www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DIP 1038--" mustUse" (formerly " noDiscard")--Accepted

reply Mike Parker <aldacron gmail.com> writes:
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](https://github.com/dlang/DIPs/blob/master/DIPs/DIP1038.md#design-goals-and-pos
ible-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](https://github.com/dlang/DIPs/blob/master/DIPs/DIP1038.md#design-goals-and-possible-alternatives).

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.
Jan 28
next sibling parent M.M. <matus email.cz> writes:
On Friday, 28 January 2022 at 13:07:13 UTC, Mike Parker wrote:
 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
 ...
Congratulations! (And thank you everyone involved in the discussions and feedback.)
Jan 28
prev sibling next sibling parent Bruce Carneal <bcarneal gmail.com> writes:
Well done Paul.  I appreciate the clarity, simplicity and utility.
Jan 28
prev sibling next sibling parent reply Dukc <ajieskola gmail.com> writes:
On Friday, 28 January 2022 at 13:07:13 UTC, Mike Parker wrote:
 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](https://github.com/dlang/DIPs/blob/master/DIPs/DIP1038.md#design-goals-and-possible-alternatives).
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!
Feb 02
parent reply Mike Parker <aldacron gmail.com> writes:
On Wednesday, 2 February 2022 at 21:23:16 UTC, Dukc 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.
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”.
 Anyway, kudos for finally getting all settled!
Feb 02
parent Dukc <ajieskola gmail.com> writes:
On Wednesday, 2 February 2022 at 22:58:39 UTC, Mike Parker 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.
An honest explaination.
 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.
Not Pauls fault nor yours. Were all more or less busy and/or lazy.
 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”.
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.
Feb 03
prev sibling next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Friday, 28 January 2022 at 13:07:13 UTC, Mike Parker wrote:
 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
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
Feb 03
parent reply Daniel N <no public.email> writes:
On Thursday, 3 February 2022 at 17:25:16 UTC, Paul Backus wrote:
 On Friday, 28 January 2022 at 13:07:13 UTC, Mike Parker wrote:
 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
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
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.
Feb 06
parent reply Paul Backus <snarwin gmail.com> writes:
On Sunday, 6 February 2022 at 10:55:20 UTC, Daniel N 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.
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 .
Feb 06
next sibling parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Sunday, 6 February 2022 at 13:33:53 UTC, Paul Backus wrote:
 On Sunday, 6 February 2022 at 10:55:20 UTC, Daniel N 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.
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 .
... This matches conventions of the built in attributes like safe, __ nogc__ ...
Feb 06
parent reply Paul Backus <snarwin gmail.com> writes:
On Sunday, 6 February 2022 at 13:40:00 UTC, Paolo Invernizzi 
wrote:
 On Sunday, 6 February 2022 at 13:33:53 UTC, Paul Backus 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
... This matches conventions of the built in attributes like safe, __ nogc__ ...
Presumably this is referring to the part about the first letter being lower-case, since the built-in attributes are quite obviously not camelCased.
Feb 06
parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Sunday, 6 February 2022 at 14:00:15 UTC, Paul Backus wrote:
 On Sunday, 6 February 2022 at 13:40:00 UTC, Paolo Invernizzi 
 wrote:
 On Sunday, 6 February 2022 at 13:33:53 UTC, Paul Backus 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
... This matches conventions of the built in attributes like safe, __ nogc__ ...
Presumably this is referring to the part about the first letter being lower-case, since the built-in attributes are quite obviously not camelCased.
While I like a lot and welcome the addition of this attribute (so thank you!), I humbly ask to reconsider using the full lowercase alternative instead of camel case. Let's conform with the other built-in attributes listed into the specs of the language, avoiding what would be another special case to remember.
Feb 06
parent reply Paul Backus <snarwin gmail.com> writes:
On Sunday, 6 February 2022 at 14:32:31 UTC, Paolo Invernizzi 
wrote:
 While I like a lot and welcome the addition of this attribute 
 (so thank you!), I humbly  ask to reconsider using   the full 
 lowercase alternative instead of camel case.

 Let's conform with the other built-in attributes listed into 
 the specs of the language, avoiding what would be another 
 special case to remember.
There is precedent for compiler-recognized UDAs using camelCase in core.attribute.gnuAbiTag [1], as well as the various LDC-specific attributes [2]. So no matter what I choose here, it will be inconsistent with something. If you strongly prefer the lower-case version, you can always rename it in your own code: import core.attribute: mustuse = mustUse; mustuse struct MyStruct { // ... } [1]: https://druntime.dpldocs.info/core.attribute.gnuAbiTag.html [2]: https://wiki.dlang.org/LDC-specific_language_changes#Attributes
Feb 06
next sibling parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Sunday, 6 February 2022 at 14:56:42 UTC, Paul Backus wrote:
 On Sunday, 6 February 2022 at 14:32:31 UTC, Paolo Invernizzi 
 wrote:
 While I like a lot and welcome the addition of this attribute 
 (so thank you!), I humbly  ask to reconsider using   the full 
 lowercase alternative instead of camel case.

 Let's conform with the other built-in attributes listed into 
 the specs of the language, avoiding what would be another 
 special case to remember.
There is precedent for compiler-recognized UDAs using camelCase in core.attribute.gnuAbiTag [1], as well as the various LDC-specific attributes [2]. So no matter what I choose here, it will be inconsistent with something. If you strongly prefer the lower-case version, you can always rename it in your own code: import core.attribute: mustuse = mustUse; mustuse struct MyStruct { // ... } [1]: https://druntime.dpldocs.info/core.attribute.gnuAbiTag.html [2]: https://wiki.dlang.org/LDC-specific_language_changes#Attributes
That's fine, I will not insist more, hoping not to see in the future it extended as a function attribute ... you know ... int foo() nogc safe mustUse etc etc ...
Feb 06
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
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…
Feb 06
parent reply Dukc <ajieskola gmail.com> writes:
On Sunday, 6 February 2022 at 15:43:39 UTC, Ola Fosheim Grøstad 
wrote:
 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).
This is a disrespectful comment. You're implying that your opinion is rational and apolitical, disagreeing with it is irrational politics. It is true that no decisions are fully politics-free, but please don't pretend that you are above all others here in that regard.
Feb 09
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 9 February 2022 at 10:59:03 UTC, Dukc wrote:
 You're implying that your opinion is rational and apolitical, 
 disagreeing with it is irrational politics.
I am implying that there are many symptoms of people not being willing to champion the best possible design and instead have started to look for what they think is easy to get through. I see that in this DIP, in other DIPs and in comments about DIPs people are contemplating. The accumulated outcome of such political design processes are usually not great. I will later try to create a separate thread for this, as Paul does not want this topic in this thread.
Feb 09
prev sibling next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 6 February 2022 at 13:33:53 UTC, Paul Backus wrote:
 On Sunday, 6 February 2022 at 10:55:20 UTC, Daniel N 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.
mustUse is a user-defined attribute, and the official style guide says that names of UDAs should be camelCased:
It is kinda confusing to call it a user-defined attribute if it is recognized by the compiler. I dislike the camel case as well, and the name is less clear than "nodiscard" in my opinion.
Feb 06
parent reply Paul Backus <snarwin gmail.com> writes:
On Sunday, 6 February 2022 at 14:44:40 UTC, Ola Fosheim Grøstad 
wrote:
 On Sunday, 6 February 2022 at 13:33:53 UTC, Paul Backus wrote:
  mustUse is a user-defined attribute, and the official style 
 guide says that names of UDAs should be camelCased:
It is kinda confusing to call it a user-defined attribute if it is recognized by the compiler.
Compiler-recognized UDAs are an established feature of D. See [`core.attribute`][1] for more examples.
 I dislike the camel case as well, and the name is less clear 
 than "nodiscard" in my opinion.
I suppose you'll have to take that up with Walter, since he's the one who vetoed "nodiscard". To be honest, though, I can see where he's coming from. When writing DIP 1038, I made a conscious effort to avoid using the term "non-` nodiscard`", due to the double negative. With a positively-phrased name like ` mustUse`, that problem disappears. [1]: https://druntime.dpldocs.info/core.attribute.html
Feb 06
next sibling parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Sunday, 6 February 2022 at 15:17:35 UTC, Paul Backus wrote:
 On Sunday, 6 February 2022 at 14:44:40 UTC, Ola Fosheim Grøstad 
 wrote:
 On Sunday, 6 February 2022 at 13:33:53 UTC, Paul Backus wrote:
  mustUse is a user-defined attribute, and the official style 
 guide says that names of UDAs should be camelCased:
It is kinda confusing to call it a user-defined attribute if it is recognized by the compiler.
Compiler-recognized UDAs are an established feature of D. See [`core.attribute`][1] for more examples.
 I dislike the camel case as well, and the name is less clear 
 than "nodiscard" in my opinion.
I suppose you'll have to take that up with Walter, since he's the one who vetoed "nodiscard". To be honest, though, I can see where he's coming from. When writing DIP 1038, I made a conscious effort to avoid using the term "non-` nodiscard`", due to the double negative. With a positively-phrased name like ` mustUse`, that problem disappears. [1]: https://druntime.dpldocs.info/core.attribute.html
hold (or held) ? donwannaopenacanofworms ... my last post really :-P (btw, It's a great companion for sumtype! thank you again!)
Feb 06
parent Paul Backus <snarwin gmail.com> writes:
On Sunday, 6 February 2022 at 15:24:17 UTC, Paolo Invernizzi 
wrote:
  hold (or  held) ? donwannaopenacanofworms ... my last post 
 really :-P
Pretend that you are a beginning D programmer, and you come across one of the following declarations while reading someone else's code: use struct Result { // ... } hold struct Result { // .. } mustUse struct Result { // ... } You have never seen any of these attributes before in your life, and there are no comments explaining what they mean--all you have to go on is the name. Which name is are you most likely to guess the correct meaning for: "use", "hold", or "mustUse"?
Feb 06
prev sibling next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 6 February 2022 at 15:17:35 UTC, Paul Backus wrote:
 On Sunday, 6 February 2022 at 14:44:40 UTC, Ola Fosheim Grøstad 
 wrote:
 On Sunday, 6 February 2022 at 13:33:53 UTC, Paul Backus wrote:
  mustUse is a user-defined attribute, and the official style 
 guide says that names of UDAs should be camelCased:
It is kinda confusing to call it a user-defined attribute if it is recognized by the compiler.
Compiler-recognized UDAs are an established feature of D. See [`core.attribute`][1] for more examples.
I don't need those? So hence I don't care… This feature you are proposing with this DIP is a *very important one* in my view, and I would use it almost everywhere.
Feb 06
parent reply Paul Backus <snarwin gmail.com> writes:
On Sunday, 6 February 2022 at 15:46:47 UTC, Ola Fosheim Grøstad 
wrote:
 On Sunday, 6 February 2022 at 15:17:35 UTC, Paul Backus wrote:
 On Sunday, 6 February 2022 at 14:44:40 UTC, Ola Fosheim 
 Grøstad wrote:
 It is kinda confusing to call it a user-defined attribute if 
 it is recognized by the compiler.
Compiler-recognized UDAs are an established feature of D. See [`core.attribute`][1] for more examples.
I don't need those? So hence I don't care… This feature you are proposing with this DIP is a *very important one* in my view, and I would use it almost everywhere.
My point is that "I'm confused because I haven't read the documentation" is a very different complaint from "I'm confused because this feature is inherently confusing." ` mustUse` will be documented in both the language spec ([PR][1]) and the DDoc for core.attribute ([PR][2]). If you're still confused *after* you've read the documentation, feel free to come back and complain to me then. [1]: https://github.com/dlang/dlang.org/pull/3201 [2]: https://github.com/dlang/druntime/pull/3712
Feb 06
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 6 February 2022 at 15:51:46 UTC, Paul Backus wrote:
 If you're still confused *after* you've read the documentation, 
 feel free to come back and complain to me then.
What I stated has nothing to do with documentation. I think the semantics are too important to be a "linter-feature". I also think C++ made a "mistake" by using an attribute for it.
Feb 06
parent reply Paul Backus <snarwin gmail.com> writes:
On Sunday, 6 February 2022 at 16:01:15 UTC, Ola Fosheim Grøstad 
wrote:
 On Sunday, 6 February 2022 at 15:51:46 UTC, Paul Backus wrote:
 If you're still confused *after* you've read the 
 documentation, feel free to come back and complain to me then.
What I stated has nothing to do with documentation.
What you stated was, and I quote:
 It is kinda confusing to call it a user-defined attribute if it 
 is recognized by the compiler.
My reply was directed towards that specific statement, and only that statement. I did not reply (and do not intend to reply) to any of the numerous other statements you have made in your other replies to this thread, since they are statements about the design of the D language and the DIP process in general, and are not directly relevant to DIP 1038.
Feb 06
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 6 February 2022 at 16:20:07 UTC, Paul Backus wrote:
 I did not reply (and do not intend to reply) to any of the 
 numerous other statements you have made in your other replies 
 to this thread, since they are statements about the design of 
 the D language and the DIP process in general, and are not 
 directly relevant to DIP 1038.
Well, but it is relevant to the outcome. In C++ I find that the more are strive to write semantically beautiful code, the less visually beautiful it becomes. My modern C++ code is littered with ```[[nodiscard]]``` and other attributes. If a language that is equally capable allows me to write code that is both semantically beautiful and visually beautiful then that would offset some of the disadvantages with using a small language. I think many C++ programmers feel that way. Big opportunity that is up for grabs there.
Feb 06
parent reply Paul Backus <snarwin gmail.com> writes:
On Sunday, 6 February 2022 at 17:07:46 UTC, Ola Fosheim Grøstad 
wrote:
 On Sunday, 6 February 2022 at 16:20:07 UTC, Paul Backus wrote:
 I did not reply (and do not intend to reply) to any of the 
 numerous other statements you have made in your other replies 
 to this thread, since they are statements about the design of 
 the D language and the DIP process in general, and are not 
 directly relevant to DIP 1038.
Well, but it is relevant to the outcome.
Let me rephrase: I do not understand why you feel the need to direct these messages at me, personally. I am not a member of the D Language Foundation, and have no particular influence over the DIP process or the design of the D language. If you have ideas or concerns you wish to present to D's leadership, my advice is to either (a) write a DIP, or (b) get in touch with Mike Parker about attending one of the D Language Foundation's monthly meetings (see the bottom of [his latest meeting summary post][1] for details). [1]: https://forum.dlang.org/post/tesktfsmdglmzbhzypsx forum.dlang.org
Feb 06
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 6 February 2022 at 19:14:50 UTC, Paul Backus wrote:
 Let me rephrase: I do not understand why you feel the need to 
 direct these messages at me, personally.
I am sorry if you felt I was addressing you personally. That was not intended, maybe bad phrasing on my part. (I tend to send email when addressing people personally! :-) I am more trying to convey what I see has gone wrong in the "modern C++" design department to "the community" in some hope that D can do better. But right now it seems like "C++ did this" is treated like a validation, rather than a warning. " mustUse" will literally be on every single function that I write that returns something… because it is almost always a bug to ignore a return value! In summary: This feature deserves a higher priority than library status.
 If you have ideas or concerns you wish to present to D's 
 leadership, my advice is to either (a) write a DIP, or (b) get 
 in touch with Mike Parker about attending one of the D Language 
 Foundation's monthly meetings (see the bottom of [his latest 
 meeting summary post][1] for details).
Yes, I am considering a DIP on parametric-aliases at least, where I think C++ currently has an edge. Thanks for tipping me about those meetings, I didn't know one could apply for participation. That might be a possibility in the future, although I think I probably should try to find time to participate in those beer-meetings first to get a rough idea of what is achievable. No point in going to a formal meeting without knowing what the terrain is like. :-)
Feb 06
parent reply Paul Backus <snarwin gmail.com> writes:
On Sunday, 6 February 2022 at 20:45:20 UTC, Ola Fosheim Grøstad 
wrote:
 On Sunday, 6 February 2022 at 19:14:50 UTC, Paul Backus wrote:
 Let me rephrase: I do not understand why you feel the need to 
 direct these messages at me, personally.
I am sorry if you felt I was addressing you personally. That was not intended, maybe bad phrasing on my part. (I tend to send email when addressing people personally! :-) I am more trying to convey what I see has gone wrong in the "modern C++" design department to "the community"
You've been replying directly to my posts. If you intended to direct your messages at "the community" in general, rather than at me specifically, you should have started a new thread. As is, with these messages buried several pages deep in a thread about a different topic, most members of "the community" are unlikely to ever even read them in the first place.
Feb 06
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 6 February 2022 at 20:52:21 UTC, Paul Backus wrote:
 If you intended to direct your messages at "the community" in 
 general, rather than at me specifically, you should have 
 started a new thread. As is, with these messages buried several 
 pages deep in a thread about a different topic, most members of 
 "the community" are unlikely to ever even read them in the 
 first place.
Good point. I will reread Robert's post on strategy and think about this for a while and write a more visible post when I have something that captures both Robert's concerns and concerns related to system level programming. That said, I really wish you had talked more with C++ programmers who make use of modern C++ before writing the DIP. I am personally so used to adding ```[[nodiscard]]``` on all functions that it has become second nature. It is a very valuable feature in regards to refactoring I think, but also the most ill-conceived design in modern C++ (that I use). I might as well do a ```#define func [[nodiscard]]```.
Feb 06
prev sibling next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 6 February 2022 at 15:17:35 UTC, Paul Backus wrote:
 To be honest, though, I can see where he's coming from. When 
 writing DIP 1038, I made a conscious effort to avoid using the 
 term "non-` nodiscard`", due to the double negative. With a 
 positively-phrased name like ` mustUse`, that problem 
 disappears.
And while I am at it, let me commit heresy by proclaiming that this feature is so important that I think it should be the default and that programmers should instead specify that the result is "discardable". That would of course be a terrible-terrible-terrible-breaking-change, and would never fly in the current political climate. But in general: D would become more interesting as a language if we could muster the guts to be different.
Feb 06
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/6/2022 7:17 AM, Paul Backus wrote:
 To be honest, though, I can see where he's coming from. When writing DIP 1038,
I 
 made a conscious effort to avoid using the term "non-` nodiscard`", due to the 
 double negative. With a positively-phrased name like ` mustUse`, that problem 
 disappears.
Andrei once asked me for scientific evidence that negations are cognitively more difficult for human brains to understand. I didn't have it at the time, but did eventually find it and forwarded it to Andrei, who was satisfied with it. I didn't keep a copy, though. It's not just my opinion that negations are to be avoided, there's research justifying it. I remember back in the olden daze when I was designing digital logic circuits that using NAND and NOR gates would cause me endless confusion. I eventually decided to design with AND and OR gates, then mechanically convert them to NAND and NOR using deMorgan's Theorem. NANDs and NORs require fewer transistors to function, so are preferred. This was later built into the ABEL programming language that I designed for Data I/O. ABEL was used to burn logic equations into programmable logic devices. It had a pass that converted everything to NANDs and NORs. Positive logic in computer code, however, has no such penalty. Hence I try to write code that eschews negative logic. Anytime you find yourself writing not-nohow, not-noway, etc., it's time to redesign the state of the variables. Try to organize logic so ! is not necessary. I mean, try to organize logic so ! is absent.
Feb 07
next sibling parent forkit <forkit gmail.com> writes:
On Monday, 7 February 2022 at 23:38:11 UTC, Walter Bright wrote:
 Andrei once asked me for scientific evidence that negations are 
 cognitively more difficult for human brains to understand. I 
 didn't have it at the time, but did eventually find it and 
 forwarded it to Andrei, who was satisfied with it. I didn't 
 keep a copy, though.

 It's not just my opinion that negations are to be avoided, 
 there's research justifying it.
 ..
I certainly don't discount such research. However, I expect there is also research that says something different ;-) Also, I expect you're talking about linguistics, and not programming languages. Truths may hold in one, and not other. Regardless, the research I am familiar with, tells me that we are psychologically biased towards cognitive schemas that we already hold. Changing ones cognitive schemas is not effortless, and, since D is very much focused on attracting programmers from the C++ world, the existing schemas those users hold should always be factored into ones thinking when implementing change in D.
Feb 07
prev sibling parent reply forkit <forkit gmail.com> writes:
On Monday, 7 February 2022 at 23:38:11 UTC, Walter Bright wrote:
 Anytime you find yourself writing not-nohow, not-noway, etc., 
 it's time to redesign the state of the variables. Try to 
 organize logic so ! is not necessary. I mean, try to organize 
 logic so ! is absent.
But sometimes that requires too much effort ;-) e.g. !debug { do this } My brain decided this form of logic without me really thinking at all. Now I have to 'rethink', in order to find the correct form of that logic that doesn't require the use of ! nodiscard is better than mustuse for the same reason. Suppose I don't want to 'use it'. That should be allowed, as long as I don't discard it. With mustuse, I'm being told I can't discard it, and that i must use it.
Feb 07
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/7/2022 5:10 PM, forkit wrote:
 Suppose I don't want to 'use it'. That should be allowed, as long as I don't 
 discard it. With mustuse, I'm being told I can't discard it, and that i must
