To everyone who has the “contracts can inject new UB in observe mode” concern: This is a fine concern. I encourage you to keep raising it and we will hear it again in Kona. Summarizing the “new UB” concern for everyone, it’s that in cases like the following, the second line might introduce “new” UB if the body of the function doesn’t otherwise dereference p:

               contract_assert (p != nullptr);

               contract_assert (p->foo());

I have just one request please, to try to reduce a lot of repetitive email list traffic (and Kona discussion time) about this: PLEASE, whenever you mention this concern, could you include a brief acknowledgment like ‘yes, this new-UB problem is existing practice using any assertion library with a check-and-continue mode’? [*]

Of course you’re still fully free to add “but that’s bad and we still don’t want such a mode in the standard!” That’s totally fine. [**]

I think including that brief acknowledgment could reduce a lot of the repetitive replies where people seem to feel obliged to repetitively keep pointing this out (often at great length) each time the “new UB” issue is mentioned.

It’s up to you of course, but thanks for considering this request.

Herb

[*] Such as BOOST_ASSERT when used with a violation handler that continues (thanks to Peter Dimov, the maintainer, for confirming!), more generally any assertion library that supports a violation handler that returns, Boost.Test’s check-and-continue macros (BOOST_TEST, BOOST_WARN, BOOST_CHECK), and other similar libraries.

I did a quick search on GitHub using the regexes

/BOOST_ASSERT.*!=\snullptr/

and

/BOOST_CHECK.*!=\snullptr/

For each one, the results contained many examples of “assert p not null; assert p->something;” as separate assertions, with check-and-continue semantics. Here’s a quick example hit for each query, both in the first half-dozen search results:

• BOOST_ASSERT example: Here’s one in Matúš Chochlík’s Python C++ code generator.

• BOOST_CHECK example: Here’s one in an LLVM unit test – and the same function has three more examples… another null example, and two examples that (if I’m reading them right) are “assert string is null-terminated; assert strlen(string) == something;” which would be equivalently UB.

[**] It would really help to know from Boost.Assert/Boost.Test maintainers, and similar assertion library maintainers, if such existing examples have generated user complaints and bug reports about the second assertion’s UB? That would be a good data point in favor of not allowing such examples to be written using the standardized facility.