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.

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?

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.

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.

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 #[must_use] make an exception for functions that return void/unit.

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.

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.

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.

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.

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