If I put them in the header, I have to include half the world because I can't forward declare `Foo foo` argument if I want to check `foo.size() > 3` or similar in a pre/post-condition. This is a non-starter, keeping headers lean is the only way to not end up with 1 hour compiles.
If I put them in the cpp, they lose their only advantage over asserts - that they also double as documentation in the headers.
Did we add 50 pages to the standard for a slightly fancier assert? I feel like this could've been one builtin and a footnote:
contract_assert(expr) - if expr evaluates to false, the behavior of the program is undefined. Implementations are encouraged to emit a runtime check for this in debug builds, or a compiler error in cases where they can statically determine, that the assert will fail.
The first declaration of a function must include the contract pre/post conditions and follow-up re-declarations of the function must either not include any contract conditions or the same conditions as the initial declaration.
And you can avoid re-including the world because pre/post conditions should be externally visible behavior or call out to functions for pre/post checks on internal behavior.
Essentially you either define them using what you have in scope during the initial declaration or you call out to a function located elsewhere that can have access to more/internal scope and do more complicated checks.
I'm expecting to see talks (and buy books, read blogs...) in 3 years by someone who spent a lot of work adding contracts to a small but significant code base. This is the type of question they will answer.
I think the right answer is in the header, and in turn that means someone needs to answer your objection - how do you avoid long compiler times? I suspect modules is a large part of the answer, which means the guide/talk will also be how to make modules work in the real world. Remember though, that is all guesses I wouldn't be surprised if I'm wrong.
Hmm, I thought I had watched all his talks on contracts by now, but I must have missed a few (which isn't a surprise - there are a lot of conferences out there that I can't watch them all and get anything done. I end up ignoring a lot of them)
I hadn't seen that talk, but the content is just an updated rehash of this is what contracts can do.
What I want I'd : we have used contracts in the tall world. This is what works and doesn't. This catches a lot of bugs for little work. This looks the same but results in false positives. This is a lot of work for few bugs.
Of course since I don't know what works I'm guessing, but that type of thing.
Ideally we would have Eiffel or Ada/SPARK kind of approach, or even something like Frama-C.
However given all the technical issues with C++ semantics, and the whole politics regarding contracts since the C++20 removal, I am not sure we will ever get there.
It will be the same as with modules or concepts, the main people behind the proposals eventually move on, and there is no one left to pick the up the pieces for the follow up papers, and related implementation.
If I put them in the header, I have to include half the world because I can't forward declare `Foo foo` argument if I want to check `foo.size() > 3` or similar in a pre/post-condition. This is a non-starter, keeping headers lean is the only way to not end up with 1 hour compiles.
If I put them in the cpp, they lose their only advantage over asserts - that they also double as documentation in the headers.
Did we add 50 pages to the standard for a slightly fancier assert? I feel like this could've been one builtin and a footnote:
contract_assert(expr) - if expr evaluates to false, the behavior of the program is undefined. Implementations are encouraged to emit a runtime check for this in debug builds, or a compiler error in cases where they can statically determine, that the assert will fail.