Proposed Changes to the Range API for Phobos v3

[Quirin Schroll]

On Thursday, 16 May 2024 at 14:56:55 UTC, Jonathan M Davis wrote:
> […]

Maybe good new names could be `empty`, `front`, and `opPopFront` 
for forward ranges, and `empty` and `opFrontThenPop` (or 
something).

Using `op…` makes sense as those functions get used by 
core-language constructs such as `foreach`. The reason `empty` 
and `front` aren’t `op…` is because those would often be called 
by programmers directly, and people would just define an alias 
anyway. One `op…` function suffices for a new interface.

As a matter of fact, `++range` could lower to 
`range.opPopFront()` or, if that is `void`, `(range.opPopFront(), 
range)` (comma operator). And `*range++` could lower to 
`range.opFrontThenPop`.

Another idea: For a forward range, `front` can be a field or 
property with a setter. The same can be true for input ranges’ 
`opFrontThenPop` which could be overloaded: If `opFrontThenPop()` 
is a getter for `front`, it’s an input range, and if there is 
`opFrontThenPop(rhs)` it’s an output range. Expressions of the 
form `*range++ = rhs` could lower to `opFrontThenPop(rhs)`.

If the names are too range-specific, they could be generalized to 
`opDereferenceUnary`, such that `*obj++` and `*obj--` lower to 
`opDereferenceUnary!"++"` and `opDereferenceUnary!"--"`, 
respectively.

If we go that path, a forward range could be defined by having 
`empty`, `front`, and supporting `++range` (which implements 
`popFront`); an input range be defined by having `empty` and 
supporting `*range++` (possibly by `opDereferenceUnary!"++"` that 
can be called with no arguments), and an output range could be 
defined by having `empty` and supporting `*range++ = rhs` 
(possibly by `opDereferenceUnary!"++"` that can be called with 1 
argument).