I don't disagree with this criticism at all. P2327R0 doesn't provide any
viable solutions IMHO. Consequently, i decided to write this paper very
deliberately as this is what C++20 compatibility would require today.
Maybe I should make the point in the draft that these various deprecations
are severable.

On Sat, May 22, 2021, 12:02 PM Ben Craig via Liaison <
liaison_at_[hidden]> wrote:

> I agree that we should make things compatible. I do think that C++ should
> revert the compound assignment deprecation though (and C shouldn't adopt it
> in the first place).
>
> I don't know that this group has talked through
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2327r0.pdf yet.
> I think it was on the agenda with the deprecating volatile paper, but that
> we didn't have time to discuss it.
>
> For the compound operators, I will highlight section 2.3 in P2327R0. We
> are trading one source of bugs (people misunderstanding RMW cycles) for
> another set of bugs (incomplete copy / pastes). The RMW cycle category of
> bugs can generally be fixed with education and code review. The incomplete
> copy / pastes are much harder to address. From P2327R0...
>
> UART1−>UCSR0B |= (1<<UCSZ01 ) ;// original code
> UART1−>UCSR0B = UART1−>UCSR0B | (1<<UCSZ01 ) ;// correct replacement
> UART2−>UCSR0B = UART1−>UCSR0B | (1<<UCSZ01 ) ;// incorrect replacement
>
> In practice, memory mapped registers often have cryptic names with numbers
> in them, making typos and copy / paste errors particularly annoying to spot.
>
> My suggestion to implementers would be to provide an off-by-default
> warning that diagnoses compound volatile assignment. This way programmers
> have the tools to find potentially buggy code and determine for themselves
> if they would prefer duplication or not.
>
> P2327R0 De-deprecating volatile compound operations
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2327r0.pdf>
> Number: P2327R0 Title: De-deprecating volatile compound operations
> Project: ISOJTC1/SC22/WG21: ProgrammingLanguageC++ Audience:
> SG14,SG1,SG22,EWG,WG21 Date: 2021-04-15 Authors: PaulM.Bendixen<
> paulbendixen_at_[hidden]> Contributors: JensMaurer ArthurO’Dwyer BenSaks
> Email: paulbendixen_at_[hidden] Reply to: PaulM.Bendixen Revision history 1
> Introduction TheC++ ...
> www.open-std.org
> **
>
> ------------------------------
> *From:* Liaison <liaison-bounces_at_[hidden]> on behalf of Aaron
> Ballman via Liaison <liaison_at_[hidden]>
> *Sent:* Saturday, May 22, 2021 10:25 AM
> *To:* WG14/WG21 liaison mailing list <liaison_at_[hidden]>
> *Cc:* Aaron Ballman <aaron_at_[hidden]>
> *Subject:* [EXTERNAL] Re: [wg14/wg21 liaison] n2743 Volatile C++
> Compatibility
>
> On Sat, May 22, 2021 at 10:49 AM Philipp Klaus Krause via Liaison
> <liaison_at_[hidden]> wrote:
> >
> > Am 22.05.21 um 16:08 schrieb Robert Seacord via Liaison:
> > > I'm looking for reviews / comments for n2743 Volatile C++ Compatibility
> > > before submission. If you are interested in reviewing, you can find a
> > > PDF of the proposal here:
> > >
> > >
> https://urldefense.com/v3/__http://robertseacord.com/wp/2021/05/22/volatile-c-compatibility/__;!!FbZ0ZwI3Qg!7Yu05pctEl1XYnq3M4GCocO9OqOSfo11xSkwBukxu79IHlmrY8WdISCcVqNc$
> > > <
> https://urldefense.com/v3/__http://robertseacord.com/wp/2021/05/22/volatile-c-compatibility/__;!!FbZ0ZwI3Qg!7Yu05pctEl1XYnq3M4GCocO9OqOSfo11xSkwBukxu79IHlmrY8WdISCcVqNc$
> >
> > >
> > > Thanks,
> > > rCs
> >
> > People use compound operators, increment and decrement on memory-mapped
> > I/O registers.
> > The justification of basically 'compound operators are misleading, since
> > they look as if there was only one memory access instead of a read
> > followed by a write' seems very weak to me. Users of volatile tend to be
> > working close to the hardware, knowing how the hardware works.
>
> FWIW, my personal experience has been that this is a significant cause
> of confusion even for people who are experienced working close to the
> hardware.
>
> > The remaining rationale apparently is just 'C++ removed the feature, so
> > we should, too', which also seems a rather weak one to me.
>
> Some of the deprecations touch on interfaces that would plausibly show
> up in headers shared between C and C++ (specifically, volatile on
> return types and on parameter types), so those particular cases are of
> importance for compatibility between C and C++.
>
> ~Aaron
>
> >
> > Philipp
> > _______________________________________________
> > Liaison mailing list
> > Liaison_at_[hidden]
> > Subscription:
> https://urldefense.com/v3/__https://lists.isocpp.org/mailman/listinfo.cgi/liaison__;!!FbZ0ZwI3Qg!7Yu05pctEl1XYnq3M4GCocO9OqOSfo11xSkwBukxu79IHlmrY8WdIVgKSfCK$
> > Link to this post:
> https://urldefense.com/v3/__http://lists.isocpp.org/liaison/2021/05/0583.php__;!!FbZ0ZwI3Qg!7Yu05pctEl1XYnq3M4GCocO9OqOSfo11xSkwBukxu79IHlmrY8WdId_Ys7fr$
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription:
> https://urldefense.com/v3/__https://lists.isocpp.org/mailman/listinfo.cgi/liaison__;!!FbZ0ZwI3Qg!7Yu05pctEl1XYnq3M4GCocO9OqOSfo11xSkwBukxu79IHlmrY8WdIVgKSfCK$
> Link to this post:
> https://urldefense.com/v3/__http://lists.isocpp.org/liaison/2021/05/0585.php__;!!FbZ0ZwI3Qg!7Yu05pctEl1XYnq3M4GCocO9OqOSfo11xSkwBukxu79IHlmrY8WdIQZJ2C0f$
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post: http://lists.isocpp.org/liaison/2021/05/0586.php
>