Range Redesign: Empty Ranges

[Dukc]

On Wednesday, 6 March 2024 at 17:57:36 UTC, H. S. Teoh wrote:
> The problem is that .choose requires that both ranges are 
> constructible in the same scope that it is called in.

It's not even about those ranges being constructible. It's about 
separation of concerns. Like you wrote in your earlier post, 
sometimes we want to work with an arbitrary range without 
templating all of our code. Maybe for compile time reasons, or 
maybe to write a library that can be separately compiled from the 
client code.

> This makes .choose essentially useless outside of trivial cases.

It's far from useless, it's only like taking an enum argument and 
`switch`ing on it instead of taking a delerate argument. 
Certainly works but means you have to list all your cases in the 
function, which may or may not be what you want.


The gripe I have with `std.range.interface` is lack of attributes 
in the virtual functions. I don't think any simple attribute set 
alone would solve the problem well. Granted, there should rarely 
be reason to have a dynamic `@system` range type, but `pure` and 
`nothrow` are attributes you sometimes really want, sometimes you 
really don't. Therefore we need the ability to pick, meaning the 
interfaces will have to be templated, along the lines of:
```D
interface ForwardRange(uint attrs) : InputRange!attrs
{
    // ...
}
```

Plus there should probably be function to convert, for example, a
```
BidirectionalRange!(FunctionAttribute!safe | 
FunctionAttribute!pure_ | FunctionAttribute!nothrow_)
```
to
```
BidirectionalRange!(FunctionAttribute!safe | 
FunctionAttribute!nothrow_)
```
.