On Friday, 11 March 2016 at 10:22:06 UTC, Jacob Carlborg wrote:
Another advantage of the contracts would be if the caller would be responsible for running the contracts. That is currently not the case. Then a library could be shipped with contracts and it's up to the user of the library to decide if the contracts should be executed or not.
The biggest problem with associating the contract with the source rather than the caller is that you only get those assertions when that library was built with assertions enabled, whereas in contracts are really testing the caller code, so what you really want is for them to be enabled or not depending on whether the calling code is compiled with assertions enabled or not. So, having the in contracts are compiled in based on the calling code would be huge IMHO (and certainly make using explicit in contracts very valuable), but there are definitely implementation issues with pulling that off. Right now, in contracts are basically just the beginning part of the function, whereas they need to be separate from it for the caller to be able to determine whether they're enabled or not, and how to do that in a way that works with our calling conventions is not immediately obvious.
Whether out contracts or invariants should be compiled in based on the caller is far less obvious though, since they're really testing the code that they're in, whereas in contracts are really testing the caller.
Regardless, if in contracts were improved to be compiled in or not based on how the calling code is compiled would definitely make it so that I'd use in contracts over just putting the assertions at the top of the function.
- Jonathan M Davis
