Proposal: Dict constructors from tuples

[kmsquire]

Just putting out feelers: I'd like to propose:

• removing constructing Dicts from tuples as is currently done

  Dict{K,V}(ks::(K...), vs::(V...)) = Dict{K ,V }(ks, vs)
  Dict{K }(ks::(K...), vs::Tuple ) = Dict{K ,Any}(ks, vs)
  Dict{V }(ks::Tuple , vs::(V...)) = Dict{Any,V }(ks, vs)
  

  (from https://github.com/JuliaLang/julia/blob/master/base/dict.jl#L302)

• add a dict constructor from a list of tuple pairs (as the inverse of collect on a Dict)

Item 1 seems like a vestige from before we had literal dict construction--is this used anywhere?

Item 2 seems like an oversight.

[kmsquire]

Of course, the easiest way to implement the second constructor would be

Dict{K,V}(kv::Array{(K,V)}) = Dict{K,V}(zip(kv...)...)

[StefanKarpinski]

I'm curious why you closed this? I do think that the collection constructors could use some review for consistency and completeness – Dicts, Sets, Arrays (which are already quite good).

[kmsquire]

Sorry, should have explained better. After making the comment above, I simply created a pull request for the new Dict constructor here: #4872.

Since it uses the other constructors, there didn't seem much point in asking to remove them, and the constructor itself is trivial.

[JeffBezanson]

Dict literals work by calling the Dict(ks,vs) constructors :)

[kmsquire]

How about changing the Dict constructor as you suggested in #4872, and making that the target of Dict literals?

[kmsquire]

(Reopening because of this discussion...)

[JeffBezanson]

That would be ok, but the current implementation was picked for efficiency. Of course I could use a hidden dict_literal() for this if we want to keep Dict simpler.

[kmsquire]

I guess my main motivation in wanting to simplify the Dict constructors is to work around #4859, so that

Dict{A,B}(::Type{A},::Type{B})

can exist. Right now, it conflicts with the Dict tuple constructors. If #4859 were addressed, this wouldn't be as necessary.

The above construction would be useful because:

1. This (or Feature Request: allow default values for unspecified type parameters #4859) would make other Dict types with more type parameters (OrderedDicts, DefaultDicts) less annoying, since they could have a similar set of constructors, and reasonable type defaults could be provided
2. It's more consistent with Array constructors

[kmsquire]

I wonder how much slower would this be:

Dict(ks, vs) = Dict{eltype(ks), eltype(vs)}(ks,vs)

This would subsume the current interfaces, and still allow

Dict{A,B}(::Type{A},::Type{B})

to exist.