Difference between Array reshaping and MArray/SizedArray reshaping

[mateuszbaran]

Modifying a reshaped array modifies the original array as well but it doesn't do that with MArray or SizedArray (a copy is created instead):

julia> vm = @MVector ones(4);

julia> vmr = reshape(vm, Size(2,2))
2×2 MArray{Tuple{2,2},Float64,2,4} with indices SOneTo(2)×SOneTo(2):
 1.0  1.0
 1.0  1.0

julia> vmr[1] = 12
12

julia> vm
4-element MArray{Tuple{4},Float64,1,4} with indices SOneTo(4):
 1.0
 1.0
 1.0
 1.0

Since we now have SizedArray that can wrap any AbstractArray, this could be fixed relatively easily. Is this something worth fixing before the 1.0 release?

[c42f]

Since we now have SizedArray that can wrap any AbstractArray, this could be fixed relatively easily. Is this something worth fixing before the 1.0 release?

Sounds good to me.

[andyferris]

I personally don't mind if this comes before or after 1.0. I've grown to like the (less bureacratic) Julia developers interpretation of semver via "minor change" which might theoretically break some code but seems very unlikely to bite anyone in practice.

[c42f]

Whether this is a breaking change depends on your point of view:

• It can certainly break people's code if they are using the concrete StaticArrays types within their code and nothing else.
• If they're coding against the (loosely defined) AbstractArray interface, they'll probably be testing with normal Array, and find that StaticArrays is inconsistent. From this point of view, this is just a bug to be fixed.

I guess we run up against Hyrum's Law here: there's quite a lot of users of StaticArrays, so if our implementation is broken in some subtle way there's a good chance somebody will be depending on it. And fixing the bug will break their code.

One option would be to state explicitly in the documentation that we interpret semver as:

"Any departure from the AbstractArrays interface is a bug; we will not increment the major version in fixing such bugs, but treat them as a "minor change" which can be fixed in minor version numbers"

[c42f]

That seems like a practical way forward; from that point of view, I'm happy to fix this in 1.1.0