This paper was discussed on the mailing list July 6- July 22.

No technical concerns, some discussions about whether this is worth our time.
I recommend it goes straight to electronic polling

A motion to move this paper from mailing list review to electronic polls was made on 2021-08-01. That motion failed to garner unanimous support, but extensive discussion followed on the mailing list. The chair believes that telecon time is unlikely to meaningfully add to the conversation and will likely not sway people's positions. As such, this paper is proceeding to electronic polling.

2021 September Library Evolution Polls

P2451: 2021 September Library Evolution Poll Outcomes

Poll 4: Send P2351R0 (Mark All Library Static Cast Wrappers As [[nodiscard]]) to Library Working Group for C++23, classified as an improvement of an existing feature (P0592R4 bucket 2 item).

Outcome: Weak consensus in favor.

Selected Comments

I encourage explicit [[nodiscard]] markings in the standard -- they help catch real world bugs!

— Strongly Favor

This matches existing practice and make the intent of these function clearer. It has a very low burden on the standard and implementers.

— Strongly Favor

Although [I] would prefer [[nodiscard]] be applied liberally to the standard library, [I] would also be satisfied with it as [Quality of Implementation (QoI)].

— Weakly Favor

While the direct value of including attributes with no reliable, normative effect in the standard is questionable, there is a very real indirect effect: if implementations can expect that other implementations will issue warnings for the same code, they are less likely to withhold the warnings for compatibility reasons.

— Weakly Favor

I find the whole idea of [[nodiscard]] backwards. The compiler should warn by default on discarded return values. I should have to do something special to get it to stop emitting a warning. If the compiler is doing its job, then nothing should need [[nodiscard]] decoration. On the other hand, I wouldn't mind if the standard library did this.

— Neutral

I am generally in favour of tightening the requirements of [Quality of Implementation (QoI)] to standardize high quality implementations. However In this case I think we can get the result with out prescribing all details.

— Neutral

I think blanket wording saying which functions should be treated as nodiscard would be superior to explicitly adding it to individual declarations.

— Weakly Against

It seems a waste of valuable LWG time to forward [[nodiscard]] papers without first having reached agreement on whether we want such annotations in the standard at all. I also have serious reservations about the process employed where the mailing list discussion was supposedly tabled until the end of the year, then a month later the paper is suddenly submitted to electronic polling.

— Strongly Against

* Has no normative effect.
* Poor use of LEWG time (and it won't stop with just this [[nodiscard]] paper).
* Poor use of WG21 time.
* There are many (if not all) bucket 3 items I would much rather have before this.

• No general rules for applying [[nodiscard]].
  * Moves the standard towards being prescriptive, not descriptive.
  * Much better to have a standing document of these things instead of littering the standard with them.
  * Controversial papers should not skip LEWG telecons and go straight to electronic polling.
  * This is something implementors should be doing instead of spending valuable committee time legislating it.

— Strongly Against