Generality creep

[ag0aep6g]

On 30.03.19 19:32, Jonathan M Davis wrote:
> RefRange is trying to force reference semantics, which then fundamentally
> doesn't fit with forward ranges. It sort of half fits right now, because of
> save, but as with forward ranges that are reference types, it causes
> problems, and code frequently isn't going to work with it without extra
> work.
> 
> As such, I really don't think that RefRange makes sense fundamentally.

You haven't spelled it out, but I suppose you also think that classes 
don't make sense as forward ranges. And Andrei has stated something to 
the effect that they wouldn't be supported in his redesign.

That is fine for a range redesign. But with the definitions we have 
right now, classes can be forward ranges, and Phobos should work with 
them. And if Phobos works with classes, it can work with RefRange (if we 
cut out opAssign).

If RefRange really is fundamentally at odds with current ranges, I'd be 
interested in an example where it causes trouble that isn't due to 
opAssign (or opSlice() which also shouldn't be there). Maybe I just fail 
to see the problem.

One issue I'm aware of is that RefRange does a GC allocation on `save`. 
That isn't pretty, but I wouldn't call it fatal.

I've said before that "we can cut out the bad parts" of RefRange, 
referring to opAssign, but I think I was wrong. Deprecating assignment 
would be so limiting that we might as well deprecate the whole thing.

Then again, Walter has made (limited) efforts to support ranges that are 
non-assignable due to const fields. Nobody acknowledges that those exact 
changes also work to accommodate RefRange, but they do.