Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP


Proposal: Dict constructors from tuples #4871

kmsquire opened this Issue · 9 comments

3 participants

Kevin Squire Stefan Karpinski Jeff Bezanson
Kevin Squire

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)


  • 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.

Kevin Squire

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

Dict{K,V}(kv::Array{(K,V)}) = Dict{K,V}(zip(kv...)...)
Kevin Squire kmsquire closed this
Stefan Karpinski

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).

Kevin Squire

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.

Jeff Bezanson

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

Kevin Squire

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

Kevin Squire

(Reopening because of this discussion...)

Kevin Squire kmsquire reopened this
Jeff Bezanson

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.

Kevin Squire

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


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 #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

Kevin Squire

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


to exist.

Jeff Bezanson JeffBezanson added this to the 0.3 milestone
Jeff Bezanson JeffBezanson closed this issue from a commit
Jeff Bezanson JeffBezanson fix #4996, fix #4871
change Set, IntSet, and PriorityQueue constructors to accept a single iterable

add an ObjectIdDict constructor accepting an iterable

now you can do this:

julia> pairs = [(1,2), (3,4)];

julia> ObjectIdDict(pairs)

julia> Dict(pairs)

julia> Collections.PriorityQueue(pairs)

julia> Set(pairs)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.