use 
 it.
Sorry, all those negations made my brain explode. P.S. English has examples of negation issues, such as: "I could care less." which makes no sense at all, until you realize it's just a shortened version of "I couldn't care less." The addition or subtraction of the negation does not change the meaning, as the brain doesn't do a good job recognizing it. The phrases "not no-way", and "not no-how" use multiple negations to emphasize, rather than negate.
Feb 07
parent reply forkit <forkit gmail.com> writes:
On Tuesday, 8 February 2022 at 01:25:52 UTC, Walter Bright wrote:
 Sorry, all those negations made my brain explode.

 P.S. English has examples of negation issues, such as:

 "I could care less."

 which makes no sense at all, until you realize it's just a 
 shortened version of "I couldn't care less." The addition or 
 subtraction of the negation does not change the meaning, as the 
 brain doesn't do a good job recognizing it.

 The phrases "not no-way", and "not no-how" use multiple 
 negations to emphasize, rather than negate.
I often say to my cat 'what are you doing' .. but what i really mean is 'don't do that'. by avoiding negation, I'm probably just confusing my cat as to what i really meant. mustuse -> I must use it? Why must i use it? How must I use it? What happens if i don't use it. nodiscard -> don't discard it. nice and simple (just like 'don't do that').
Feb 07
parent reply forkit <forkit gmail.com> writes:
On Tuesday, 8 February 2022 at 01:40:38 UTC, forkit wrote:
 I often say to my cat 'what are you doing' .. but what i really 
 mean is 'don't do that'.

 by avoiding negation, I'm probably just confusing my cat as to 
 what i really meant.

 mustuse -> I must use it? Why must i use it? How must I use it? 
 What happens if
 i don't use it.

 nodiscard -> don't discard it. nice and simple (just like 
 'don't do that').
I guess the question really is: What it the most important concept you are relaying to the programmer by the use of that term? That they 'must use it'. Or, that they 'cannot discard it'. They seem like two different concepts to me. I don't believe that using nodiscard in C++, means you must use it. If in D, it means you must use it, then 'mustuse' makes more sense. If not, then stick with what people already know, is my advice.
Feb 07
next sibling parent forkit <forkit gmail.com> writes:
On Tuesday, 8 February 2022 at 01:53:17 UTC, forkit wrote:

also, the use of the word 'must' in any programming language, 
needs careful consideration.

'mustuse' has the potential to invite mass 'mustuse' 
demonstrations!

'nodiscard' suggests somewhat more 'autonomy', and would achieve 
a more-or-less similiar outcome.
Feb 07
prev sibling parent reply claptrap <clap trap.com> writes:
On Tuesday, 8 February 2022 at 01:53:17 UTC, forkit wrote:
 On Tuesday, 8 February 2022 at 01:40:38 UTC, forkit wrote:

 If in D, it means you must use it, then 'mustuse' makes more 
 sense.

 If not, then stick with what people already know, is my advice.
Probably noignore would be a better name. You're not really trying to dictate what people do with the result, just that they dont ignore it.
Feb 08
parent forkit <forkit gmail.com> writes:
On Tuesday, 8 February 2022 at 21:28:06 UTC, claptrap wrote:
 Probably  noignore would be a better name. You're not really 
 trying to dictate what people do with the result, just that 
 they dont ignore it.
I'd like to see an option to annotate such an attribute. Something like this: mustuse("or else this could occur") Then the compiler could return that message, rather than some generic message that provides no real insight into why that attribute was used in the first place. Similar to C++20's: [[nodiscard("check if not null")]])
Feb 08
prev sibling parent reply Daniel N <no public.email> writes:
On Sunday, 6 February 2022 at 13:33:53 UTC, Paul Backus wrote:
 On Sunday, 6 February 2022 at 10:55:20 UTC, Daniel N 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.
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 .
If you just google for "dlang attributes" you should be able to find what you search for, regardless of what it is called, thus personally I think greppability is the only thing we have to cater for. If the attribute is in core or truly built-in feels like an implementation detail, if nogc was created today, it also probably would have been listed in core.attribute. By using a different naming convention we actually block refactoring/cleanup of the frontend by moving build-in attributes to the core.attribute. However by choosing "use" we could avoid the entire discussion about which case to use... Best Regards, Daniel N
Feb 06
parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/6/2022 7:14 AM, Daniel N wrote:
 However by choosing "use" we could avoid the entire discussion about which
