| It’s giving you an expression capability so that you can state your intent, in a standardized way, that other tooling can build off. But it’s recognizing that the degree of enforcement depends on applied context. A big company team might want to enforce them rigidly, but a widely used tool like Visual Studio would not want to prevent code from running, so that folks who are introducing themselves to the paradigm can start to see how it would work, through warnings, while still being able to run code. |
| |
| ▲ | riazrizvi 4 days ago | parent | next [-] | | Perhaps another helpful paradigm are traffic/construction cones with ‘do not cross’ messages. Sometimes nothing happens, other times you run into wet concrete, other times you get a ticket. They’re just plastic objects, easy to move, but you are not meant to cross them in your vehicle. While concrete bollards are a thing, they are only preferable in some situations. | | |
| ▲ | SkiFire13 4 days ago | parent [-] | | I don't think this analogy fully respects the situation here. These pre/post condition are not just adding a warning to not do something, they also add a potentially bigger danger if they are broken. It's as if you also added a trap behind the construction cone which can do more damage than stepping on the wet concrete! |
| |
| ▲ | Phil_Latio 4 days ago | parent | prev [-] | | > documentation clearly states that it's UB to violate them Only in "fast" mode. The developer has the choice: > Compilation has two modes: “safe” and “fast”. Safe mode will insert checks for out-of-bounds access, null-pointer deref, shifting by negative numbers, division by zero, violation of contracts and asserts. | | |
| ▲ | SkiFire13 4 days ago | parent [-] | | > The developer has the choice The developer has the choice between fast or safe. They don't have a choice for checking pre/post conditions, or at least avoiding UB when they are broken, while getting the other benefits of the "fast" mode. And all in all the biggest issue is that these can be misinterpreted as a safety feature, while they actually add more possibilities for UB! | | |
| ▲ | Phil_Latio 3 days ago | parent [-] | | Well, the C3 developer could add more fine grained control if people need it... I don't really see what's your problem. It's not so much different than disabling asserts in production. Some people don't do that, because they rather crash than walking into invalid program state - and that's fine too. It largely depends on the project in question. | | |
| ▲ | SkiFire13 3 days ago | parent [-] | | > It's not so much different than disabling asserts in production. Disabling asserts would be equivalent to not having them at all, while this feature introduces _new_ UB. In "fast" mode it's equivalent to using C's `__builtin_assume` or Rust's `std::hint::assert_unchecked`, except it's marketed with a name that makes it appear a safety/correctness feature. |
|
|
|
|
