Hi Jason, You're definitely not the only one with this concern! Contracts and undefined behaviour have been a heated topic for quite some time, and concerns like yours have motivated proposals like this one [1] to address them.
> We could use this only if Clang adds a mode that, contrary to the standard, > guarantees that unchecked contracts do exactly nothing, while retaining all > the other optimizations that we rely on. Having the standard allow for or even mandate such a mode, or alternatively to avoid the need for "modes" by allowing the author to specify the desired semantics in the code itself, is a very popular request and the subject of several other papers, such as this one [2]. I'm not technically allowed to talk about the discussions that have taken place so far this week (and in any case nothing is final until the plenary votes on Saturday), but please do check /r/cpp on Saturday and have a look at the collaborative trip report that's usually released very soon after plenary ends. My strong suspicion is that one way or another, your fears will be allayed. With all that said, on the topic of blanket avoidance of undefined behaviour, I've found this CppCon talk by Chandler Carruth [3] to be very informative, and I would recommend it. Cheers, Botond [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1290r3.pdf [2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1429r2.pdf [3] https://www.youtube.com/watch?v=yG1OZ69H_-o On Thu, Jul 18, 2019 at 11:27 AM Jason Orendorff <jorendo...@mozilla.com> wrote: > > Botond, > > Presumably it's too late for the ongoing meeting, but I'm very concerned > about C++20 assertions. > > The proposal says that in a release build, any contract violation is > undefined behavior. Sounds reasonable enough. > > Every assertion adds potential UB. Hmm. > > ISTM this makes the feature very much off-limits for us. Undefined behavior > is bad. It accounts for most security vulnerabilities in Firefox. We could > use this only if Clang adds a mode that, contrary to the standard, guarantees > that unchecked contracts do exactly nothing, while retaining all the other > optimizations that we rely on. > > But is it really just us? Are these semantics good for anyone? C++20 > assertions seem to be a software-engineering quality-assurance feature > crazy-glued to a very tricky, dangerous, > squeeze-out-the-last-few-drops-of-CPU performance feature. But those two > things are more useful separately; and surely the latter should not be > designed to look like the former. I would like to understand the motivation > behind this. > > -j > > On Fri, Jul 12, 2019 at 11:25 PM Botond Ballo <bba...@mozilla.com> wrote: >> >> Hi everyone! >> >> The next meeting of the C++ Standards Committee (WG21) will be July >> 15-20 in Cologne, Germany. >> >> (Apologies for not sending this announcement sooner!) >> >> This is a particularly important meeting because the committee aims to >> publish the C++20 Committee Draft, a feature-complete draft of C++20 >> that will be sent out for balloting and comment from national >> standards bodies, at the end of this meeting. C++20 is probably going >> to be the language's largest release since C++11, containing an >> extensive lineup of significant new features (Concepts, Modules, >> Coroutines, Contracts, Ranges, and default comparisons (<=>), among >> others). Modules has just merged into the working draft at the last >> meeting, and continues to be under active discussion due to tooling >> impacts. Contracts are at risk of being pulled due to controversy. >> Even for uncontroversial features, technical issues that we can't fix >> in time are sometimes discovered and result in the feature being >> bumped to the next release. All in all, this is going to be a busy and >> eventful meeting. >> >> If you're curious about the state of C++ standardization, I encourage >> you to check out my blog posts where I summarize each meeting in >> detail (most recent one here [1]), and the list of proposals being >> considered by the committee (new ones since the last meeting can be >> found here [2] and here [3]). >> >> I will be attending this meeting, likely splitting my time between the >> Evolution Working Group (where new language features are discussed at >> the design level) and interesting Study Groups such as SG7 >> (Reflection) and SG15 (Tooling). As always, if there's anything you'd >> like me to find out for you at the meeting, or any feedback you'd like >> me to communicate, please let me know! >> >> Finally, I encourage you to reach out to me if you're thinking of >> submitting a proposal to the committee. I'm always happy to help with >> formulating and, if necessary, presenting a proposal. >> >> Cheers, >> Botond >> >> [1] >> https://botondballo.wordpress.com/2019/03/20/trip-report-c-standards-meeting-in-kona-february-2019/ >> [2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/#mailing2019-03 >> [3] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/#mailing2019-06 >> _______________________________________________ >> dev-platform mailing list >> dev-platform@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
