Discussion Thread: DIP 1038-- at nodiscard--Final Review

[Bruce Carneal]

On Friday, 5 February 2021 at 01:04:01 UTC, IGotD- wrote:
> On Thursday, 4 February 2021 at 20:15:07 UTC, Q. Schroll wrote:
>>
>> I wonder how many non-void functions exist whose return values 
>> are usually ignored.
>
> There are plenty of them and I do it all the time. Sometimes it 
> is unnecessary and sometimes not and I pay the price. I 
> consider @nodiscard a very niche problem in D, as described in 
> the DIP mostly for system code. I think that in system code you 
> do so much unsafe things anyway and if you want to be sure to 
> check return values, then check the documentation of the 
> library that you are using. It's a nanny when you need it the 
> least.

I'll take every bit of concise help that moves checking off the 
error-prone-human plate and on to the much-less-error-prone 
compiler plate.  Such help is especially valuable at an 
underlying @system level when it comes at compile time.

>
> I think the DIP is heavily influenced by Rust but there the 
> return value is part of the default language error handling 
> which makes more sense. In D there are exceptions but this DIP 
> doesn't regard them so the benefit is limited.

Limited in what way?  How might the DIP "regard" exceptions?

>
> I think that having a compiler flag that warns when a return 
> value is not used should be enough. That should cover those 
> projects where always checking the return value is a 
> requirement.

I much prefer errors to warnings.  If I accept warnings then I 
must carry more of the burden of correctness manually, unaided, 
as long as the code base is active. YMMV of course.

The happily cavalier crowd should be fine because the capability 
is opt-in.  They'll only be bitten if a less-cavalier author 
updates support code underneath them IIUC.

I like the DIP, a lot.  It is useful, performant (compile time), 
and orthogonal to other compiler concerns AFAICS.  I also like 
the writing.  Nicely done.