Contracts are all about introducing undefined behaviour if you don't satisfy a precondition.
In practice this improves software quality on many levels by clearly defining requirements on interface boundaries that would otherwise be implicit or just documented.
Of course you can have special debug modes where you actually check that contracts are being satisfied.
As ever the C++ train leaves on schedule with or without anything you suppose is "promised" for that standard revision. This has been the practice since 2011 and I don't expect it to stop unless ISO tells them "Enough" or the whole thing comes apart.
> Contracts are all about introducing undefined behaviour if you don't satisfy a precondition.
Nope. That's explicitly not what the proposal sets out to do. It is likely that, as usual, WG21 will manage to take facilities intended to be safe, file them to a sharp edge and then slit their own throats, but P2900 in its current form doesn't do so. Here's an item from the proposal's list of things they're explicitly not proposing:
"The ability to assume that an unchecked contract predicate would evaluate to true, and allow the compiler to optimize based on that assumption, i.e. the assume semantic"
One of the three significant implementers, Microsoft, actually strongly objects to any idea of introducing yet more Undefined Behaviour into a language that is distinctly underwater when it comes to provable correctness. Microsoft shut down previous proposals in this area, and while they might (wrongly IMO) be sold the compromise position that's advocated by some WG21 members today (some UB in some contract checks), you're asking for a lot more.
Now regarding undefined behaviour, it's always been the reason why the proposal isn't moving forward. Some people believe religiously undefined behaviour is evil and will oppose anything tied to it. The kind of clause you mentioned is just to appease them and attain a compromise.
But ultimately, contracts and undefined behaviour (depending on the definition you go for) are intimately linked.
Consider lower_bound. The behaviour is undefined if the input is not sorted. That's just the way it is.
You can't magically make a program well-formed if you breach preconditions even if you say optimizers are not allowed to make additional assumptions.
No, it's a classic WG21 choice in that it's pointlessly worse, that's not "the way it is" it's just the way WG21 decided to define it in C++. More reasonable choices would obviously include the choice made over in std::set where lower_bound gives you a past-the-end iterator if there isn't an apparent answer for your inputs.
Undefined Behaviour is the worst choice, which is why in a horrible way it makes sense as WG21's default - a group known for always choosing bad defaults.
> You can't magically make a program well-formed if you breach preconditions
Of course you can, it's not even hard.
I thought they invented Go for these things?
