Conflicting attributes for virtual base class methods

Quirin Schroll qs.il.paperinik at gmail.com
Fri Aug 2 20:46:56 UTC 2024


Currently, functions can only carry one attribute of each 
category. Assuming there were an inverse for every attribute, the 
compiler wouldn't let you mark a function e.g. both `@system` and 
`@safe`.

What would that even mean?
- It would only be possible for function definitions, not 
prototypes.
- It enables the checks for the guarantee-making attribute, but 
be typed and mangled as lacking the guarantee-making attribute, 
e.g. a `@system @safe` function definition is checked for 
`@safe`, but is typed and mangled `@system`.

Why would you want this?
- Not often, sure, but for a virtual base class method, it makes 
sense. If it has a `@safe` implementation, having those checks 
enabled makes sense. Allowing derived classes to override it with 
a `@system` implementation also makes sense, but both together 
isn't possible.
- And if we're at it, if the base-class method is actually 
`@safe` (because it's provably checked for it), an overrider 
might just define a `@safe` override directly and be calling the 
base class method, non-virtually, rendering the call `@safe`. 
That would bind classes derived from that class to being `@safe`, 
but that's intended. And a non-trivial overrider may be `@system 
@safe` as well for the same reason.


More information about the dip.ideas mailing list