"the last change" for ranges

[Jason House]

Bill Baxter Wrote:

> On Wed, May 20, 2009 at 12:05 PM, dsimcha <dsimcha at yahoo.com> 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)
> 
> Maybe, but I don't really agree that input ranges should be forced to
> be classes.  Seems like they should be allowed to be either as long as
> they support the required methods.

If you really mean methods and semantics, then I agree. It's becoming increasingly clear to me that D users struggle against the struct/class division. I frequently think of the division as value/reference type while many others think of it as non-virtual/virtual. These different perspectives means there is a large set of "objects" where the two definitions disagree on which data type (struct or class) is more appropriate. IMHO, D should have a type with low size and function call overhead like a struct as well as reference semantics like a class. 
 
> Actually that's a good argument for not making  a = b part of the
> Forward Range concept.   If you get rid of that one, then Forward
> Ranges can be either classes or structs too.

Having undefined behavior (for assignments and passing as arguments) is bad.