Should we allow `IOContext` to accept `kwargs`

[m-wells]

IOContext already accepts Vararg{Pair{Symbol}}. The following code seems to work just fine.

> julia
               _
   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.8.2 (2022-09-29)
 _/ |\__'_|_|_|\__'_|  |  Official https://julialang.org/ release
|__/                   |

julia> Base.IOContext(io; kwargs...) = if length(kwargs) > 0
       IOContext(io, kwargs...)
       else
       convert(IOContext, io)
       end

julia> IOContext(stdout)
IOContext(Base.TTY(RawFD(13) open, 0 bytes waiting))

julia> io = IOContext(stdout)
IOContext(Base.TTY(RawFD(13) open, 0 bytes waiting))

julia> printstyled(io, rand())
0.39622936715782087
julia> io = IOContext(stdout; compact=true)
IOContext(Base.TTY(RawFD(13) open, 0 bytes waiting))

julia> printstyled(io, rand(), color=:red)
0.0857637

I can open a PR if there is interest.

[rfourquet]

For context, the kwargs version was deleted in #23271 as being redundant.

[m-wells]

This kwargs version is actually faster. Also, passing options as key => value is not how most other Base methods accept options.

julia> IOContext(stdout, :compact=>true, :limit=>true, :color=>true);

julia> @time IOContext(stdout, :compact=>true, :limit=>true, :color=>true)
  0.000011 seconds (9 allocations: 304 bytes)
IOContext(Base.TTY(RawFD(13) open, 0 bytes waiting))

julia> # define the kwargs method

julia> IOContext(stdout; compact=true, limit=true, color=true);

julia> @time IOContext(stdout; compact=true, limit=true, color=true)
  0.000004 seconds (4 allocations: 128 bytes)
IOContext(Base.TTY(RawFD(13) open, 0 bytes waiting))

[m-wells]

@rfourquet could we also label this as performance improvement as well?

[vtjnash]

Dict constructors do not typically accept kwargs as values for initialization as an explicit decision, which is what this proposes adding for the special case of IOContext

[m-wells]

Dict constructors do not typically accept kwargs as values for initialization as an explicit decision, which is what this proposes adding for the special case of IOContext

I see. It seems quite natural (and performant, see the example above) to allow this sort of construction. What is the rationale behind this convention.

[vtjnash]

For Dict, it is because it fails to generalize appropriately, since it only meaningful for Symbol keys. And because it is how the AbstractDict itself is expected to be configured (if applicable). And because NamedTuple doesn't iterate to produce pairs, but rather is an ordered container of values closer to a Tuple (that last is a bit less relevant now that kwargs are once again acting like a list of Pairs objects and not like NamedTuples)

[LilithHafner]

I think that the fact that IOContext is backed by a Dict is an implementation detail. To a user, its main role is mapping option names to values, for which keyword arguments are standard.

could we also label this as performance improvement as well?

The benchmarks you gave are not particularly convincing because the @time results are both just a few microseconds which is below level of noise/overhead in @time. However, with more accurate benchmarking, we can see that it is indeed a performance improvement :)

julia> using BenchmarkTools

julia> @btime IOContext(stdout)
  105.540 ns (1 allocation: 32 bytes)
IOContext(Base.TTY(RawFD(15) open, 0 bytes waiting))

julia> @btime IOContext(stdout, :compact=>true, :limit=>true, :color=>true)
  430.151 ns (9 allocations: 304 bytes)
IOContext(Base.TTY(RawFD(15) open, 0 bytes waiting))

julia> Base.IOContext(io; kwargs...) = if length(kwargs) > 0
           IOContext(io, kwargs...)
       else
           convert(IOContext, io)
       end

julia> @btime IOContext(stdout)
  105.931 ns (1 allocation: 32 bytes)
IOContext(Base.TTY(RawFD(15) open, 0 bytes waiting))

julia> @btime IOContext(stdout, :compact=>true, :limit=>true, :color=>true)
  424.854 ns (9 allocations: 304 bytes)
IOContext(Base.TTY(RawFD(15) open, 0 bytes waiting))

julia> @btime IOContext(stdout; compact=true, limit=true, color=true)
  117.416 ns (4 allocations: 128 bytes)
IOContext(Base.TTY(RawFD(15) open, 0 bytes waiting))

[m-wells]

This is probably a better definition than the one I had originally

@inline Base.IOContext(io; kw...) = isempty(kw) ? convert(IOContext, io) : IOContext(io, kw...)

[KristofferC]

I think that the fact that IOContext is backed by a Dict is an implementation detail.

The docs say:

In short, it is an immutable dictionary that is a subclass of IO.

so I am not sure it is really an implementation detail. And you interact with it like a dict with get etc.

[rfourquet]

I would not base the decision for this on whether this is faster or not, as performance comparisons might evolve; unless the current performance with pairs is deemed problematic (but I don't recall seing complaints about it) and it's believed to not be easily improvable.
And yes IOContext is literally a container for pairs, as dicts, whereas usually keywords are more used to tweak how the method should proceed. But I recognize that kwargs syntax can be more convenient at times.

[m-wells]

Ok, so maybe leave IOContext alone.
But how about something like sprint.
The kw... would take precedence over the context.
Currently it looks like

function sprint(f::Function, args...; context=nothing, sizehint::Integer=0)
    s = IOBuffer(sizehint=sizehint)
    if context isa Tuple
        f(IOContext(s, context...), args...)
    elseif context !== nothing
        f(IOContext(s, context), args...)
    else
        f(s, args...)
    end
    String(resize!(s.data, s.size))
end

It could be extended to

function sprint(f::Function, args...; context=nothing, sizehint::Integer=0, kw...)
    s = IOBuffer(sizehint=sizehint)
    if context isa Tuple
        ioc = IOContext(s, context...)
    elseif context !== nothing
        ioc = IOContext(s, context)
    else
        ioc = IOContext(s)
    end
    f(IOContext(ioc, kw...), args...)
    String(resize!(s.data, s.size))
end

[rfourquet]

Why not, but kw... could be believed to be kwargs to be passed to f instead of to the IOContext constructor.