On 06/10/2023 11:30, Ferhat Geçdoğan via Std-Proposals wrote:
> Is there any useful use-case that makes [[discard]] unique? That's just
> a way of adding one more unuseful C++ keyword to the list in my opinion.
It's not a new keyword, it's an attribute.
But if EWG thinks it "has an effect," they'll ask to make it a keyword. ;)
If we s/keyword/syntactic feature/, I agree with Ferhat's point. (As you know; I know I'm repeating myself needlessly here. :))
* It does not abuse the cast notation and the cast semantics towards
void in order to suppress a warning. Doing a cast to void (à la
`(void)f();`) isn't done because one wants a specific type conversion,
it's done to silence the [[nodiscard]] warning.
Well, it occurred to me this morning that (void) has another very nice synergy. Remember how we said yesterday that nobody should ever use the comma operator for anything? Well, today I'm walking back from that position a little bit. Library implementors use it a lot, in the context of the three-part for loop:
for (int i = 0; i < n; ++i, (void)update(n)
)In this context, (void) has two reasons to exist:
- It indicates that we're discarding the value of `update` (which let's assume is a user-provided function that the library doesn't know what it returns)
- It suppresses ADL on that `operator,` in case the user-provided `advance` returns some type `Evil`
struct Evil { friend void operator,(int, Evil) { puts("ha ha"); } };
That is, (void) coincidentally-or-not fits the bill for these library implementors exactly.
Your proposed [[discard]] wouldn't be a replacement for (void) here.
So, if I value consistency and having-a-small-subset-of-C++-to-teach, and I have to teach (void) here,[*] I don't see why I should teach a different syntax anywhere else.
[* — Teach to library contributors and other advanced folks; obviously not teach on Day 2 of the intro course. :)]
[** — Alternatively one could teach this cast-free version:
for (int i = 0; i < n; ++i, void(), (update(n) [[discard]]))
but I don't think that's any easier to teach nor easier to read nor even easier to write. Or of course one could stick to one's guns and move the increment to the bottom line of the loop; but then one must also warn the contributor not to use `continue`; that leads to a nice structured-programming fixed-point but it may be unacceptable to some.]
IMO the paper should mention this use of comma, even if only to dismiss it as "not relevant because this is not a place the compiler would warn anyway" or "there are better ways to write this" or whatever. Just get the whole question out of the way, one way or another.
In a C++-future project wouldn't it be nice™ to be able to have as
coding policies 1) to forbid C-style casts (and especially those to
void), and 2) require people to use [[discard("with reason")]] instead¹?
FWIW, I say no; that sounds like churn for churn's sake. For me, I would particularly allow casts-to-void, because those have a long-standing meaning blessed by tradition; and also casts-equivalent-to-static-cast (which sadly would have to be enforced by clang-tidy, not by lint/grep); but forbid casts-equivalent-to-reinterpret-or-const_cast.
–Arthur