Forward ranges in Phobos v2

[H. S. Teoh]

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.


> - We add a function, let's say `std.range.valueRange`, in both
>   versions, that will convert any v1 forward range to a value range
>   that works in both versions.

What's a value range?


> - We also add some other function, or perhaps a flag to aforementioned
>   one, that can convert any v1 input ranges to v2 input range.
>   `valueRange` as default must not accept non-forward ranges, because
>   then it cannot guarantee that the result will be a value range.
[...]

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.


> - 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.
Now imagine mixing v1 algorithms and v2 algorithms in the same UFCS
chain (via shims) over a string, and you're in for a heck of time trying
to debug the resulting mess.

IMO it's better to just keep v1 code distinct from v2 code, and migrate
v1-based code to v2-based code on a case-by-case basis.  In most cases,
you could probably just change `import std` to `import stdv2` and it
should work.  In cases involving e.g. autodecoding you'd add an adapter
or two in your UFCS code, then change to `import stdv2` and that should
fix it.  For the rest of the cases, just leave `import std` as-is, and
existing code should still function as before, with existing semantics,
without any surprise breakages.


T

-- 
That's not a bug; that's a feature!