Forward ranges in Phobos v2

[Dukc]

On Tuesday, 2 November 2021 at 18:09:55 UTC, H. S. Teoh wrote:
> On Tue, Nov 02, 2021 at 12:11:24PM +0000, Dukc via 
> Digitalmars-d wrote:
>> On Tuesday, 2 November 2021 at 02:45:11 UTC, Andrei 
>> Alexandrescu wrote:
>> > 
>> > Exactly. No need to support class ranges - simple wrappers 
>> > can do everything class-like indirection does. Thanks.
>> 
>> Trying to write up a plan based on that one, so you can 
>> correct and/or spot weaknesses
>> 
>> - stuff in `std.v2.range.interfaces` and
>>   `std.v2.concurrency.Generator` will continue to be ranges 
>> from
>>   Phobos v1 viewpoint but not from Phobos v2 viewpoint.
>
> Why is this necessary?  I thought we're getting rid of 
> std.range.interfaces.

I quess we could write a more advanced alternative, but I'd 
prefer to keep the range interfaces around until someone does, to 
avoid scope creep.

The downside is going to be that Phobos v2 cannot use the 
interfaces directly as they aren't ranges anymore, but that's 
what the `valueRange` and the "other function" I mentioned are 
for.

> What's a value range?

Opposite of a reference range - copying implies `save()`.


>
> Interesting idea. So basically a shim for easy translation of 
> v1-based code to v2-based code?  That would be nice for gradual 
> migration.  It would have to exclude certain incompatible 
> things like autodecoded strings, though. Otherwise it will 
> result in a mess.

I propose that the shim will autodecode if imported from `v1` (if 
we even add it to `v1`) but not if imported from `v2` - just like 
the rest of the range-accepting functions.

>
>
>> - Phobos v2 ranges should still continue to provide the `save` 
>> method
>>   so they can be passed to v1 ranges.
> [...]
>
> I'm not sure this is such a good idea, because v2 ranges may 
> have fundamental incompatibilities with v1 algorithms, e.g., a 
> v2 string range (non-autodecoded) being passed to a v1 
> algorithm (autodecoded) will probably produce the wrong 
> results, likely silently, which is bad.

I agree that it's better to avoid function chains like that if 
easily possible. But the underlying rule is simple and 
unambiguous: a Phobos v1 function will autodecode a character 
array, a v2 function will not. If the character range is anything 
other than a plain array, they behave identically: the decoding 
or lack of thereof depends on the range itself.

Not worth to make the interoperability difficult just because of 
that IMO. If the users start having problems, they can 
voluntarily avoid mixing the character-handling `v1` and `v2` 
ranges - they still enjoy easier interoperability with other 
ranges.