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?