DIP 1038: @nodiscard - Unofficial "post-final" review

[Andrei Alexandrescu]

On 2/22/21 7:03 AM, Paul Backus wrote:
> In response to Walter's feedback [1] from the final review round, I've 
> added a new section to DIP 1038 (@nodiscard) on "Design Goals and 
> Possible Alternatives".
> 
> Since it's a substantial addition (almost 50% of the DIP's original 
> length), Mike Parker, the DIP Manager, has graciously allowed me to 
> postpone formal assessment to give the community a chance to look it 
> over, and point out any silly mistakes I may have made.
> 
> If you'd like to help @nodiscard succeed, I hope you'll give the revised 
> version a read and reply to this thread with any questions or feedback 
> you may have, especially regarding the new section. You can also reach 
> out to me on the dlang slack or the D community Discord if you'd prefer.
> 
> Revised DIP 1038:
> https://github.com/pbackus/DIPs/blob/dip1038-final-revisions/DIPs/DIP1038.md 
> 
> 
> Direct link to new section:
> https://github.com/pbackus/DIPs/blob/dip1038-final-revisions/DIPs/DIP1038.md#design-goals-and-possible-alternatives 
> 
> 
> [1] https://forum.dlang.org/post/rvgdj6$15na$1@digitalmars.com

This is nice and well argued. The time-tested presence of the attribute 
in C++ is important, probably could use 1-2 paragraphs to emphasize 
that. (It's been a non-standard extension for a long time and clearly 
there was a lot of demand to standardize it.)

For integration, it would be nice if the proposal made pure non-void 
functions automatically nodiscard. That way ignoring the reusult of such 
a function is an error, as it should.

The proposal should mention what happens if two declararions differ only 
by nodiscard:

void* malloc(size_t);
@nodiscard void* malloc(size_t);

I forgot what we usually do. I think it's safe to mark that as as error.

The proposal should mention how @nodiscard works with overriding. Given 
that @nodiscard is more restrictive, by the old OOP principles a 
@nodiscard function should be overridable by a non- at nodiscard function. 
(Rationale: overriding functions ASK LESS and RETURN MORE.) However, a 
practicality consideration is that the author of the override simply 
forgot to add @nodiscard, so we can make the attribute equivariant. It's 
important in all cases that a no- at nodiscard function cannot be overriden 
by a @nodiscard one.

Great work!!!