Generality creep

[H. S. Teoh]

On Thu, Mar 28, 2019 at 01:56:08PM -0400, Andrei Alexandrescu via Digitalmars-d wrote:
> On 3/28/19 1:42 PM, H. S. Teoh wrote:
> > On Thu, Mar 28, 2019 at 01:04:58PM -0400, Andrei Alexandrescu via Digitalmars-d wrote:
> > [...]
> > > 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.
> > 
> > What about classes that wrap ranges?
> 
> Those must go. Supporting classes and structs within the same
> framework is a costly low-yield endeavor.

So this will be a major breaking change, since there's a significant
amount of user code that currently relies on this functionality.  Which
means we're seriously considering Phobos v2 here?  I'd support that.
It's time to reverse all those decisions that in hindsight were poor
ones.  Like autodecoding.


> > E.g., std.ranges.interfaces.
[...]
> > Since classes are reference types, this would mean it's impossible
> > to use those interfaces with forward ranges or above, which is a
> > show-stopping limitation (e.g., if you need to return two different
> > range types selected at runtime -- the current solution is to wrap
> > them in the appropriate class using std.ranges.interfaces).
> 
> The obvious solution is to use structs that wrap pointers or class
> references. We don't preclude virtuals and dynamic behavior.

IOW, all ranges will be required to be structs?  And if we need dynamic
behaviour it will have to be a struct that overrides opAssign to copy
the state of the underlying range (for forward ranges)?

I suppose that could work.  There will be friction, though, if you need
to access the underlying class hierarchy (e.g., the struct would have to
export some sort of API for casting the wrapped class reference to some
interface or base class that you might want to pass into a function
expecting such).


T

-- 
Life is too short to run proprietary software. -- Bdale Garbee