> Array slices will create views rather than copies. This is just a matter of performance
Except for breaking any existing code which mutates slices (unless slices are COW?), and implicit sharing can have disastrous effects on memory usage.
Except for breaking any existing code which mutates slices (unless slices are COW?), and implicit sharing can have disastrous effects on memory usage.
A small long-lived slices keeping a original arrays alive implicitly. Oracle recently undid the same optimisation in Java's strings because of that exact issue (which obviously broke code the other way around, code relying on cheap substrings would now take O(n) instead of O(1)). Erlang developers are also warned early and often about that behaviour in binaries.
Still something that should be in bold text in Julia 0.5's readmes, though; slicing is cheap now, but it comes with this very important caveat!
Iterating over the columns of an in-memory matrix, for example, is the use case that this change is meant to speed up.
I am saying this change is not quite "just a matter of performance", that the documentation and changelogs should be very very clear about the behavioural changes and the possible issues with the new behaviour, and that there should be an easy way to "unshare" slices and force a copy.
Like advanced indexing (http://docs.scipy.org/doc/numpy/reference/arrays.indexing.ht...) in the Python world?
2. there are gradations in breaking changes, the breaking changes I outline are insidious because they are silent, they won't cause the program to fail loudly, but they will cause it to behave very differently than it used to and possibly to corrupt data.