case 
 to use...
"mustuse" is much more greppable.
Feb 07
prev sibling parent reply forkit <forkit gmail.com> writes:
On Friday, 28 January 2022 at 13:07:13 UTC, Mike Parker wrote:

my only concern is the capital U, in  mustUse

This seems a little inconsistent with current attributes??

e.g:

nogc
nothrow
inout

https://dlang.org/spec/attribute.html

also, nodiscard would actually seem more logical, given the above 
as well.

I bet you, people will be thinking nodiscard, but will have to 
remember to type,  mustuse, only to have the compiler complain, 
that its' actually  mustUse
Feb 06
next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Monday, 7 February 2022 at 05:05:27 UTC, forkit wrote:
 my only concern is the capital U, in  mustUse

 This seems a little inconsistent with current attributes??

 e.g:

 nogc
 nothrow
 inout

 https://dlang.org/spec/attribute.html

 also, nodiscard would actually seem more logical, given the 
 above as well.

 I bet you, people will be thinking nodiscard, but will have to 
 remember to type,  mustuse, only to have the compiler complain, 
 that its' actually  mustUse
See my previous replies on this topic: https://forum.dlang.org/post/xgdwevkxqapljcvyjwtx forum.dlang.org https://forum.dlang.org/post/yxoinjtarkuotnlncyqw forum.dlang.org
Feb 06
next sibling parent reply forkit <forkit gmail.com> writes:
On Monday, 7 February 2022 at 05:09:23 UTC, Paul Backus wrote:
 On Monday, 7 February 2022 at 05:05:27 UTC, forkit wrote:
 my only concern is the capital U, in  mustUse

 This seems a little inconsistent with current attributes??

 e.g:

 nogc
 nothrow
 inout

 https://dlang.org/spec/attribute.html

 also, nodiscard would actually seem more logical, given the 
 above as well.

 I bet you, people will be thinking nodiscard, but will have to 
 remember to type,  mustuse, only to have the compiler 
 complain, that its' actually  mustUse
