Congratulations to Paul Backus. DIP 1038, "@mustUse" has been accepted after he implemented changes to address concerns from Walter.

https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1038.md

During the Formal Assessment, Walter and Paul discussed a few aspects of the original proposal that Walter felt needed to be addressed. I will summarize them here. Please refer to the section of the DIP titled 'Design Goals and Possible Alternatives' for the rationale behind Paul's decisions regarding points 2 and 3 below.

The TL;DR: the attribute is now called @mustUse and it only applies to structs and unions.

1. @noDiscard is a negative, and though we have nothrow and @noGC, Walter has come to believe that negatives are suboptimal from a "human factors perspective". He noted that must_use in Rust is the right idea, and suggested Paul change @noDiscard to @use. Paul opted to go with @mustUse instead on the grounds that @use is too short and difficult to search for.

2. The original proposal allowed the attribute to apply to classes and interfaces. Walter offered examples of where it can cause problems when applied to classes and requested that Paul address these cases in the DIP. Ultimately, Paul opted to disallow the attribute on classes.

3. The original proposal allowed the attribute to apply to functions. Walter requested that Paul develop rules for covariance and contravariance, with would apply to function overloading, function overriding, function parameters, and implicit conversions. Ultimately, Paul opted to disallow the attribute on functions.

I want to reiterate that the above is only a summary. Paul and Walter exchanged multiple emails in discussion of these issues, with both proposing ideas to solve them. Paul does an excellent job describing his rationale for only allowing the attribute on structs in the section I noted above.

The final form of this DIP does not preclude future expansion of the feature to allow it on classes and functions. Paul has noted elsewhere that Rust took the similar approach in that must_use was only allowed on types initially and expanded to include functions later.

Anyone interested in writing a DIP for such expansion of the feature should certainly consult with Walter beforehand for a more thorough overview on what must be accounted for.

On Friday, 28 January 2022 at 13:07:13 UTC, Mike Parker wrote:

Congratulations! (And thank you everyone involved in the discussions and feedback.)

Well done Paul. I appreciate the clarity, simplicity and utility.

On Friday, 28 January 2022 at 13:07:13 UTC, Mike Parker wrote:

So this explains why the DIP lingered so long in formal assessment. I think the reason for the delay is good in itself, but it would have been better to update us a bit more on why the assessment is taking so long. From the outside it seemed it's likely forgotten.

Anyway, kudos for finally getting all settled!

On Wednesday, 2 February 2022 at 21:23:16 UTC, Dukc wrote:

No, that wasn’t the reason for the delay. Delays in the DIP process always come down to someone waiting for a response from someone else. Everyone involved has multiple priorities, so when the next move comes down to any one person, it will happen when that person is ready to make it happen.

In this case, Walter took much longer than usual to get to his initial review. I’ve set a 30-day window for this, but this time he went over. The email discussions with Paul happened over a relatively short period. Then there was a long delay while we waited for Paul to get the changes made. I was busy enough that I put all DIPs out of mind for a while, so I wasn’t pinging him asking for an update.

And this is not a fault with Paul. This happens with nearly every DIP. All of the DIPs that have begun the process and are currently in the queue are stalled waiting for the authors to tell me they’re ready to move to the next round. I ping them periodically, and eventually they’ll be ready.

In any case, if there’s no news on a DIP, it’s almost always because someone is waiting on someone else. If I’m not the reason someone is waiting, then the only update I would ever be able to give is “we’re waiting”.

On Wednesday, 2 February 2022 at 22:58:39 UTC, Mike Parker wrote:

An honest explaination.

Not Pauls fault nor yours. Were all more or less busy and/or lazy.

Which would tell that it's not forgotten. You're technically right, what would we do with the information that a DIP is not (or is) forgotten? Perhaps ping sometimes ourselves but that's it.

But I think it still might have a bit morale value to do that "we're waiting" update if a formal assesment misses that 30-day window you mentioned, for instance. May be just my taste, though.

On Friday, 28 January 2022 at 13:07:13 UTC, Mike Parker wrote:

Update for anyone following this: a PR implementing DIP 1038 has been submitted, and is currently awaiting Walter's approval.

https://github.com/dlang/dmd/pull/13589

On Thursday, 3 February 2022 at 17:25:16 UTC, Paul Backus wrote:

Guess I'm way too late, I just find it very strange you settled on mixedCase, it's not used for anything else. (nothrow @nogc). I also don't agree with the motivation that @use is hard to search for because @ is an unusual symbol.

Both these suggestions are better imho.
@use
@mustuse

Still congratulations, I guess the most important part is that we get the feature... I'm just very surprised, is all.

On Sunday, 6 February 2022 at 10:55:20 UTC, Daniel N wrote:

@mustUse is a user-defined attribute, and the official style guide says that names of UDAs should be camelCased:

https://dlang.org/dstyle.html#naming_udas

"Hard to search for" in this context means "hard to Google for", not "hard to grep for". Search engines tend to ignore symbols like @.