"the last change" for ranges

[Jason House]

dsimcha Wrote:

> == Quote from Bill Baxter (wbaxter at gmail.com)'s article
> > On Wed, May 20, 2009 at 11:44 AM, Andrei Alexandrescu
> > <SeeWebsiteForEmail at erdani.org> wrote:
> > > Jason House wrote:
> > >>
> > >> Andrei Alexandrescu Wrote:
> > >>
> > >>> Jason House wrote:
> > >>>>
> > >>>> I feel like there are too many differences between input and forward
> > >>>> ranges for such a minor difference. Many range functions are written
> > >>>> assuming no side effects on the caller. This can restrict the use of
> > >>>> helper functions. It may be best to make their usage different...
> > >>>
> > >>> So how do you think we should go about it? Also don't forget that any
> > >>> ranges should be seamlessly and efficiently treated as input ranges.
> > >>>
> > >>> Andrei
> > >>
> > >> You won't like my answer!
> > >>
> > >> Like you've already said, the semantics of forward ranges and input ranges
> > >> are different. I would argue that forward ranges have value semantics but
> > >> input ranges do not. Any function that implicitly assumes value semantics is
> > >> wrong. Sadly, overlapping API's makes that all too easy for someone to write
> > >> bad code that passes simplistic tests with forward ranges and then fail with
> > >> input ranges.
> > >>
> > >> My initial thoughts is that input ranges should have two changes:
> > >> 1. A different API from forward ranges
> > >> 2. Be a reference type (AKA class instead of struct)
> > >>
> > >> In short, I disagree with your basic premise of treating the two ranges
> > >> similarly.
> > >
> > > I don't want to treat them similarly, but we should be able to treat forward
> > > ranges as input ranges. Otherwise, all algorithms that work for input ranges
> > > would have to be written twice.
> > auto inp = std.typecons.inputRangeFromForwardRange(fwd);
> > No need to write the algos twice now, but you do have to add a line or
> > two of code to every input range algo.  Or force the the user to call
> > the converter function.
> > --bb
> 
> But if you make the input range a class as Jason proposed, then:
> 
> 1.  Unless it's final, its methods will be virtual (slow).
> 2.  You trigger a heap allocation every time you want to make this conversion.  (slow)

Scope classes avoid the heap allocations. Classes are not required for referance semantics. Specially constructed structs can also satisfy the requirement. By declaring the typical input range to be a (scope final) class, I was hoping to emphasize the fundamental difference with forward ranges.

It should be trivial to write a (scope) wrapper that converts a forward range into an input range. The compiler should be able to optimize away the wrapper or at least inline the functions.