Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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)) - Rust: #[must_use] 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.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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)) - Rust: #[must_use] C++17: [[nodiscard]] is just a warning; must use another compiler flag in order to have same @mustuse in D -> already discrepancy in meaning
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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!
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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)) - Rust: #[must_use] 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? ;)
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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)) - Rust: #[must_use] 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.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
On Wednesday, 9 February 2022 at 14:30:30 UTC, Guillaume Piolat wrote: Hence some does of of reusing, some dose of reuse*
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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")]])
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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!
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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 ;-)
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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').
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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 ;-)
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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/xgdwevkxqapljcvyj...@forum.dlang.org https://forum.dlang.org/post/yxoinjtarkuotnlnc...@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.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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/xgdwevkxqapljcvyj...@forum.dlang.org https://forum.dlang.org/post/yxoinjtarkuotnlnc...@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..
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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/xgdwevkxqapljcvyj...@forum.dlang.org https://forum.dlang.org/post/yxoinjtarkuotnlnc...@forum.dlang.org
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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]]```.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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. :-)
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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/tesktfsmdglmzbhzy...@forum.dlang.org
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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…
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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"?
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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!)
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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 ...
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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__ ...
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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 @.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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!
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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!
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
Well done Paul. I appreciate the clarity, simplicity and utility.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
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.)
