Range Redesign: Empty Ranges

[Jonathan M Davis]

On Wednesday, March 6, 2024 3:54:54 PM MST Dukc via Digitalmars-d wrote:
> On Wednesday, 6 March 2024 at 21:24:59 UTC, Jonathan M Davis
>
> wrote:
> > 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.
>
> It's not a problem with classes, it's a decision one has to make
> when designing an interface with runtime variance regardless of
> the mechanism. You either have to allow the unknown code you're
> calling to execute side effects in which case it's impure, or you
> must execute the side effects it requests on it's behalf which
> means the unknown code must use your interfaces instead of doing
> their io themselves. It would be the same with any other
> mechanism.

Yes, it's a problem with non-templated code in general, but because you
can't templatize virtual functions, it's a problem with classes that you
can't really fix, whereas with most other code, you can usually fix it by
templatizing the code and inferring the attributes based on the arguments.

> > And what you're describing results in a proliferation of
> > interfaces, which to an extent, goes against the point of using
> > interfaces.
>
> I don't think so. Say, you're designing an interpreter, and
> decide the user-defined functions can't execute io directly or
> break D type system, but can throw exceptions. Therefore the D
> type for a range in your client langauge will be
> `ForwardRange!(ClientLangValue, FunctionAttribute.safe |
> FunctionAttribute.pure_)`. You need only one template instance,
> same as presently. How is this exactly proliferation?

It's a proliferation, because you're declaring a bunch of different
interfaces. Instead of having ForwardRange, you have a whole bunch of
variants of ForwardRange. Now, that might not end up being a problem in
practice (particularly since you do already have to templatize ForwardRange
on the element type), because you may only need one variation in your
codebase, but it does further complicate the interfaces, and it does mean
that interfaces with the same element type won't necessarily be compatible,
whereas with the current design, that isn't a problem.

So, it may ultimately be what we want to do, but it's not without its
downsides.

- Jonathan M Davis