Range Redesign: Empty Ranges

[Dukc]

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.

> 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?