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