On Tuesday, March 06, 2018 09:36:43 H. S. Teoh via Digitalmars-d-announce
> 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