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
