Less quacking in Dict constructor?

[timholy]

This may have been discussed previously (I searched but didn't find it), but there are circumstances where duck-typing the Dict constructor can lead to confusion.

https://discourse.julialang.org/t/does-anyone-else-find-the-behavior-of-dict-namedtuple-a-little-funky-juli/56050

It may be worth briefly considering a future requirement that it be an iterable of Pairs? Or less drastically, where each item in the iterable have exactly 2 elements?

[jakobnissen]

Yeah, that example is confusing. But perhaps it's useful to separate three distinct reasons why it's confusing:

1. Duck typing - he fact that you can make Dicts from 2-tuples, arrays of two elements, pairs, and whatever
2. The fact that any iterable of >N elements can be destructured into N elements (Stricter tuple destructuring. Error on (a, b) = (1, 2, 3) #37132)
3. The fact that named tuples "looks" like pairs, but only iterate over their values, not their keys.

I think these are different and have different resolutions. Do we really want to restrict or remove duck typing? This issue's title suggests so, but I think a huge part of Julia's power draw from this ability. If we do that, we might eventually end up relaxing that restriction, as there will no doubt be a flood of PR's with "Allow constructing a dict from Foo".

Point two is clearly a mistake, I think, but that has its own issue and is already milestoned for 2.0, so let's not rehash it here.

The last one (edit: whether named tuples should iterate key => value pairs) is debatable. I have no strong opinions, but I'm sure other people do.

The restrictions on destructuring alone would make the original example error. @timholy Do you think there is reason to have a dict-specific solution to this, other than restricting destructuring as in #37132

[timholy]

These are excellent points. But #37132 isn't the only problem here; suppose I instead had done

julia> t = (a = [1, 2], b = [4, 5])
(a = [1, 2], b = [4, 5])

julia> Dict(t)
Dict{Int64, Int64} with 2 entries:
  4 => 5
  1 => 2

then implementing #37132 wouldn't save me.

On your third reason,

The fact that named tuples "looks" like pairs, but only iterate over their values, not their keys

it's really hard to address this generally. Are NamedTuples more like Tuples or AbstractDicts? We could solve this by having all indexable collections iterate as if we'd applied pairs(iter), but then non-indexable collections will have fundamentally different iteration behavior from indexable collections.

For this reason it seems to me that the least-disruptive solution is to be pickier about the constructor of any AbstractDict. But like you, I think this box is a really hard to design in. We need more mind-reading.

[jakobnissen]

We could solve this by having all indexable collections iterate as if we'd applied pairs(iter)

It would be highly unexpected if e.g. collect([15, 16]) gave [(1, 15), (2, 16)]. I think we unfortunately need some distinction between "iterables of (index, value) pairs", e.g. AbstractDict, and "iterables of values". It's just where NamedTuple falls on that line.