"the last change" for ranges

[Bill Baxter]

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