points by hollowonepl 4 days ago | 0 comments
I'm not surprised. Pace of adding new features vs. realistic added value, vs. complexity to get it properly standardised makes 3 years rounds to circulate new ISO C++ standard less and less possible without introducing major flaws that will continue sending C++ to hell in the eyes of Rustafarians and other safe languages folk.
[–] muvlon 4 days ago
[–] leni536 4 days ago
While the observe semantics example is somewhat scary, it isn't the end of the world. It is more than likely that `foo` dereferences p in the function body anyway, so the UB in the precondition is inconsequential.
You can fix every problem in language design with more language features, except "too many language features". Most people on the committee even seem to intellectually understand this, but their preferred time to stop adding new major features is "once my pet feature is in".
And to harp on the safety thing a bit: In the absence of an actually safe subset of C++, additional language complexity is also a safety problem. "best effort" safety like the stuff C++ is pursuing at the moment still relies on you knowing exactly what your code does, which is hindered by complexity.
Here's an example for contracts. Say you have the following declaration:
What happens if you pass a nullptr? You'd guess that it either raises a contract violation or silently ignores it, right? Yes, those are two possibilities, in the "enforce" and "ignore" modes respectively. But there's also an "observe" mode, where the preconditions are checked at runtime and violations reported but then execution resumes normally. Can you see the problem? Passing a nullptr causes evaluation of the second precondition to deref it, so we get UB from the contracts themselves before we ever hit the function body (which might have its own, classic nullptr checks, who knows). This is a completely new class of footgun that you never had with assertions (they are always either enforced or ignored).