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…
