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 2022
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 2022
prev sibling next sibling parent Bruce Carneal <bcarneal gmail.com> writes:
Well done Paul.  I appreciate the clarity, simplicity and utility.
Jan 28 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022



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 2022



  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 2022



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 2022



  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 2022



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 2022



 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 2022



 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 2022



  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 2022



  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 2022



  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 2022



 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 2022



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 2022



 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 2022



  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 2022



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 2022



  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 2022



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 2022



  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 2022



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 2022



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 2022



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 2022



  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 2022



 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 2022



  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 2022



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 2022