See my previous replies on this topic: https://forum.dlang.org/post/xgdwevkxqapljcvyjwtx forum.dlang.org https://forum.dlang.org/post/yxoinjtarkuotnlncyqw forum.dlang.org
no amount of replies will change anything ;-) .. people will still 'think' nodiscard, but have to 'remember' it's actually mustuse, but oops.. no... it's mustUse.. I do not expect anything from my feedback ;-) .. I'm just saying..humans are humans..
Feb 06
parent reply Paul Backus <snarwin gmail.com> writes:
On Monday, 7 February 2022 at 05:12:39 UTC, forkit wrote:
 no amount of replies will change anything ;-)

 .. people will still 'think'  nodiscard, but have to 'remember' 
 it's actually  mustuse, but oops.. no... it's  mustUse..

 I do not expect anything from my feedback ;-)  .. I'm just 
 saying..humans are humans..
I've seen similar sentiments expressed many times before, in other contexts. Every time, there are some who insist that the new name will never feel natural to them, and they will never let go of the old name. And every time, history proves them wrong. The fact is, human brains are quite plastic and adaptable. You'll get used to mustUse, just like I did, and so will everyone else.
Feb 07
parent reply forkit <forkit gmail.com> writes:
On Monday, 7 February 2022 at 13:55:40 UTC, Paul Backus wrote:
 I've seen similar sentiments expressed many times before, in 
 other contexts. Every time, there are some who insist that the 
 new name will never feel natural to them, and they will never 
 let go of the old name. And every time, history proves them 
 wrong.

 The fact is, human brains are quite plastic and adaptable. 
 You'll get used to  mustUse, just like I did, and so will 
 everyone else.
