Map function inconsistency with scalar inputs

[BioTurboNick]

Pursuant to discussion here: https://discourse.julialang.org/t/map-pmap-and-scalar-argument/30089

Scalars, provided to a function like map or pmap, leads to unexpected behavior:

map(+, 1:2, 1) # [2]

map(+, 1:2, [1]) # ERROR: DimensionMismatch

A user would naively think a scalar would be broadcast or rejected. Treating it as if the user just wanted to process the first element of each argument would be unlikely to be intended.

Based on discussion linked above, it appears to be because scalars are iterable. The code for consuming iterables uses zip() to stitch the arguments together, which takes as many as it can and discards the remainder.

For comparison, here are how some other inputs are treated:

map(+, 1:2, (1,)) # [2]

map(+, 1:2, (1,2)) # [2;4]

map(+, 1:2, (1,2,3)) # [2;4]

map(+, 1:2, (i for i in 1:1)) # ERROR: DimensionMismatch

map(+, 1:2, (i for i in 1:2)) # [2;4]

These are also surprising to me, since documentation suggests a generator is an iterable, but its size is being enforced as if it were an array. Meanwhile, tuples which have a fixed number of elements are treated like an iterator of unknown length.

[mbauman]

Duplicate of #29523

[BioTurboNick]

It's not a duplicate. That issue is about an array input being checked inconsistently. This issue is about a scalar input not being checked at all.

It's possible that the constellation of fixes proposed for the related issues would also solve this issue, but I'm unclear on that at the moment.

[mbauman]

Ok, but can we fold this into that issue, though? Yes, it's a slightly different example, but it's definitely an example of map checking dimensions inconsistently. It'll be easier to track and tackle if it's all together.

[BioTurboNick]

Sure. Should I make an explicit note of that in that issue?

[mbauman]

That'd be great!