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

[mw]

On Wednesday, 19 October 2022 at 13:17:00 UTC, Paul Backus wrote:
>
> In other words, you cannot introduce `@mustuse` in a derived 
> class; it must be present in the base class.
>

I just realized that we two have different design motivations / 
goals: my goal is allow programmers to add @mustuse annotation to 
*any* methods that return values, and then make the whole thing 
work (to simulate Eiffel behavior to the max extent). So I need 
global analysis.

While your goal is to add @mustuse to method in such a way, which 
won't break current system (or with minimal impact), if the 
impact is too big, e.g conflict with prebuilt binary, then 
constraint the annotation in such a way that some of the 
annotations are not allowed to avoid the conflicts.


> This is somewhat problematic for D, because we have a universal 
> base class, `Object`, and neither it nor any of its methods are 
> `@mustuse`.

This is not a concern/problem at all, esp in your design goal, 
because your rule will prohibit adding such annotation to 
existing methods, e.g. Object.opEquals(); and for the methods 
that programmers do care, e.g. Paths.remove(i), there is no such 
method in Object.