Generality creep

[Andrei Alexandrescu]

On 3/28/19 1:04 PM, Andrei Alexandrescu wrote:
> On 3/28/19 9:16 AM, ag0aep6g wrote:
>> On 28.03.19 14:05, Andrei Alexandrescu wrote:
>>> Then some ranges are not meant to be assignable.
>>
>> Should Phobos be compatible with those ranges?
> 
> A variety of algorithm and data structures in Phobos are relying on 
> assignment. Presumably a good part of them can be converted with ease to 
> use single assignment, but not all.
> 
> The overall message is we got bogged down on the "wrong" side of 
> generality - cross-cutting and nonscalable code additions to support 
> unprincipled and low-impact corner cases.
> 
> Part of that is we've been cagey about defining copy and assignment 
> semantics of ranges in a simple and comprehensive manner. It seems to me 
> going with these is the right thing:
> 
> * Input ranges are copyable and assignable, and have pointer semantics 
> (all copies refer to the same underlying position, and advancing one 
> advances all others).
> 
> * Forward ranges are copyable and assignable, but distinct copies refer 
> to distinct positions in the range such that advancing one does not 
> advance the others.
> 
> * We don't support other semantics.

Forget to add - no more save(). We just use some sort of flag and simple 
introspection.