Suggested Change to Contract Syntax

[Jonathan M Davis via Digitalmars-d]

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