DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted

[Ola Fosheim Grøstad]

On Sunday, 6 February 2022 at 14:56:42 UTC, Paul Backus wrote:
> If you strongly prefer the lower-case version, you can always 
> rename it in your own code:
>
>     import core.attribute: mustuse = mustUse;

This response is getting a bit longwinded, and I really want this 
feature, but…

1. *Process*: I apologise for having missed the original DIP 
feedback thread. I understand that this retrospective feedback 
might be annoying and is easy to dismiss, but please consider 
making this feature as attractive as possible and let us focus on 
improving the language proper rather than shifting everything to 
the standard library where the threshold is lower?

2. *Renaming key features*: The renaming looks reasonable to me 
at the first glance, but when I think about it some more I think 
this will lead to a mess and make code less readable if many 
developers start doing this. I don't think programmers should be 
allowed to rename it at all! Maybe there should be a popularity 
vote for the syntax?

3. *The politics of language improvements*: I don't think this 
should be a library type. I think this feature is too important 
for that. To me this smells of let's move the syntax to a library 
to avoid any discussion about breaking changes. Design 
considerations should not become political, we need to get rid of 
politics and focus on principled strategies that makes the whole 
eco system attractive to more developers (the ones we don't have).

4. *Mandatory eco system*: How does the compiler recognize it? I 
hope it is by intrinsics and not by "symbol-path". That seems to 
be an import omission in the DIP, unless I overlooked it. For 
instance, if some sub-group of D programmers want grow their own 
independent niche-runtime-libary-combo, are they then free to 
write their own standalone hierarchy? Or is the standard library 
now taking over the introduction of language features in order to 
downplay politics?

5. *Make syntax pretty*: It would actually be better to just have 
this as part of the formal syntax with a non-attribute without 
the "@". One thing that makes D source code hard on the eyes is 
the "@" noise. The current parser is a bit primitive, but you can 
often accept terms in the syntax without making them keywords 
with a little bit of careful planning.

6. *Strategic positioning*: And yes, C++ syntax is becoming ugly 
too, but this is also why **making D pretty should be a strategic 
concern**! Can we afford to add more visual noise? I think not…