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

[mw]

On Wednesday, 19 October 2022 at 18:01:42 UTC, H. S. Teoh wrote:
> On Wed, Oct 19, 2022 at 05:40:00PM +0000, mw via Digitalmars-d 
> wrote:
> It saves a few keystrokes but introduces long-distance implicit 
> relationships between distant pieces of code (i.e., 
> Derive3.remove being marked @mustuse implicitly causes 
> Derived1.remove to be @mustuse, but the latter is not 
> represented in the source code). This makes the code hard to 
> understand and reduces maintainability.
>
> Rather, the correct approach should be that all instances of 
> .remove should be *explicitly* marked @mustuse in the source 
> code. It should be a compile error for some instances of 
> .remove to be marked @mustuse and others not marked.

Conceptually I agree  about the *explicitly* part. My only 
concern is that as in Paul Backus' example the classes are in 
separate dub packages that the programmer has *no* control with, 
e.g. the programmer decided to derived from one of the unmarked 
std.lib class, and added @mustuse mark to a method in his derived 
class, s/he will not be able to manually change the std.lib class 
source code to add @mustuse explicitly.

But for the @mustuse logic to be correct, the compiler need to 
internally propagate to the base std.lib classes.

And yes, I know this global analysis view will have conflict with 
the current compilation & build process.