Generality creep

[Jonathan M Davis]

On Thursday, March 28, 2019 2:05:41 PM MDT Andrei Alexandrescu via 
Digitalmars-d wrote:
> On 3/28/19 3:43 PM, ag0aep6g wrote:
> > I've started that endeavor, because the only tangible response I got
> > when I asked what do do was from Jonathan M Davis who said: "it could be
> > argued that generic, range-based functions simply shouldn't ever be
> > assigning one range to another."[1]
>
> This is a sign things have gotten off the rail. Assignment should be
> accessible and have obvious semantics.

That's really the problem. Some operations on ranges are not well defined,
and so you can't rely on them in generic code. The prime example is copying
(though assignment then gets tied up in that). If a range is a reference
type, then iterating the copy iterates the original; if a range is a value
type, then iterating the copy doesn't affect the original; and if a range is
a pseudo-reference type, then exactly what happens depends on how it's
implemented. The end result is that you basically can't use a range after
it's been copied (which includes passing it to a function or using it with
foreach), because what happens depends on how the range was implemented.

I've thought for a while now that how things should really work would be to
require that basic input ranges be reference types and that forward ranges
be value types (ditching save, requiring copy construction instead, which
then requires wrapping classes in structs to be ranges), though that
potentially means that calling the same function on basic input ranges and
forward ranges gets a bit sticky. The biggest problem though of course is
compatibility, but if we're seriously looking at doing a v2 for major stuff
in Phobos or Phobos as a whole, then we definitely should be sitting down
and working through what we did wrong with ranges and fix this sort of
thing.

- Jonathan M Davis