This is the discussion thread for the first round of Community Review of DIP 1038, "@nodiscard":

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. Discussion in this thread may continue beyond that point.

Here in the discussion thread, you are free to discuss anything and everything related to the DIP. Express your support or opposition, debate alternatives, argue the merits, etc.

However, if you have any specific feedback on how to improve the proposal itself, then please post it in the feedback thread. The feedback thread will be the source for the review summary that I will write at the end of this review round. I will post a link to that thread immediately following this post. Just be sure to read and understand the Reviewer Guidelines before posting there:

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

And my blog post on the difference between the Discussion and Feedback threads:

https://dlang.org/blog/2020/01/26/dip-reviews-discussion-vs-feedback/

Please stay on topic here. I will delete posts that are completely off-topic.

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

> However, if you have any specific feedback on how to improve the proposal itself, then please post it in the feedback thread. The feedback thread will be the source for the review summary that I will write at the end of this review round. I will post a link to that thread immediately following this post.

The Feedback Thread is located here:

https://forum.dlang.org/post/qptthjobogooocleizvo@forum.dlang.org

What I usually do to avoid exceptions is using Nullable/Variant as the return type, as using it still needs checking.
So, syntax sugar to return those seems like a nicer alternative with less changes to the compiler and less @s

On Wednesday, 9 December 2020 at 10:10:40 UTC, Mike Parker wrote:
> This is the discussion thread for the first round of Community Review of DIP 1038, "@nodiscard":
>
> https://github.com/dlang/DIPs/blob/58b29a85fdf3cbf3521235e40f2a66e141e856c2/DIPs/DIP1038.md


So, er.... I feel in the "target market" of this DIP, we use D-with-runtime-disabled
and the codebase is completely @nogc.
The DIP is not that appealing to me because we do manage to throw/catch anyway with manually allocated exceptions.

So most likely I would put this attribute in the "do not use" list of D features.

I'd be more excited about:
- throw-by-value exceptions
- a way to use exceptions in @nogc and even -betterC (There was a DIP for it, it was implemented, but doesn't work IIRC)
than improving error codes.

That said, I have no real idea how much needed this DIP is.

https://forum.dlang.org/post/mloquupidedjxasqqhkt@forum.dlang.org

>> 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.

I have to disagree forcefully, no numbers are highly preferable unless you
have shown that they are accurate, within a few percent.
The burden of proof is on the DIP.

Please read the following sympathetic.
Using these false numbers to emphasize the usefulness of this DIP has the opposite
effect.
Every word I read after seeing these claims left a foul taste, even though I
consider this a useful DIP.

On Friday, 11 December 2020 at 08:03:06 UTC, Guillaume Piolat wrote:
> So, er.... I feel in the "target market" of this DIP

I think I'd actually use it for an entirely different purpose.

My cgi.d has a function called `schedule` that returns a plan builder object but doesn't actually do anything with it. You're supposed to actually build it then commit it. Like so:

schedule!some_operation.at(whatever);

The @nodiscard there could help when you've constructed the builder, but didn't actually do anything with it.

Perhaps you'd argue a required named param or something is better here but I still kinda like this.

> - a way to use exceptions in @nogc and even -betterC (There was a DIP for it, it was implemented, but doesn't work IIRC)

The -dip1008 switch.... sometimes works? i rarely use non-default switches but i had success playing with it in small toys.

On Wednesday, 9 December 2020 at 10:10:40 UTC, Mike Parker wrote:
> This is the discussion thread for the first round of Community Review of DIP 1038, "@nodiscard":
>
> [...]

I use the equivalent feature in C all the time and it is great. It especially helps when a function that previously was declared as returning void needs to now return an error code.

On Friday, 11 December 2020 at 14:01:59 UTC, Adam D. Ruppe wrote:
>
> The -dip1008 switch.... sometimes works? i rarely use non-default switches but i had success playing with it in small toys.

To be precise: -review=dip1008 doesn't work well with -betterC since you can't use try/catch in -betterC, it needs the equivalent of a dynamic cast, so more RTTI
https://d.godbolt.org/z/Ta5T7K

Curious if it works for your WASM work

On 2020-12-11 09:03, Guillaume Piolat wrote:

> So, er.... I feel in the "target market" of this DIP, we use D-with-runtime-disabled
> and the codebase is completely @nogc.
> The DIP is not that appealing to me because we do manage to throw/catch anyway with manually allocated exceptions.
> 
> So most likely I would put this attribute in the "do not use" list of D features.
> 
> I'd be more excited about:
> - throw-by-value exceptions
> - a way to use exceptions in @nogc and even -betterC (There was a DIP for it, it was implemented, but doesn't work IIRC)
> than improving error codes.

I completely agree. Instead of this approach, the compiler could lower try/catch/finally/throw for a function to return tagged union of the success value and all the exceptions that can be thrown. Then one could easily throw any kind of types, not just classes inheriting from `Throwable`, including value types.

-- 
/Jacob Carlborg

On Fri, Dec 11, 2020 at 08:54:58PM +0100, Jacob Carlborg via Digitalmars-d wrote:
> On 2020-12-11 09:03, Guillaume Piolat wrote:
[...]
> > I'd be more excited about:
> > - throw-by-value exceptions
> > - a way to use exceptions in @nogc and even -betterC (There was a DIP
> > for it, it was implemented, but doesn't work IIRC)
> > than improving error codes.
> 
> I completely agree. Instead of this approach, the compiler could lower try/catch/finally/throw for a function to return tagged union of the success value and all the exceptions that can be thrown.

Yes!  Lightweight by-value exceptions will be a plus in my book.


> Then one could easily throw any kind of types, not just classes inheriting from `Throwable`, including value types.
[...]

But I don't agree with this.

I used to write a lot of C++, where you can throw literally *anything*. It seems to be a good thing to allow maximum flexibility, but that actually hinders code interoperability: you cannot assume *anything* about something you caught, because it can literally be *any* type.  D's Throwable API is much better because it guarantees a minimal common interface that all catch blocks can depend on.  Having a standard .msg field that returns a string you can print to the user in the event you need to abort, e.g., is much more useful than an opaque type that you can't do anything with other than say "an error occurred, abort" -- what error? Don't know, can't know, the catch block in main() has no idea where it came from or what information might be encoded within. Knowledge about the error might only exist inside a 3rd party dependency.

Maximum flexibility isn't always a good thing.


T

-- 
Study gravitation, it's a field with a lot of potential.