Generality creep

[Jonathan M Davis]

On Thursday, March 28, 2019 11:04:58 AM MDT Andrei Alexandrescu via 
Digitalmars-d 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.

I've thought for a while now that this is what we should do if we could
start over. The problem has been that it breaks a ton of code, and a
migration path is difficult. Doing a v2 version of Phobos would really help
with making fixes like that - though then we have to deal with stuff like
whether a library is written to work with v1 or v2, and with stuff like
ranges effectively working via duck typing, that could get a bit
interesting. If we can do it without splitting the community though, it
would allow us to fix some of the big mistakes we made with our core stuff
(auto-decoding being another).

- Jonathan M Davis