Date: Thu, 5 Oct 2023 16:24:53 -0400
On Thu, Oct 5, 2023 at 4:03 PM Giuseppe D'Angelo via Std-Proposals <
std-proposals_at_[hidden]> wrote:
>
> Hoping that EWGI will reconvene in Kona, I have prepared a proposal to
> allow attributes on expressions, and also proposes the [[discard]]
> attribute. It is a draft ... of a draft -- there's still some design
> work to be done, possibly with EWG(I) help.
>
> https://isocpp.org/files/papers/D2992R0.html
>
> As usual, any early feedback is very much appreciated.
>
Copying my comments from Slack...
> 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.
> 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."
> explicitly cast to void
The wording in 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.
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.)
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
- left-hands of comma operators
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
It would be useful, IMHO, to put this information in the paper, so
nobody else has to ask or look it up.
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), 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().
my $.02,
–Arthur
std-proposals_at_[hidden]> wrote:
>
> Hoping that EWGI will reconvene in Kona, I have prepared a proposal to
> allow attributes on expressions, and also proposes the [[discard]]
> attribute. It is a draft ... of a draft -- there's still some design
> work to be done, possibly with EWG(I) help.
>
> https://isocpp.org/files/papers/D2992R0.html
>
> As usual, any early feedback is very much appreciated.
>
Copying my comments from Slack...
> 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.
> 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."
> explicitly cast to void
The wording in 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.
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.)
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
- left-hands of comma operators
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
It would be useful, IMHO, to put this information in the paper, so
nobody else has to ask or look it up.
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), 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().
my $.02,
–Arthur
Received on 2023-10-05 20:25:07