Range Redesign: Empty Ranges

[Jonathan M Davis]

On Wednesday, March 6, 2024 1:53:55 PM MST Dukc via Digitalmars-d wrote:
> 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_)
> ```
> .

This is a fundamental problem with classes in general. Attributes just do
not play nicely with them. Either you're forced to require attributes that
potentially won't work for some code, or you're forced to disallow
attributes that some code might require.

And what you're describing results in a proliferation of interfaces, which
to an extent, goes against the point of using interfaces. So, we might do
something like that, but it does cause a different set of problems.

Regardless, we will have to look over exactly what we want to do with the
replacement for std.range.interfaces. I think that it was mostly thrown
together because it was thought that it was needed and not because it really
had been needed much at that point, and we should definitely look at what
needs reworking based on what we've learned in the interim. Classes in
general are kind of terrible with generic code in D though, particularly
because of the issues with attributes.

- Jonathan M Davis