www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - FeedbackThread: DIP 1038-- nodiscard--Community Review Round 1

reply Mike Parker <aldacron gmail.com> writes:
This is the feedback thread for the first round of Community 
Review of DIP 1038, " nodiscard".

===================================
**THIS IS NOT A DISCUSSION THREAD**

Posts in this thread must adhere to the feedback thread rules 
outlined in the Reviewer Guidelines (and listed at the bottom of 
this post).

https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md

That document also provides guidelines on contributing feedback 
to a DIP review. Please read it before posting here. If you would 
like to discuss this DIP, please do so in the discussion thread:

https://forum.dlang.org/post/zlanrlqqjjtvfwbymppn forum.dlang.org
==================================

You can find DIP 1038 here:

https://github.com/dlang/DIPs/blob/58b29a85fdf3cbf3521235e40f2a66e141e856c2/DIPs/DIP1038.md

The review period will end at 11:59 PM ET on December 23, or when 
I make a post declaring it complete. Feedback posted to this 
thread after that point may be ignored.

At the end of this review round, the DIP will be moved into the 
Post-Community Round 1 state. Significant revisions resulting 
from this review round may cause the DIP manager to require 
another round of Community Review, otherwise the DIP will be 
queued for the Final Review.

==================================
Posts in this thread that do not adhere to the following rules 
will be deleted at the DIP author's discretion:

* All posts must be a direct reply to the DIP manager's initial 
post, with only two exceptions:

     - Any commenter may reply to their own posts to retract 
feedback contained in the original post

     - The DIP author may (and is encouraged to) reply to any 
feedback solely to acknowledge the feedback with agreement or 
disagreement (preferably with supporting reasons in the latter 
case)

* Feedback must be actionable, i.e., there must be some action 
the DIP author can choose to take in response to the feedback, 
such as changing details, adding new information, or even 
retracting the proposal.

