Suggested Change to Contract Syntax

[Jonathan M Davis via Digitalmars-d]

On Thursday, 10 March 2016 at 23:31:22 UTC, FatalCatharsis wrote:
> On Thursday, 10 March 2016 at 22:57:41 UTC, Jonathan M Davis 
> wrote:
>> If/Once we get more features in the compiler which take 
>> advantage of contracts, then I'll likely change my tune on 
>> that one, but for now, IMHO, they're really only of value in 
>> classes.
>
> I'm curious, what kind of features might come out of contracts 
> in the future? They seem somewhat helpful in terms of QA and 
> organization, but what kind of compiler or performance gains 
> could you gain from this system?

Well, if you had something like

     auto foo(int i)
     in
     {
         assert(i > 10 && i < short.max + 5);
     }
     body
     {
         ...
     }

and the the code called it with a value that's known at compile 
time - e.g. foo(2) - and that value clearly fails the contract, 
then the compiler could treat that as an error. Similarly, it 
would know the valid range of i within the function body, which 
might help with optimizations or with VRP (value range 
propagation - i.e. how it can know that an integral value can fit 
in a smaller integral type and use an implicit cast rather than 
requiring an explicit cast).

Or if you do something with out contracts, e.g.

     int foo(int i)
     out(result)
     {
         assert(result => 0 && result < 100);
     }
     body
     {
         ...
     }

then in theory, the compiler could assume that the result passed 
the out contract and optimize based on that. For instance, with 
the code above, maybe it would then treat the result of foo as 
fitting it a ubyte without a cast, because it would know that as 
long as the contract passed, it would fit. e.g.

     ubyte bar = foo(9);

Now, I suspect that stuff like that tends to be restricted to 
basic examples, particularly since you usually pass variables to 
functions, not literals, and at the moment, I can't think of much 
useful other than VRP for what could be done with out contracts, 
but in theory, the compiler would know more about what the 
function parameters and return value, and in at least some cases, 
it could optimize based on that or allow certain operations that 
might not be done implicitly in the general case.

So, at this point, I think that it's pretty much all theoretical, 
but we might benefit from it at some point. And given that we 
don't know when such improvements might be made or exactly what 
code they'd benefit, it's arguably better to just use in and out 
contracts now just in case we get those improvements later, and 
the code then benefits without you having to change it, but 
personally, I don't think that that's worth the extra syntactic 
mess, particularly since while such improvements have been 
discussed upon occasion, it's not at all clear that we're ever 
going to get anything like them.

- Jonathan M Davis