Yes, I'm concerned about this as well. I'm sure we'll come up with something. Maybe allow using the old behavior during a transitional period with something like `using OldArrays` and then when you've gotten the chance to double check your code, you can delete that line and move to the new behavior. We'll have to see.
On Mon, Oct 26, 2015 at 10:20 PM, David Anthoff <anth...@berkeley.edu> wrote: > Are there plans to throw deprecation warnings in julia 0.5 whenever one > slices an array with [], and then reuse the [] syntax to return views in > julia 0.6? That would be approach that is consistent with previous changes > of functionality, right? > > > > I’m very much in favor of the new design, but I’m very worried about the > transition. There seems an enormous potential for subtle bugs to go > undetected for a long time… the tuple change was nicely phased in, as were > any other breaking changes since I’ve used julia (since 0.2), i.e. I always > had the impression that as long as I just fixed all depreciation warnings > when a new version came out, I would be good. But my understanding right > now for the array change is that the behavior of slicing with [] will > change drastically, with essentially no indicator where in my code I might > run into trouble, right? > > > > *From:* julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] > *On Behalf Of *Stefan Karpinski > *Sent:* Monday, October 26, 2015 12:05 PM > *To:* Julia Users <julia-users@googlegroups.com> > *Subject:* Re: [julia-users] Re: Re: are array slices views in 0.4? > > > > On Mon, Oct 26, 2015 at 2:17 PM, Christoph Ortner < > christophortn...@gmail.com> wrote: > > Fabian - Many thanks for your comments. This was very helpful. > > > > (c) if I want to write code now that shouldn't break with 0.5, what should > I do? > > > I think when you need a copy, just surround your getindex with a copy > function. (e.g. copy(x[:,10]) instead of x[:,10]). > > > > But this would lead me to make two copies. I was more interested in seeing > whether there is a guideline on how to write code now so it doesn't have to > be rewritten for 0.5. > > > > There will be a solution in the Compat package once this change is made. > It will probably consist of having a replacement for getindex that creates > a slice rather than a copy so that calling copy won't result in two copies. > I.e. it will backport the 0.5 behavior to earlier versions of Julia. > > > > Regarding this change I am also more on the sceptical side. I would very > much prefer a copy-on-write like solution like Matlab and R provide, but I > don't know if and how this would be possible to implement, so I don't raise > my voice here. > To me the main benefit of this change is that it drove the main developers > to make array views much more performant and first class members of julia. > As Tim Holy mentioned, the actual change seems to be be very small, but it > needed and still needs a lot of work to make it possible. > > > > My own scepticism comes from the idea that using immutable objects > throughout prevents bugs and one should only use mutable objects sparingly > (primarily for performance - but I thought it shouldn't be the default) > > > > Copy-on-write is complex and leads to brittle performance properties that > cannot be reasoned about locally. The semantics of R and Matlab also > notoriously make it impossible to write efficient mutating functions – > people generally end up writing C extensions to do that. > > > > It remains to be seen how this pans out, but keep in mind that C, C++, > Java, Fortran, Julia, Python, Ruby, etc. all use mutable non-copy-on-write > arrays everywhere and the world has not ended. Slices are a bit different, > but NumPy, for example, creates views for slices and that works well in the > SciPy ecosystem. > > > > Philosophically, I think that returning views from operations is > problematic when the object being viewed is conceptually a single value – > strings being a good example that have gone different ways in different > languages. In C everyone thinks of strings as arrays of characters and it > works pretty well since everyone has that in mind. In higher level > languages, people stop thinking of strings this way, which means that > making strings mutable or returning slices of them as views becomes > problematic because it's at odds with how we think of strings. Arrays are > the prototypical example of a container-like thing, so I don't think that > this will be that confusing. If you "own" the array, then it's ok to make a > slice and potentially mutate it – if you don't, then it's not ok. We could > potentially add tooling to help enforce this since we know by the f! naming > convention which functions should and shouldn't mutate their arguments. >
