Generality creep

[ag0aep6g]

On 31.03.19 08:53, Jonathan M Davis wrote:
> Once the range is saved, RefRange is
> pretty useless, because the results of what are done to the copy don't
> affect the original.
> 
> And to use RefRange, you're basically depending on implementation details of
> a particular algorithm and when it chooses to call save and what exactly it
> does with the original before and after calling save - something that is not
> part of the function's API or any guarantee that it makes. 
[...]
> RefRange on the other hand is basically trying to get access to the results
> of the first part of the algorithm prior to the call save (and possibly some
> of what's done to the original after the call to save).

All that also applies to other ranges that have reference semantics.

[...]
> So, while RefRange might be okay in code that's written specifically for use
> with RefRange, in general, it's a terrible idea. And I really regret that I
> got into Phobos. The fact that I did just shows how much less I understood
> about ranges at the time.

RefRange is painted as this big scary monster that ruins everything 
(Andrei called it "cancer", you call it a "terrible idea"). In reality, 
it might not be the most useful thing, but it works just as well as 
other reference-type ranges. Or rather, it would, if it weren't for that 
pesky opAssign. RefRange.opAssign ruins everything.