Il 05/10/23 22:24, Arthur O'Dwyer via Std-Proposals ha scritto:
>
> > We can’t disallow it, in the spirit of ignorability of attributes.
> seems wrong; adding an attribute in an inappropriate location (e.g.
> [[fallthrough]] on a non-null statement, or on a function declaration)
> is certainly permitted to (and does) give a hard error.

OK, I am not going to reopen *that* can of worms and and I will cut the
sentence.


> > Appearance of a discouraged nodiscard call is discouraged.
> :perfection:
> I suggest combining this sentence with the next one: "Implementations
> should issue a warning whenever a discouraged nodiscard call is
> encountered."

Can certainly do, but I wonder where the "discouraged" term in the
existing wording comes from. It's otherwise used only a handful of
times, so I wonder if it's a "term of power" of some sorts and should be
kept.


>
> > explicitly cast to void
> The wording in https://eel.is/c++draft/expr.static.cast#6
> <https://eel.is/c++draft/expr.static.cast#6> is "explicitly converted to
> void"; I think you should say "explicitly converted to void
> ([expr.static.cast])" because the cross-reference is useful.

Pre-existing, but sure.


> I can see this example of yours causing headaches for style-guide writers:
> > enable_missile_safety_mode(); // warning encouraged
> > [[discard]] my_unique(), enable_missile_safety_mode(); // warning
> not encouraged
> The benefit of (void)my_unique() is that the cast binds tightly to the
> ignored thing; [[discard]] as proposed seems to bind super loosely. If
> it bound as tight as any other prefix operator, that would help.
> (As you said on Slack, the counterargument is that people who use
> [[discard]] should not be using the comma operator.)


Precisely. If you're writing a style guide, please write "do not use the
comma operator". Once we're in that scenario, then the fact that

  [[discard]] foo();

is technically speaking an attribute on the statement (and not on the
expression) won't matter at all, it will "just work".


> It looks to me like there are only three kinds of discarded-value
> expressions in the entire language:
> - expression-statements https://eel.is/c++draft/stmt.expr#1.sentence-2
> <https://eel.is/c++draft/stmt.expr#1.sentence-2>
> - left-hands of comma operators
> https://eel.is/c++draft/expr.comma#1.sentence-2
> <https://eel.is/c++draft/expr.comma#1.sentence-2>
> - things cast to void
> https://eel.is/c++draft/expr.static.cast#6.sentence-1
> <https://eel.is/c++draft/expr.static.cast#6.sentence-1>
> It would be useful, IMHO, to put this information in the paper, so
> nobody else has to ask or look it up.

Can do, although it's probably more on topic for the `[[nodiscard]]`
attribute. And yes, I also think that this is a comprehensive list, with
the caveat of parenthesized expressions whose inner expressions can be
discarded-value as well.


> FWIW, personally I'd be in F of allowing attributes on expressions (with
> prefix syntax /*and prefix-operator high precedence*/, which at the
> moment you have not got),

I'd be glad for inputs, because I don't see how to fix the clash with
attributes on statements, that is, in `[[attribute]] x;` the attribute
already appertains to the statement and not to the expression. I do not
want to start making decisions based on the kind of attribute.


> but A or SA the proposed [[discard]] attribute
> since it's just another way of spelling something that — as you point
> out — we've already got several competing ways of spelling. And it's
> much more cumbersome to write, to read, and probably even to parse, than
> (void)f().

I'd say that instead it's just yet another weird remnant of C that we
now use because that's all we have; this is a case of "familiarity" vs.
"the right thing to do".


As usual, thank you so much for your feedback.

-- 
Giuseppe D'Angelo