Generality creep

[Andrei Alexandrescu]

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.

> E.g., std.ranges.interfaces.

One could pin-point the introduction of that as a clear point when we 
veered from the nice highway into the cornfields.

> 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.