If we want library-authors to opt-in, then we need a way to run contracts for a library when it’s disabled for the compilation unit.
Why? It’s the end user of the compiler who is compiling the code, and if ultimately I decide to compile my helloworld.cpp, that uses seven Boost libraries to do what printf does, with contracts disabled, then that includes the code that I’m… well, #includeing.
Mostly comes down to how good the default behaviour a library wants to present. Eg: how do we convert a simple if check with a return in case of nullptr with contracts? Do we duplicate and have it in contacts and fn body or just contacts? If just contacts, the compiler will be able to apply optimizations assuming contracts hold but the user might put the contact in observe mode. So, we need duplicate content, and then there’s not much benefit of contracts
If a contract has to apply to what it goes inside the body of the function, then it has to go, and be limited to, inside the body of the function. Else we get a longer version of the whole explicit(body_of_function) noexcept(noexcept(body_of_function)) function (arguments_of_function) { body_of_function } decltype(body_of_function) debacle. And, to me, that makes sense: if for example you are only using the fact that a function name exists, but are not invoking it, you only need the declaration, you don’t need any of that added hassle.
Accepting that a contract can go outside the function, means being able to accept that a user of the function should be able to load only the function and not its contract, for example for no-contract modes, or for compatibility with older compilers. It’s no different from nothrow modes, or accepting that we can #ifdef nonworking pieces of code away.
Why? It’s the end user of the compiler who is compiling the code, and if ultimately I decide to compile my helloworld.cpp, that uses seven Boost libraries to do what
printfdoes, with contracts disabled, then that includes the code that I’m… well,#includeing.Mostly comes down to how good the default behaviour a library wants to present. Eg: how do we convert a simple if check with a return in case of nullptr with contracts? Do we duplicate and have it in contacts and fn body or just contacts? If just contacts, the compiler will be able to apply optimizations assuming contracts hold but the user might put the contact in observe mode. So, we need duplicate content, and then there’s not much benefit of contracts
Correct me if I’m wrong:
If a contract has to apply to what it goes inside the body of the function, then it has to go, and be limited to, inside the body of the function. Else we get a longer version of the whole
explicit(body_of_function) noexcept(noexcept(body_of_function)) function (arguments_of_function) { body_of_function } decltype(body_of_function)debacle. And, to me, that makes sense: if for example you are only using the fact that a function name exists, but are not invoking it, you only need the declaration, you don’t need any of that added hassle.Accepting that a contract can go outside the function, means being able to accept that a user of the function should be able to load only the function and not its contract, for example for no-contract modes, or for compatibility with older compilers. It’s no different from nothrow modes, or accepting that we can
#ifdefnonworking pieces of code away.And that’s the criticism of current design that it doesn’t address issues like this and feels like half baked from certain pov
The nothrow (or whatever got deprecated) was a similarly poor design where the headaches weren’t worth the benefits