* Feedback related to the merits of the proposal rather than to 
the contents of the DIP (e.g., "I'm against this DIP.") is 
allowed in Community Review (not Final Review), but must be 
backed by supporting arguments (e.g., "I'm against this DIP 
because..."). The supporting arguments must be reasonable. 
Obviously frivolous arguments waste everyone's time.

* Feedback should be clear and concise, preferably listed as 
bullet points (those who take the time to do an in-depth review 
and provide feedback in the form of answers to the questions in 
the documentation linked above will receive much gratitude). 
Information irrelevant to the DIP or which is not provided in 
service of clarifying the feedback is unwelcome.
Dec 09 2020
next sibling parent reply Max Haughton <maxhaton gmail.com> writes:
On Wednesday, 9 December 2020 at 10:11:52 UTC, Mike Parker wrote:

 This is the feedback thread for the first round of Community 
 Review of DIP 1038, " nodiscard".

 [...]


How will the cast semantics interact with  safe (and it's 
family)? On the one hand  safe doesn't really affect exceptions, 
but equally they are a different abstraction to return values.

Should I be able to cast away a  nodiscard return value in safe 
code?
Dec 09 2020
parent Paul Backus <snarwin gmail.com> writes:
On Wednesday, 9 December 2020 at 10:49:32 UTC, Max Haughton wrote:

 On Wednesday, 9 December 2020 at 10:11:52 UTC, Mike Parker 
 wrote:

 This is the feedback thread for the first round of Community 
 Review of DIP 1038, " nodiscard".

 [...]


 How will the cast semantics interact with  safe (and it's 
 family)? On the one hand  safe doesn't really affect 
 exceptions, but equally they are a different abstraction to 
 return values.

 Should I be able to cast away a  nodiscard return value in safe 
 code?


cast(void) is always  safe.
Dec 09 2020
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On Wednesday, 9 December 2020 at 10:11:52 UTC, Mike Parker wrote:

 This is the feedback thread for the first round of Community 
 Review of DIP 1038, " nodiscard".


 From the DIP:


 By contrast,  nodiscard can be used with any function because 
 all functions have a return type.


Just a small implementation note: I think  nodiscard should not 
apply to void functions. In other words, if I have:

-----
 nodiscard:

int foo();
void bar();
-----

then calling `bar();` should just work, we shouldn't need to 
write `cast(void)bar()`.

At least I can't think of use-cases for it having an effect on 
void functions.
Dec 09 2020
next sibling parent Paul Backus <snarwin gmail.com> writes:
On Wednesday, 9 December 2020 at 14:30:13 UTC, Andrej Mitrovic 
wrote:

 By contrast,  nodiscard can be used with any function because 
 all functions have a return type.


 Just a small implementation note: I think  nodiscard should not 
 apply to void functions. In other words, if I have:

 -----
  nodiscard:

 int foo();
 void bar();
 -----

 then calling `bar();` should just work, we shouldn't need to 
 write `cast(void)bar()`.

 At least I can't think of use-cases for it having an effect on 
 void functions.


I agree that  nodiscard is not really useful on void functions, 
but it seems to me like the obvious solution is to just...not 
annotate void functions with  nodiscard. Unlike 
 safe/pure/nothrow/ nogc, it is not transitive and will never be 
inferred by the compiler, so the only way a void function can end 
up with  nodiscard is if the programmer explicitly annotates it 
as such.

If you can come up with a realistic example of a void function 
being annotated with  nodiscard, please reply in the Discussion 
thread.

If we want to go down the route of making certain return types 
exempt, then we also have to consider whether  nodiscard should 
apply to examples like this:

struct Void {}
 nodiscard Void baz();

It is worth noting that neither C++'s [[nodiscard]] nor Rust's
Dec 09 2020
prev sibling parent reply Denis Feklushkin <feklushkin.denis gmail.com> writes:
On Wednesday, 9 December 2020 at 14:30:13 UTC, Andrej Mitrovic 
wrote:

 On Wednesday, 9 December 2020 at 10:11:52 UTC, Mike Parker 
 wrote:

 This is the feedback thread for the first round of Community 
 Review of DIP 1038, " nodiscard".


 From the DIP:


 By contrast,  nodiscard can be used with any function because 
 all functions have a return type.


 Just a small implementation note: I think  nodiscard should not 
 apply to void functions.


Do not forgot about templates with auto-inferred return types. It 
can be void or not, it depend on template arguments.
Dec 09 2020
parent Paul Backus <snarwin gmail.com> writes:
On Wednesday, 9 December 2020 at 20:10:14 UTC, Denis Feklushkin 
wrote:

 On Wednesday, 9 December 2020 at 14:30:13 UTC, Andrej Mitrovic 
 wrote:

 On Wednesday, 9 December 2020 at 10:11:52 UTC, Mike Parker 
 wrote:

 This is the feedback thread for the first round of Community 
 Review of DIP 1038, " nodiscard".


 From the DIP:


 By contrast,  nodiscard can be used with any function because 
 all functions have a return type.


 Just a small implementation note: I think  nodiscard should 
 not apply to void functions.


 Do not forgot about templates with auto-inferred return types. 
 It can be void or not, it depend on template arguments.


I have trouble imagining why you would want to mark such a 
function as  nodiscard in the first place. If you can come up 
with a plausible example, please reply in the discussion thread.
Dec 12 2020
prev sibling next sibling parent reply Robert burner Schadek <rburners gmail.com> writes:
The "Rationale -> Error handling without exceptions sections 
argument" is wrong.

1. I know of at least one package marked as "optimized for fast 
execution" that throws.

2. Just because you bind to other languages does not mean that 
you can not throw.
I would even argue, building a nice D interface with exceptions 
is the purpose of any language binding written in D.

3. Many package don't use categories, so the numbers are off by 
default.

4. Just because people say there package works with  nogc, 
doesn't mean it does.

The only "correct" way to get to any percentage, is to try to use 
all packages from code that is nothrow and/or  nogc.
Dec 10 2020
parent Paul Backus <snarwin gmail.com> writes:
On Thursday, 10 December 2020 at 09:40:08 UTC, Robert burner 
Schadek wrote:

 The "Rationale -> Error handling without exceptions sections 
 argument" is wrong.


[...]

 The only "correct" way to get to any percentage, is to try to 
 use all packages from code that is nothrow and/or  nogc.


I am well aware that these numbers are not perfectly accurate. 
The point of using them is only to get a rough approximation of 
the proportion of D code that could benefit from an alternative 
to exceptions. Unless there is a reason to think they are 
strongly *biased* (i.e., there are many more false positives than 
false negatives), it does not really matter to the DIP's argument 
if they are off by a few percent one way or the other.

As you point out, the amount of work required to get more 
accurate data is prohibitive, so the actual choice is between 
"rough, approximate numbers" and "no numbers at all." I think the 
DIP is stronger with the numbers than without them, even 
accounting for their shortcomings, but I am happy to hear 
arguments to the contrary.
Dec 10 2020
prev sibling next sibling parent Paul Backus <snarwin gmail.com> writes:
On Wednesday, 9 December 2020 at 10:11:52 UTC, Mike Parker wrote:

 ==================================
 Posts in this thread that do not adhere to the following rules 
 will be deleted at the DIP author's discretion:


FYI: if you posted feedback that I haven't replied to, it's 
because you violated one of the thread rules (e.g., responding to 
other feedback instead of the first post). Please familiarize 
yourself with the rules and re-submit your feedback if you would 
like a reply. Keeping the thread well-organized makes it much 
easier for the DIP Manager, Mike Parker, to summarize the 
feedback at the end of each review round.
Dec 11 2020
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2020-12-09 11:11, Mike Parker wrote:

 This is the feedback thread for the first round of Community Review of 
 DIP 1038, " nodiscard".


The DIP doesn't mention anything about constructors. It should mention 
if this attribute can be applied to constructors. It should also mention 
if it applies to if the attribute is attached to the type and a 
constructor is called for that type.

For constructors, there is mostly no other option of error handling than 
exceptions. Perhaps an `out` parameter could work.

-- 
/Jacob Carlborg
Dec 11 2020
parent Paul Backus <snarwin gmail.com> writes:
On Friday, 11 December 2020 at 20:01:38 UTC, Jacob Carlborg wrote:

 On 2020-12-09 11:11, Mike Parker wrote:

 This is the feedback thread for the first round of Community 
 Review of DIP 1038, " nodiscard".


 The DIP doesn't mention anything about constructors. It should 
 mention if this attribute can be applied to constructors. It 
 should also mention if it applies to if the attribute is 
 attached to the type and a constructor is called for that type.


These cases are both covered by the rules given in the DIP.

1) A constructor is a function. Therefore,  nodiscard can be 
applied to a constructor.
2) For any type T, a call to T's constructor is an expression of 
type T. Therefore, if T is an aggregate type whose declaration is 
annotated with  nodiscard, that expression will be considered 
non-discardable.
Dec 11 2020