Command–query separation principle [re: @mustuse as a function attribute]

[Paul Backus]

On Wednesday, 19 October 2022 at 16:31:59 UTC, mw wrote:
> On Wednesday, 19 October 2022 at 13:17:00 UTC, Paul Backus 
> wrote:
>> 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.
>>
>
> Let's concentrate on only @mustuse as a function attribute for 
> now, since I have not checked the exact semantics of  @mustuse 
> as a type annotation.
>
>
> There are two directions to propagate the attribute in the 
> inheritance tree, upwards and downwards. We all agree on the 
> direction of downwards propagation to the derived class 
> methods, I.e in your expression: "may add `@mustuse`, but can 
> never remove it".

You have this completely backwards. A derived class may 
**remove** `@mustuse`, but can never **add** it.

In your example, attempting to add `@mustuse` to `Paths.remove` 
would result in a compile-time error:

```d
class AbstractPaths {
   AbstractPaths remove (int I) {...}
}


class Paths : AbstractPaths {
   @mustuse
   AbstractPaths remove (int I) {...}
   // Error: @mustuse method cannot override method without 
@mustuse
}
```