Inconsistency in assignment: Numbers vs. Arrays

[juliohm]

I don't know if this is the intended behavior, could you please clarify?

a = b = 1
a = 0
# b is still 1
A = B = eye(3)
A[1,1] = 0
# B has also changed!

In GNU Octave, A and B point to the same address location as long as no write operation is performed. The expression A[1,1] = 0 tells to the language that it is time to copy the underlying data and make A and B two distinct objects.

[ivarne]

This is definitely intended. You will have to take a copy (A = copy(B)), to actually get a different array.

[quinnj]

This is entirely on purpose. A and B refer to the same Array, so changing one will change the other. There's this section in the FAQ that discusses a point related to this, but honestly, I think the chapter on variables in the manual would be an excellent place to have an explanation on this. Isn't there somewhere else this is mentioned in the manual though? Maybe I'm just thinking of the few times this has come up in the julia-users forum.

[juliohm]

Is it not possible to mimic GNU Octave COW?

[StefanKarpinski]

Is it not possible to mimic GNU Octave COW?

Absolutely – just copy your array before modifying it ;-)

[juliohm]

Copying manually isn't the smartest solution.

[quinnj]

I would argue that's it's the most explicit and forces the programmer to think about if she really wants to assign the same reference object to two variables or if she wants two separate reference objects. No magic behind the back.

[JeffBezanson]

Currently our arrays are true mutable arrays. We might have immutable arrays as well in the future.

[jiahao]

See #5556 for a discussion on copy-on-write semantics.

[timholy]

You can also search old julia-dev discussions about copy-on-write. Bottom line is that many of us would view it as harmful. How do you implement push! if arrays are usually copy-on-write?