Command–query separation principle [re: @mustuse as a function attribute]
Paul Backus
snarwin at gmail.com
Wed Oct 19 13:17:00 UTC 2022
On Wednesday, 19 October 2022 at 08:35:21 UTC, mw wrote:
> On Wednesday, 19 October 2022 at 08:29:20 UTC, mw wrote:
>> OK, I saw what they are talking about.
>>
>>
>> Basically, in Eiffel, all query @mustuse.
>>
>> Here in D @mustuse is an remedy add-on, which can be specified
>> by the programmers in the middle of the inheritance tree, the
>> question is what if the pointers got casted either upwards or
>> downwards?
>>
>> (It's too late for me here today.)
>>
>
> My gut feeling is: make it simple, if a method is marked as
> @mustuse anywhere in the inheritance tree, that method in all
> the class levels of the inheritance tree became @mustuse!
The correct rule is exactly what Mike quoted from my email
discussion with Walter: implicit conversions may add `@mustuse`,
but can never remove it.
From this, it follows that
* a `@mustuse` method cannot override a non-`@mustuse` method.
* a `@mustuse` class/interface cannot inherit from a
non-`@mustuse` class/interface.
In other words, you cannot introduce `@mustuse` in a derived
class; it must be present in the base class.
This is somewhat problematic for D, because we have a universal
base class, `Object`, and neither it nor any of its methods are
`@mustuse`.
More information about the Digitalmars-d
mailing list