range.save

[Jonathan M Davis via Digitalmars-d]

On Thursday, 26 November 2015 at 17:23:07 UTC, Andrei 
Alexandrescu wrote:
> As of right now the situation with ranges is suboptimal - you 
> need to use .save() but if you don't the sheer copy works most 
> of the time, just not always. It may be nice to improve on that 
> a bit, for example to require input ranges that are not forward 
> ranges to indeed have reference semantics. Or require forward 
> ranges to define .save() but only with the body { return this; 
> }. Either of these would break code.

As long as a range has semantics very similar to a dynamic array, 
it works great, but as soon as it doesn't, it tends to fall apart 
in subtle ways. The current situation is simply too error-prone 
and unwieldy IMHO. It works great in the common case but 
definitely falls apart at the edges. And even if you're diligent 
about getting it right, the number of calls to save that are 
required is ridiculous. So, while I completely agree that we want 
to avoid breaking code if we can, I'm also increasingly convinced 
that we should look at what would need to be done to make ranges 
clean to use without being error-prone and see if we can get 
there with minimal breaking changes. Regardless, if we _do_ make 
breaking changes with regards to ranges, we need to be very sure 
that we want to make them.

- Jonathan M Davis