DIP 1038: @nodiscard - Unofficial "post-final" review
Andrei Alexandrescu
SeeWebsiteForEmail at erdani.org
Mon Feb 22 22:01:01 UTC 2021
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!!!
More information about the Digitalmars-d
mailing list