Julia: Should vararg keyword arguments be returned as `Pair`?

[eschnett]

With

f(;args...)=args

there is

julia> f(x=1)
1-element Array{Any,1}:
 (:x,1)

julia> f(x=1) |> typeof
Array{Any,1}

julia> f(x=1)[1] |> typeof
Tuple{Symbol,Int64}

It might be nicer if the tuple (:x,1) was a Pair instead.

[stevengj]

It would also be nicer if args were an Associative type (albeit with simple linear search, not a heavyweight Dict).

[eschnett]

args is currently an Array{Any,1} -- would it make sense to use NTuple instead?

[eschnett]

See https://github.com/eschnett/SimpleAssoc.jl for a package that shows how an AssocArray or AssocTuple could be implemented -- associative collections based on arrays or tuples.

[tkelman]

There's already an ImmutableDict in base as an implementation detail of some recent output refactoring, I don't think it's exported though and maybe not documented either. https://github.com/JuliaLang/julia/blob/c45175f81abf0d05db835a9d302b1545b730476c/base/dict.jl#L935-L950

[eschnett]

Hmm: There is

ImmutableDict{K,V}(KV::Pair{K,V}) = ImmutableDict{K,V}(KV[1], KV[2])

but:

julia> typealias D Base.ImmutableDict{Char,Int}
Base.ImmutableDict{Char,Int64}

julia> D('a'=>1)
ERROR: MethodError: Cannot `convert` an object of type Pair{Char,Int64} to an object of type Base.ImmutableDict{Char,Int64}
This may have arisen from a call to the constructor Base.ImmutableDict{Char,Int64}(...),
since type constructors fall back to convert methods.
Closest candidates are:
  convert{T}(::Type{T}, ::T)
  (::Type{BoundsError})(::ANY)
  (::Type{BoundsError})(::ANY, ::ANY)
  ...
 in Base.ImmutableDict{Char,Int64}(::Pair{Char,Int64}) at ./sysimg.jl:48
 in eval(::Module, ::Any) at /Users/eschnett/julia05nt/lib/julia/sys.dylib:-1

Apparently needs a few tests...

[vtjnash]

that's an outer constructor, and works as intended:

julia> Base.ImmutableDict('a'=>1)
Base.ImmutableDict('a'=>1)

[eschnett]

In https://github.com/eschnett/FlexibleArrays.jl , I used the names lbnd and ubnd for the lower and upper bounds, respectively. I like the idea of returning both in one go. This also allows strided arrays if one returns a StepRange. This even generalizes to sparse arrays, where one could return just the list of indices (or an iterator to them).

[JeffBezanson]

Dup of #4916.