First, I'm not 'insisting' on anything. I'm just expressing a view. nodiscard is already used by more programmers that D is likely to ever adopt. Indeed, it's these programmers that D is trying to adopt. I'm not sure forcing such people to adapt is necessarily the right approach. that is my point. it's not necessary. you making it necessary ;-)
Feb 07
parent reply Guillaume Piolat <first.last gmail.com> writes:
On Monday, 7 February 2022 at 19:57:28 UTC, forkit wrote:
 First, I'm not 'insisting' on anything. I'm just expressing a 
 view.

 nodiscard is already used by more programmers that D is likely 
 to ever adopt.

 Indeed, it's these programmers that D is trying to adopt.

 I'm not sure forcing such people to adapt is necessarily the 
 right approach.
I'll have to side with forkit there. In audio software (at the very least) you pay very dearly the price of introducing new _words_, because the existing words embodies existing meaning and practice that users have internalized. If you call your "Amount" parameter "Dry/wet" instead, then misunderstandings will happen for years without ever a chance to correct them, because "Dry/wet" means something already in the users mind. If you call your mutex a "synchronizer" then you have to tell everyone what is a synchronizer, why it is needed as a concept, and so on. Think: "slices" and "dynamic arrays" in D, a distinction that is of no use and begets a lot of misunderstandings. Hence some does of of reusing, reduce mental load. Paucity of words helps the cast of D explainers.
Feb 09
next sibling parent Guillaume Piolat <first.last gmail.com> writes:
On Wednesday, 9 February 2022 at 14:30:30 UTC, Guillaume Piolat 
wrote:
 Hence some does of of reusing,
