Generality creep

[Jonathan M Davis]

On Thursday, March 28, 2019 11:42:50 AM MDT H. S. Teoh via Digitalmars-d 
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? 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).

It's not a problem for basic input ranges, because they'd then have
reference semantics. The problem would just be forward ranges, and the
solution to that is to use wrapper ranges which are structs. Then they can
define a copy constructor which gives value semantics in place of save.

The reality of the matter though is that code should be _really_ wary of
using classes for forward ranges, because it requires calling new a lot, and
it's really inefficient. So, while we probably should support it for those
use cases that really need it, if code doesn't really need it, it shouldn't
do it. For instance, I tested dxml with a whole range of range types
(including ranges that were classes) when benchmarking, and performance
tanked when using ranges that were classes because of all of the memory
allocation that was happening.

- Jonathan M Davis