DIP 1003 Formal Review

[MysticZach via Digitalmars-d]

On Monday, 15 May 2017 at 02:02:42 UTC, Basile B. wrote:
> On Monday, 15 May 2017 at 01:39:34 UTC, MysticZach wrote:
>> Not that a whole new way of doing things is called for... but 
>> I think a better design would have been to allow 'in' and 
>> 'out' statements in the function itself, with no need for 
>> brackets if you only have one line's worth of contract, e.g.,
>>
>> int fun(int a) {
>>   in assert(...);
>>   out(x) assert(...);
>>
>>   // do stuff
>> }
>
> It's nice, i like it but it cant work as simply. You're 
> forgetting that interface member functions can have contracts. 
> With this syntax interfaces member functions would always have 
> a body BUT the current semantic is that interface member 
> functions with bodies are final methods. Boom. Interfaces don't 
> work anymore because there's no easy way to make the difference 
> between an interface member function that's final and an 
> interface member function that's not pre-implemented (so 
> overridable) but has contracts.

It seems to me that the compiler could detect a presence or lack 
of a body simply by the presence or absence of any statement 
after the contracts, i.e.,

interface D {
   // fun is implicitly overridable here
   int fun() {
     in assert(...);
   }
}

Also, does a final function with contracts, but no body, make any 
sense? What's the use case?

Even if there were some use case for it, I can think of two 
solutions. One is to keep and require the current syntax for an 
interface function without a body. This is the natural way to 
install contracts anyway, for a function with no body.

The other solution is to recommend the addition of an empty 
statement, for an empty final function, e.g.:

// final
int fun() {
   in assert(...);
   {}
}

Considering what Jonathan said about how he never uses contracts 
because they're so bulky, might it not be worth it to solve the 
interface problem in either of the above two ways?