Forward ranges in Phobos v2

[H. S. Teoh]

On Tue, Nov 02, 2021 at 11:07:08PM +0000, Paul Backus via Digitalmars-d wrote:
> On Tuesday, 2 November 2021 at 21:58:20 UTC, Andrei Alexandrescu wrote:
[...]
> > The differentiation can be made with a nested enum tag:
> > 
> > struct MyInputRange {
> >     enum inputRangeTag = true;
> >     ...
> > }
> > 
> > Client code can inspect R.inputRangeTag to figure whether the range
> > is input (if present) or forward (if missing).
> 
> Not sure this is the best idea--it means new-style algorithms will
> silently treat old-style input ranges as though they were forward
> ranges, which could lead to incorrect behavior at runtime. If we are
> going to make incompatible changes to the range API, we should do it
> in such a way that version mismatches are caught at compile time.

The problem with manually-added tags of this sort is that people forget
to do it, and that leads to trouble.  Preferably, it should be something
already implicit in the range type itself, that does not require
additional effort to tag.

I'm kinda toying with the idea of struct == forward range, class ==
input range: the difference is inherent in the type itself and requires
no further effort beyond the decision to use a by-value type vs. a
by-reference type, which coincides with the decision to make something
an input range or a forward range.


T

-- 
Political correctness: socially-sanctioned hypocrisy.