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

[Ali Çehreli]

On 10/19/22 11:16, mw wrote:

 >> If I now decide to add @mustuse to Derived.fun, in the "derived"
 >> module, and we apply your proposed global analysis, this will cause a
 >> compilation error in the "doStuff" function in the "base" module!
 >>
 >> Note that the "base" module does not have any explicit dependency on
 >> the "derived" module. It does not import it, or otherwise refer to it
 >> in any way. In the real world, these two modules might even be in
 >> separate dub packages.
 >
 > Yes, I know that. But this in my view is still a compiler implementation
 > issue:

It is a human issue: Let's assume twenty developers have been using an 
Animal hierarchy. One day, Bertrand decides to add @mustuse to the new 
class Giraffe, a decendent of Animal. Now the code is broken all over 
the place.

Twenty developers chase Bertrand in and around the building until he/she 
removes @mustuse. (Commenting-out is acceptable as well.) Very human 
indeed... :o)

 > even in separate dub packages, as long as the compiler visit that
 > package, it need to propagate the attribute to that package's relevant
 > class.

The compiler does not and should not do anything like that. I can 
imagine the specification for compilers finding source code (of 
potentially pre-compiled libraries) and visiting all their source code 
would be very complicated and very different from @mustuse.

We started @mustuse as a simple concept of "this value must be used" and 
ended up with coming up with a whole new compilation system. Not 
practical... :)

All aside, I agree with the fact that @mustuse should somehow be 
per-function. If it were left to me, I would make it the default... 
which would annoy even myself because it would make quick-and-dirty 
prototype test code unnecessarily noisy. Perhaps a compiler switch to 
set the default behavior would work.

Ali