implement `@fill([0, 0], 2)`

[CameronBieganek]

Original Title: Change fill([0, 0], 2) behavior for 2.0

The behavior of fill when its first argument is an array is to create an array of arrays, where each of the elements is a reference to the exact same array in memory. This is counterintuitive to many users (see Discourse links below), and it seems kind of pointless. I propose that in 2.0 fill with an array input should fill the resulting array with copies of the input array.

Below are some examples where this came up on Discourse. There may be more.

https://discourse.julialang.org/t/simple-question-about-assignment-to-a-vector-of-vectors/62744
https://discourse.julialang.org/t/fill-anarray-2-behaviour/22429
https://discourse.julialang.org/t/initialization-of-array-of-arrays-with-fill-ones-1-2-2-only-one-vector-is-created/48048
https://discourse.julialang.org/t/how-can-i-fill-an-array-with-empty-2d-arrays/60895

[simeonschaub]

Copying by default seems even more confusing to me. This would cause lots of allocations any time an array is filled with mutable objects. There are many situations where you actually want to fill an array with references to the same mutable object, for example pretty much any time you don't plan to mutate the items in an array themselves, which is a frequent use case when working with DataFrames. Implicit copies can also lead to wrong results in some cases, for example Measurements.jl uses references to other measurements to keep track of correlations. It is also not clear how this should behave for recursively mutable objects: if it's just the default copy behavior, you would run into exactly the same issues when filling an array with arrays of arrays, you could use deepcopy, but that can be super slow and can easily blow up allocations for more complex objects.

I think we should just document the current behavior better. Once you have a basic understanding how memory and references work, the current behavior makes a lot of sense, so I don't think that needs to be changed. One thing we could do is add a copy keyword argument to fill though, so if someone wants the copying behavior, it's really easy to get.

[JeffBezanson]

Fully agree with Simeon. Calling copy internally is a hack. I think what you really want here is to evaluate the argument expression for each element, not just get a copy, e.g. consider something like fill(rand(), n). Then the copy behavior, if you want it, is an easy special case. The easiest way to do this now is with a comprehension, but the syntax is unfortunately very different from fill. Maybe a @fill(expr, ...) that does repeated evaluation?

[simeonschaub]

Maybe a @fill(expr, ...) that does repeated evaluation?

Does that really add something over just using an array comprehension though?

[JeffBezanson]

Not really, it's just shorter.

[PaulSoderlind]

I believe those discourse threads signal that the documentation could be improved. If x is an object reference, all elements will refer to the same object: is somewhat opaque. Adding the example (done in #35683) was a step in the right direction, but perhaps not enough.

In fact, the expression object reference does not seem to be widely used in the docs. Searching the pdf gives 4 hits: 2 on unsafe_pointer... and 2 on fill/fill!. Is there a better (simpler) terminology?

[goretkin]

Is it wrong to say if x is mutable (ismutable(x)) instead of if x is an object reference?
(yes, because of #30210 , but otherwise?)

[PaulSoderlind]

@goretkin

Could I ask you submit a PR - and then we see how this plays out?
Maybe we could try If x is mutable (ismutable(x)), for instance, an Array, then all elements will refer to the same object:?

[simeonschaub]

ismutable(x) here is not quite correct, since for example:

julia> ismutable(1 => Ref(2))
false

while this will still run into the same issues as mentioned above.

[PaulSoderlind]

Thanks. I (and several others, it seems) am still struggling with If x is an object reference, all elements will refer to the same object. I guess just changing to If x is an object reference (for instance, an array), all elements will refer to the same object would be a step forward, but maybe you have a better idea?

[mbauman]

There's no if. All elements always are the same object. The only time it's observable, though, is if there's something mutable.

[CameronBieganek]

I concede that there isn't really a sensible way to do this. We would need to use either a macro or a function myfill whose first argument is a function (the name of the function would have to be different from fill, since the first argument of fill is generic for the existing method definitions, unless we want to use the f::Union{Function, Type} hack). At that point it makes more sense to just use a comprehension or a generator.

I'm not too invested in this anyways---I just noticed that this question came up a lot on Discourse.

[CameronBieganek]

On second thought, could we branch on isbits? If an object is not isbits, then we do a deepcopy?

julia> myismutable = !isbits
#76 (generic function with 1 method)

julia> myismutable([1, 2])
true

julia> myismutable(1 => Ref(2))
true

julia> struct A
           x::Vector{Int}
       end

julia> myismutable(A([1, 2]))
true

[simeonschaub]

That wouldn't make any difference, since deepcopy is just a no-op for isbits objects.

[CameronBieganek]

Yeah, I just noticed that deepcopy has

isbitstype(typeof(x)) && return x

for its first line.

That wouldn't make any difference, since deepcopy is just a no-op for isbits objects.

But that's fine. We want it to be a no-op for isbits objects! The point is that its not a no-op if the object is not isbits.