Thanks Paul for this analysis. Copying Wouter in case he does not have SG14
access yet.

On Thu, Feb 11, 2021 at 3:08 AM Paul M. Bendixen via SG14 <
sg14_at_[hidden]> wrote:

> After a (long overdue) complete read of both r0 and r4 of p1152 i have
> come to a few conclusions:
>
> 1. While the motivation in r0 is quite thorough, it fails to convey
> the dangers of using the compound volatile operations in higher level
> highly threaded code that was alluded to in tonight's meeting.
> If anyone could enlighten me further in this regard I'd be much
> obliged.
> 2. The changes that Wouter and others (myself included) found
> frightening were mostly neglected in R0: "This is a departure from C
> which breaks source compatibility (once removed), but maintains ABI
> compatibility."
> And even though the committee was heard on the question, the
> question was before SG1 and EWG ( from r0 -> r1 changelog), not
> necessarily parts of the committee that are affected by the proposed
> changes (compound operations).
> 3. The only change to the r4 paper that I can see would be necessary
> is in 3.7 item 9 where "op=" is discussed.
>
> I would posit that, put before SG14 the vote on "Deprecate volatile
> compound operations (including ++ and --) on scalar types (arithmetic,
> pointer, enumeration)." would have been a very different one and we
> might even revisit this at the next embedded themed SG14 meeting.
>
> The concerns regarding incorrect usage of the comppound operations is
> not as bad as they are made out to. It is even there in the standard
> right next to it:
> "The behavior of an expression of the form E1 op= E2 is equivalent to
> E1 = E1 op E2 except that E1 is evaluated only once"
> While the wording might be a bit clearer this explicitly states that
> it is the same. Examples regarding tearing in the parts of volatile
> that have been retained are also mentioned in the paper and as such I
> do not see the reason why this usage of volatile should be any more
> onerous.
>
> Regarding the concern of breaking functioning code expressed as code
> that must operate on variables that must be declared volatile that
> also has a controlled application of the compound operation, I find
> that it has not been very well examined and I am perplexed that the
> committee would break codebases for such a large part of the C++
> community.
>
> The paper even acknowledges the quite early retirement of volatile,
> with the, in my eyes, incorrect assumption:
> "Now that codebases use atomic and have moved away from erroneous
> volatile, we believe deprecation is warranted. In other words, what
> would have been a disastrous breaking change for C++11 is merely good
> house-cleaning for C++20." (from r0)
>
> Finally, on a more introspective note, this leaves me with some doubts
> regarding what we are doing here.
> This paper has its r0 date in 2018. I have been following this group
> since at least then and cannot remember it ever being mentioned before
> being part of the standard.
> If the purpose of this group is to be an outreach group and get the
> opinions of people who don't regularly attend standards meetings, then
> this paper becoming standard marks a failure on this point to me.
> We need to do better and I would like to hear from the rest of the
> group if you have any idea as to how.
>
> Before going too much into discussions on this, please read the two
> paper versions (that are actually different papers), they are well
> written and relatively short and having read through them will give
> you a better understanding of what is being discussed and will prevent
> others from having to tell you what is in them.
>
> Best Regards
> Paul M. Bendixen
> --
> • − − •/• −/• • −/• − • •/− • • •/•/− •/− • •/• •/− • • −/•/− •/• − −
> •− •/− − •/− −/• −/• •/• − • •/• − • − • −/− • − •/− − −/− −//
> _______________________________________________
> SG14 mailing list
> SG14_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg14
>