some dose of reuse*
Feb 09
prev sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Wednesday, 9 February 2022 at 14:30:30 UTC, Guillaume Piolat 
wrote:
 On Monday, 7 February 2022 at 19:57:28 UTC, forkit wrote:
 First, I'm not 'insisting' on anything. I'm just expressing a 
 view.

 nodiscard is already used by more programmers that D is likely 
 to ever adopt.

 Indeed, it's these programmers that D is trying to adopt.

 I'm not sure forcing such people to adapt is necessarily the 
 right approach.
I'll have to side with forkit there. In audio software (at the very least) you pay very dearly the price of introducing new _words_, because the existing words embodies existing meaning and practice that users have internalized.
In D, there is no existing word for this, so from that perspective both "mustuse" and "nodiscard" are equally valid. In other languages, there are multiple existing words: - C++17: [[nodiscard]] - C (gcc/clang): __attribute__((warn_unused_result)) If you are used to C++, then you will find "nodiscard" natural, and "mustuse" will require you to learn a new word. If you are used to Rust, then you will find "mustuse" natural, and "nodiscard" would have required you to learn a new word. And, of course, if you are used to Python or Javascript or one of the many other languages that has no word for this at all, it will make little difference to you either way. C++ is quite popular, but it is not the only popular language, and there are many D programmers who have never used C++ at all, let alone C++17 or later. Therefore, it is a mistake to assume that all or even most D programmers have already internalized "nodiscard", or indeed *any* particular word for this concept.
Feb 09
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 9 February 2022 at 16:21:24 UTC, Paul Backus wrote:
 [snip]

 In D, there is no existing word for this, so from that 
 perspective both "mustuse" and "nodiscard" are equally valid.

 In other languages, there are multiple existing words:

 - C++17: [[nodiscard]]
 - C (gcc/clang): __attribute__((warn_unused_result))


 If you are used to C++, then you will find "nodiscard" natural, 
 and "mustuse" will require you to learn a new word. If you are 
 used to Rust, then you will find "mustuse" natural, and 
 "nodiscard" would have required you to learn a new word.
