"the last change" for ranges

[Bill Baxter]

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.

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.

--bb