Forward ranges in Phobos v2

H. S. Teoh hsteoh at quickfur.ath.cx
Mon Nov 1 14:13:00 UTC 2021


On Mon, Nov 01, 2021 at 01:51:32PM +0000, Dukc via Digitalmars-d wrote:
> It seems we're going to do Phobos v2. I don't know whether it will be
> the idea Andrei just published or something else, but anyway.
> 
> So I think it's the time to discuss, do we want to change the
> definition of forward ranges? It seems to be the
> [consensus](https://forum.dlang.org/thread/ztgtmumenampiobbuiwd@forum.dlang.org?page=1)
> that it's current API is error-prone to use correctly.
> 
> For example, we could define that a range that does not offer `save()`
> is still a forward range if it can be copy constructed, and that copy
> constructors for reference ranges would be forbidden. But one big
> problem with that: classes can not be ranges then.
> 
> At the very least, I think we must take the stance that all Phobos v2
> ranges must be save-on-copy where the documentation does not
> explicitly declare them reference ranges.
[...]

Based on what Andrei said in the past, there will no longer be .save
(which has always been a point of confusion in the API and interacts
poorly with the type system), but forward ranges will be based on
by-value semantics, and input ranges on by-reference semantics. So if
it's a by-value type, it's a forward range; if it's a by-reference type,
it's an input range.

If you have a struct but it only supports input range semantics, then
you could pass it by ref or pass a pointer to it.

If you have a class but it supports forward range semantics, then wrap
it in a struct with a copy ctor that saves state in the copy ctor.


T

-- 
Questions are the beginning of intelligence, but the fear of God is the beginning of wisdom.


More information about the Digitalmars-d mailing list