Date: Tue, 23 Feb 2021 20:05:57 +0100
On 23/02/2021 19.45, Arthur O'Dwyer via SG14 wrote:
> The point of Paul's paper, as I understand it, is /*not */to firm up the rules around volatile, but simply to undeprecate some syntactic constructs.
>
> Situation in the 1990s through 2020: `vx += y;` compiles, with unclear formal semantics, but if you don't care about portability then you can use it and not get any diagnostics.
> Situation post-2020: `vx += y;` compiles, with unclear formal semantics, but if you don't care about portability then you can use it; but the implementation is /formally encouraged/ to give you a deprecation diagnostic.
> Situation Paul is trying to achieve: `vx += y;` compiles, with unclear formal semantics, but if you don't care about portability then you can use it and not get any diagnostics. (This is identical to the pre-2020 situation.)
>
> Goal for the paper: Through informal language, convince WG21 that "Situation Paul is trying to achieve" is somehow /better/ than "Situation post-2020."
Yes. Please don't go any further for this paper.
> I'm still extremely unconvinced myself — mainly due to lack of examples in the paper
Adding another example from another embedded library would probably
be helpful, just to show the "it's used everywhere" rationale.
Or maybe just a few URLs to publicly-available code, if there is any.
> — but even with examples, you still need to explain why "add -Wno-deprecated to your makefile" isn't a reasonable medium-term solution.
Maybe because you still want deprecation warnings for everything else,
so this is too much of a shotgun.
Let's not over-think or over-engineer the paper, but let's get it out quickly.
(We want this fixed for C++23.)
Jens
> The point of Paul's paper, as I understand it, is /*not */to firm up the rules around volatile, but simply to undeprecate some syntactic constructs.
>
> Situation in the 1990s through 2020: `vx += y;` compiles, with unclear formal semantics, but if you don't care about portability then you can use it and not get any diagnostics.
> Situation post-2020: `vx += y;` compiles, with unclear formal semantics, but if you don't care about portability then you can use it; but the implementation is /formally encouraged/ to give you a deprecation diagnostic.
> Situation Paul is trying to achieve: `vx += y;` compiles, with unclear formal semantics, but if you don't care about portability then you can use it and not get any diagnostics. (This is identical to the pre-2020 situation.)
>
> Goal for the paper: Through informal language, convince WG21 that "Situation Paul is trying to achieve" is somehow /better/ than "Situation post-2020."
Yes. Please don't go any further for this paper.
> I'm still extremely unconvinced myself — mainly due to lack of examples in the paper
Adding another example from another embedded library would probably
be helpful, just to show the "it's used everywhere" rationale.
Or maybe just a few URLs to publicly-available code, if there is any.
> — but even with examples, you still need to explain why "add -Wno-deprecated to your makefile" isn't a reasonable medium-term solution.
Maybe because you still want deprecation warnings for everything else,
so this is too much of a shotgun.
Let's not over-think or over-engineer the paper, but let's get it out quickly.
(We want this fixed for C++23.)
Jens
Received on 2021-02-23 13:06:02