Mapping empty Arrays

[MillCheck]

typeof(float(String[])) is Array{String,1}. This can cause performance issues.
typeof(map(float, String[])) behaves the same.

Even worse, runtime errors if someone reads numbers from a line and later tries to push! something to them - if the line was empty, you get an ERROR.

[simonster]

I think this is already covered by #210/#1864/ #10269. Without knowing what type the function returns, we can't get the proper return type for an empty array. But even if we could do that, type inference would also have to know about the return type to solve the performance issue. Parametric function types should solve all of this.

[johnmyleswhite]

I believe not all functions will be parametric and hence map of empty arrays will still do odd things sometimes.

[JeffBezanson]

For those particular conversion functions, e.g. float(), it would be totally reasonable for them to pick the result type and use map! instead.

[MillCheck]

I think making it return Any[] would be reasonable then

[JeffBezanson]

Array{Union()} is an even better general result for an empty array.

[StefanKarpinski]

I feel like we've already been here: [] used to construct a Vector{Union()} (it was called Vector{None} back then). Then we decided that was a pretty useless type, so we made it do Any[] instead. What makes this situation different, I suppose is type stability. You don't want the return type signature of map(x->x+1, Vector{Int}) to be Union(Vector{Int},Vector{Any}), and Union(Vector{Int},Vector{Union()}) is a bit better since you know that any element taken out of something of that type must be an Int, but it's still kind of an unfortunate type signature. @JeffBezanson, are you concerned about this?

[JeffBezanson]

I think [] is a really different case because that will be written by hand to initialize an array for pushing things into.

I'm concerned about it, but I also don't see what else can be done. Vector{Union()} is much better than Vector{Any} or Vector{String} in the empty map case.

[nalimilan]

But won't the same problem reappear if you try to call push! on the Vector{Union()} resulting from calling map on an empty array? I imagine this could create run-time exceptions, but only under very specific conditions -- i.e. they would often not be detected by the developer until a user encounters the bug. So in a sense it might be worse than [], which at least gives this behavior more reliably.

[simonster]

The counterpoint to @nalimilan's example is g(map(f, x)) where g takes a Vector{T<:Number}. This will work if map returns a Vector{Union()}, but won't work if it returns a Vector{Any}.

[nalimilan]

Yeah, the eternal covariance vs. contravariance dilemma...

[JeffBezanson]

When there is no "one right answer", you have to make these decisions based on expected use in each case. You hardly ever see code that even mutates, let alone grows, the result of a map. Unlike map, [] shows the specific intention to start with an empty array, while getting an empty array from map is just one case.

If arbitrarily mutating the result of map is the requirement, then you can only really give an Array{Any}.