Forward ranges in Phobos v2

[Steven Schveighoffer]

On 11/3/21 11:03 AM, Andrei Alexandrescu wrote:
> On 2021-11-02 19:07, Paul Backus wrote:
>> On Tuesday, 2 November 2021 at 21:58:20 UTC, Andrei Alexandrescu wrote:
>>> On 2021-11-02 17:44, Dukc wrote:
>>>>
>>>>> What's a value range?
>>>>
>>>> Opposite of a reference range - copying implies `save()`.
>>>
>>> Yah, one simple improvement we could make is to assume all forward 
>>> ranges copy their iteration state when copying the range. Then input 
>>> ranges do NOT do that, i.e. all copies of an input range refer to the 
>>> same stream and iterate it together (advancing one advances all).
>>>
>>> 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.
> 
> Good point. Maybe have all ranges define that enum with values true and 
> false respectively?

Oh, and one more thing, if we are going to do a tag, a UDA is probably a 
more asthetic and functional tag. e.g. it doesn't affect 
`__traits(allMembers, T)`.

-Steve