For the decimal format I would recommend checking typeinfo and, if it matches the type, printing without any decoration 123. If it does not match (including unset typeinfo) then print UInt64(123).

We would need an extremely compelling use case to motivate introducing new syntax or pseudo-syntax/abbreviations like 123u.

I bet you could implement this in a package with a display backend (or you could use piracy).

For the decimal format I would recommend checking typeinfo and, if it matches the type, printing without any decoration 123. If it does not match (including unset typeinfo) then print UInt64(123).

Sure, I think that's even better; changed in f498e86. New examples:

julia> function Base.show(io::IO, n::Unsigned)
           if get(io, :hexunsigned, true)::Bool
               print(io, "0x", string(n, pad = sizeof(n)<<1, base = 16))
           else
               if get(io, :typeinfo, Nothing)::Type == typeof(n)
                   print(io, n)
               else
                   print(io, typeof(n), "($n)")
               end
           end
       end

julia> Base.active_repl.options.iocontext[:hexunsigned] = false
false

julia> rand(UInt8, 10)
10-element Vector{UInt8}:
  24
 246
  41
  59
 227
 230
 232
  35
 229
 219

julia> using Sockets

julia> listenany(8080)
(UInt16(8080), Sockets.TCPServer(RawFD(23) active))

I bet you could implement this in a package with a display backend (or you could use piracy).

I actually did do it by type-piracy in my startup.jl for like a year, but the extra latency from invalidations was too much in the end so I recently disabled it (hence this PR). I'm not sure how it could be done with a custom display, but in any case I'd argue this is basic (and wanted) enough to be in Base.

(bump)

From triage,

Ideally, we would have a better way to configure REPL display options that doesn't require the options to be baked into Base. That said, there are not very many REPL display options folks have asked for and we don't think that there's going to be a new extensible REPL display option system any time soon (if you're reading this, please build one :) ), so it's fine to proceed with this approach now.

I'm glad it passed triage, but to be clear this is an IOContext/show option rather than a REPL-specific display option. Do you mean that it would be better to have an extensible IOContext system?

It would be better to implement this as a custom display backend, or to entirely overhaul the io API. The former being a smaller project.

Oh, actually, this needs a news entry. Sorry I only realized that now.

No worries, added in 338e886.