¿My understanding is that part of the reason Contracts caused this kind of failure is that it was set up to be a change far too deep? Like, if something like going for std hardening requires Contracts, I can understand the fear that we might end up in yet another std::regex situation except for the entirely of std::. On my initial attempts to read the Contracts papers, it all felt like a LLM was let loose on the Standard, and at points made me think “what if they changed the properties of double?”.
If it was designed to be decoupled so that Hardening does not depend on it, or if it was set up to be a partial implementation with an expectation to get completion across two Standards (so basically, “starts in 26, ends in 29” for example), could this have had a better result?
One major disagreement was on contracts being opt-in, but by who?
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.
If not, then there are all sorts of issues and code repetition between contract and function body.
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.
¿My understanding is that part of the reason Contracts caused this kind of failure is that it was set up to be a change far too deep? Like, if something like going for std hardening requires Contracts, I can understand the fear that we might end up in yet another
std::regexsituation except for the entirely ofstd::. On my initial attempts to read the Contracts papers, it all felt like a LLM was let loose on the Standard, and at points made me think “what if they changed the properties ofdouble?”.If it was designed to be decoupled so that Hardening does not depend on it, or if it was set up to be a partial implementation with an expectation to get completion across two Standards (so basically, “starts in 26, ends in 29” for example), could this have had a better result?
One major disagreement was on contracts being opt-in, but by who? 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. If not, then there are all sorts of issues and code repetition between contract and function body.
Both camps refused to budge
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