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@lists.isocpp.org> 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.

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@gmail.com> Contributors: JensMaurer ArthurO’Dwyer BenSaks Email: paulbendixen@gmail.com Reply to: PaulM.Bendixen Revision history 1 Introduction TheC++ ...


From: Liaison <liaison-bounces@lists.isocpp.org> on behalf of Aaron Ballman via Liaison <liaison@lists.isocpp.org>
Sent: Saturday, May 22, 2021 10:25 AM
To: WG14/WG21 liaison mailing list <liaison@lists.isocpp.org>
Cc: Aaron Ballman <aaron@aaronballman.com>
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@lists.isocpp.org> 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@lists.isocpp.org
> 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@lists.isocpp.org
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@lists.isocpp.org
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
Link to this post: http://lists.isocpp.org/liaison/2021/05/0586.php