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