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

[mw]

On Wednesday, 19 October 2022 at 07:41:33 UTC, mw wrote:
> On Wednesday, 19 October 2022 at 07:28:21 UTC, Mike Parker 
> wrote:
>> On Wednesday, 19 October 2022 at 04:52:31 UTC, mw wrote:
>>
>>> @mustuse as a function attribute was in the original version 
>>> of the DIP. It was vetoed by Walter. Thus, only the type 
>>> attribute remains in the accepted version.
>>>
>>
>> Please include the entire context that I posted earliar from 
>> the summary of the formal assessment here:
>>
>> https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1038.md#formal-assessment
>>
>> Walter didn't just willy-nilly "veto" the attribute on 
>> functions. He accepted the proposal with three requests for 
>> enhancement, one of which I summarized as:
>>
>>> develop rules for handling covariance and contravariance when 
>>> applied to functions.
>
> Covariance and contravariance is a big topic by itself.
> But ..., what does it have anything to do here with @mustuse as 
> a function attribute?
>
> @mustuse here only enforces there must be a receiver of the 
> function call result, and do not throw away the returned result.
>
> I'd really like to see some examples what's this concern is 
> about.

I read the above link again, esp these:

2) address issues that arise from the feature's interaction with 
inheritance when applied to classes.

3) develop rules for handling covariance and contravariance when 
applied to functions.


And I think, 3) is talking about 2) about types!

In short: it's about the @mustuse annotation on types! -- the 
accepted half of the DIP!

Actually, it's the other half I.e @mustuse annotation on function 
should be accepted! since it has nothing to do with covariance 
and contravariance.

And the accepted half on types should be addressed with 3).