But what color should the bike shed be? ;)
Feb 09
parent forkit <forkit gmail.com> writes:
On Wednesday, 9 February 2022 at 17:40:31 UTC, jmh530 wrote:
 On Wednesday, 9 February 2022 at 16:21:24 UTC, Paul Backus 
 wrote:
 [snip]

 In D, there is no existing word for this, so from that 
 perspective both "mustuse" and "nodiscard" are equally valid.

 In other languages, there are multiple existing words:

 - C++17: [[nodiscard]]
 - C (gcc/clang): __attribute__((warn_unused_result))


 If you are used to C++, then you will find "nodiscard" 
 natural, and "mustuse" will require you to learn a new word. 
 If you are used to Rust, then you will find "mustuse" natural, 
 and "nodiscard" would have required you to learn a new word.
But what color should the bike shed be? ;)
Color is a perceptual experience, and its impact on psychological functioning has been well researched.
Feb 09
prev sibling next sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Wednesday, 9 February 2022 at 16:21:24 UTC, Paul Backus wrote:
 C++ is quite popular, but it is not the only popular language, 
 and there are many D programmers who have never used C++ at 
 all, let alone C++17 or later. Therefore, it is a mistake to 
 assume that all or even most D programmers have already 
 internalized "nodiscard", or indeed *any* particular word for 
 this concept.
There is also the Nim "discard" statement. I wonder why noone stole that feature. Feels more natural to me speak about the error being avoided, than a vague statement like "must use". C++17 is the most used language in the native space, so yes I think it takes precedence in the minds of native programmers. But, it is a level of bikeshedding I'm not keen on entering.
Feb 09
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 9 February 2022 at 17:48:29 UTC, Guillaume Piolat 
wrote:
 There is also the Nim "discard" statement.
Just change the default to not allowing return values to be discarded. When you really want to, do: ``` cast(void) function_with_return_value(…) ``` Or something like that.
Feb 09
prev sibling next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 10/02/2022 5:21 AM, Paul Backus wrote:
 - C (gcc/clang): __attribute__((warn_unused_result))
C23 will also have [[nodiscard]] Not only will it have that on functions, but also support a string too. Unfortunately its looking like we have chosen to diverge from C, and therefore won't be completely C compatible soon. Will be exciting as to what kind of bugs crop up because of this!
Feb 09
parent forkit <forkit gmail.com> writes:
On Wednesday, 9 February 2022 at 17:54:17 UTC, rikki cattermole 
wrote:
 On 10/02/2022 5:21 AM, Paul Backus wrote:
 - C (gcc/clang): __attribute__((warn_unused_result))
