1. Revision History
1.1. Revision 4 - August 5th, 2019
Preliminary Core Working Group suggestions from Jens Maurer about basic source character set applicability.
Rebase on n4820.
Basically copy-pasta the updated
[[ deprecated ]]
Merged into the C++20 Working Paper, and sent out in the C++20 CD! 🎉
1.2. Revision 3 - June 17th, 2019
Wording is now relative to [n4820], the latest C++ Standard working draft.
Approved for Core in Kona, going there! 🎉
1.3. Revision 2 - January 21st, 2019
Wording is now relative to [n4778], the latest C++ Standard working draft.
Add §2 Feedback from reflector discussion.
1.4. Revision 1 - November 7th, 2018
Add Tony Table and fix the example in the Tony Table.
1.5. Revision 0 - October 7th, 2018
After a brief discussion with no negative feedback on November in San Diego, the chair forwarded this to EWG with the caveat that this paper should ask both LWG and LEWG representatives to chime in. A message was sent out on the reflector with 50+ responses indicating strong support (90%+ positive affirmation) for having this feature.
The question is whether or not the standard should mandate the text that goes in a
attribute. There was extremely strong push back to that idea, and this paper does not propose any standardized text on any entity within the C++ Standard. This paper encourages implementers to apply any text they see fit, and if they find it overwhelmingly useful to bring that information in a new and separate paper.
This paper simply proposes making it possible to have the reason present, nothing more.
attribute has helped prevent a serious class of software bugs, but sometimes it is hard to communicate exactly why a function is marked as
This paper adds an addendum to allow a person to add a string attribute token to let someone provide a small reasoning or reminder for why a function has been marked
4. Design Considerations
This paper is an enhancement of a preexisting feature to help programmers provide clarity with their code. Anything that makes the implementation warn or error should also provide some reasoning or perhaps point users to a knowledge base or similar to have any questions they have about the reason for the
The design is very simple and follows the lead of the
attribute. We propose allowing a string literal to be passed as an attribute argument clause, allowing for
. The key here is that there are some
attributes that have different kinds of "severity" versus others. That is, the cost of discarding
's return value is probably of slightly less concern than
: one might manifest as a possible bug, the other is a downright memory leak.
Adding a reason to
allows implementers of the standard library, library developers, and application writers to benefit from a more clear and concise error beyond "Please do not discard this return value". This makes it easier for developers to understand the intent of the code they are using.
All wording is relative to [n4820].
The intent of the wording is to let a programmer specify a string literal that the compiler can use in their warning / error display for, e.g.
. Multiple redeclarations leave it up to the implementation what happens to the diagnostic message, but does not require them to define and document such behavior.
5.2. Feature Test Macro
already has an attribute value in Table 15. If this proposal is accepted, then per the standard’s reasoning the value of
should be increased to some greater value (such as
5.3. Proposed Wording
Modify §15.1 [cpp.cond]'s Table 15:
Attribute Value nodiscard 201603L
Modify §9.11.9 Nodiscard attribute [dcl.attr.nodiscard]'s clause 1 as follows:
1 The attribute-token nodiscard may be applied to the declarator-id in a function declaration or to the declaration of a class or enumeration. It shall appear at most once in each attribute-list
and no attribute-argument-clause shall be present..
3 [Note: A nodiscard call is a function call expression that calls a function previously declared
, or whose return type is a possibly cv-qualified class or enumeration type marked nodiscard. Appearance of a
call as a potentially-evaluated discarded-value expression is discouraged unless explicitly cast to
. Implementations should issue a warning in such cases. This is typically because discarding the return value of a
call has surprising consequences. — end note]