On Tuesday, March 06, 2018 09:36:43 H. S. Teoh via Digitalmars-d-announce wrote: > Andrei has said before, and probably on more than one occasion, that if > he were to redesign ranges today, one of the things he would do > differently was to change the definition of forward range so that .save > is basically implicit on copying the range object, and non-forward input > ranges would just be reference / non-copyable types. > > But that boat has long sailed, and we just have to make do with what we > have today. Changing this now will literally break just about *every* D > program that uses ranges, which is breakage of an ecosystem-killing > magnitude that I can't even contemplate. I would much rather go with a > less intrusive breakage like killing autodecoding with fire, than with > something that will basically require me to rewrite practically every D > program I ever wrote.
I'm not actually convinced that killing auto-decoding is really much better. As it stands, changing it would break a large percentage of string-based code, and the functions in question sit in std.range.primitives along with all of the other core range stuff such that I don't see how we can change them any more than we can change the basic range API. I would love to be proven wrong, but I don't know how we could change it at this point without code breakage that comes pretty close to the breakage that changing the range API would cause. - Jonathan M Davis