C23 will also have [[nodiscard]] Not only will it have that on functions, but also support a string too. Unfortunately its looking like we have chosen to diverge from C, and therefore won't be completely C compatible soon. Will be exciting as to what kind of bugs crop up because of this!
Exactly. So now C++ and C will have nodiscard, and when those developers come over to D (the developers most targetted by D btw), someone will have to explain why D decided on a different color for the bikeshed.
Feb 09
prev sibling parent apz28 <home home.com> writes:
On Wednesday, 9 February 2022 at 16:21:24 UTC, Paul Backus wrote:
 On Wednesday, 9 February 2022 at 14:30:30 UTC, Guillaume Piolat 
 wrote:
 On Monday, 7 February 2022 at 19:57:28 UTC, forkit wrote:
 First, I'm not 'insisting' on anything. I'm just expressing a 
 view.

 nodiscard is already used by more programmers that D is 
 likely to ever adopt.

 Indeed, it's these programmers that D is trying to adopt.

 I'm not sure forcing such people to adapt is necessarily the 
 right approach.
I'll have to side with forkit there. In audio software (at the very least) you pay very dearly the price of introducing new _words_, because the existing words embodies existing meaning and practice that users have internalized.
In D, there is no existing word for this, so from that perspective both "mustuse" and "nodiscard" are equally valid. In other languages, there are multiple existing words: - C++17: [[nodiscard]] - C (gcc/clang): __attribute__((warn_unused_result))
C++17: [[nodiscard]] is just a warning; must use another compiler flag in order to have same mustuse in D -> already discrepancy in meaning
Feb 09
prev sibling parent bauss <jj_1337 live.dk> writes:
On Monday, 7 February 2022 at 05:09:23 UTC, Paul Backus wrote:
 On Monday, 7 February 2022 at 05:05:27 UTC, forkit wrote:
 my only concern is the capital U, in  mustUse

 This seems a little inconsistent with current attributes??

 e.g:

 nogc
 nothrow
 inout

 https://dlang.org/spec/attribute.html

 also, nodiscard would actually seem more logical, given the 
 above as well.

 I bet you, people will be thinking nodiscard, but will have to 
 remember to type,  mustuse, only to have the compiler 
 complain, that its' actually  mustUse
See my previous replies on this topic: https://forum.dlang.org/post/xgdwevkxqapljcvyjwtx forum.dlang.org https://forum.dlang.org/post/yxoinjtarkuotnlncyqw forum.dlang.org
This is one of those cases where I think there should be an exception to the "rule" you so blindly want to follow. mustuse is so much better and makes code so much more consistent.
Feb 07
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/6/2022 9:05 PM, forkit wrote:
 only to have the compiler complain, that its' actually  mustUse
I have to agree. All D keywords and imports and compiler-recognized attributes are lower case, mustuse should be consistent with that.
Feb 07
parent reply Paul Backus <snarwin gmail.com> writes:
On Monday, 7 February 2022 at 23:40:38 UTC, Walter Bright wrote:
 On 2/6/2022 9:05 PM, forkit wrote:
 only to have the compiler complain, that its' actually  mustUse
I have to agree. All D keywords and imports and compiler-recognized attributes are lower case, mustuse should be consistent with that.
I guess core.attribute.gnuAbiTag sneaked in behind your back, huh? Anyway, I'm happy to change it if that's your call, although it would have been nice to have caught this before the DIP was officially accepted.
Feb 07
next sibling parent reply forkit <forkit gmail.com> writes:
On Tuesday, 8 February 2022 at 02:21:37 UTC, Paul Backus wrote:
 I guess core.attribute.gnuAbiTag sneaked in behind your back, 
 huh?

 Anyway, I'm happy to change it if that's your call, although it 
 would have been nice to have caught this before the DIP was 
 officially accepted.
actually, I wish camelCase was not a requirement of user defined attributes. I would prefer must_use over mustUse, for example (althouhgh i prefer mustuse to both of these, since the underscore is not really needed in this case). Don't be discouraged though, the proposal is sound. But ideas that might help it become more acceptable to programmers (and the langauge), is still not worthy of being excluded from discussion (I think I got enough negations in there ;-)
Feb 07
parent forkit <forkit gmail.com> writes:
On Tuesday, 8 February 2022 at 02:57:29 UTC, forkit wrote:
 I would prefer  must_use over  mustUse, for example (althouhgh 
 i prefer  mustuse to both of these, since the underscore is not 
 really needed in this case).
my argument for the above, is: The problem with using camelCase on attributes, is that it implies nothing special about it (the attribute), at all. It is common practice to use camelCase for things like variables, function names, etc... i.e. things that hold something, or do something. Whereas an attribute is essentially a predicate. You are proclaiming a static declaration, that will apply to what follows. As such, it deserves to stand out, with a different naming convention. That is: all lowercase, but when required, snake_case.
Feb 07
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/7/2022 6:21 PM, Paul Backus wrote:
 On Monday, 7 February 2022 at 23:40:38 UTC, Walter Bright wrote:
 On 2/6/2022 9:05 PM, forkit wrote:
 only to have the compiler complain, that its' actually  mustUse
I have to agree. All D keywords and imports and compiler-recognized attributes are lower case, mustuse should be consistent with that.
I guess core.attribute.gnuAbiTag sneaked in behind your back, huh?
Indeed it did. I did not notice it until this moment. A lot of people work on D, and I have to trust them.
 Anyway, I'm happy to change it if that's your call, although it would have
been 
 nice to have caught this before the DIP was officially accepted.
Yes, please change it. Thank you!
Feb 07