DIP 1009--Improve Contract Usability--Preliminary Review Round 1

jmh530 via Digitalmars-d digitalmars-d at puremagic.com
Thu Jun 22 07:08:32 PDT 2017


On Thursday, 22 June 2017 at 12:21:29 UTC, MysticZach wrote:
>
> I understand. Thus, a better DIP would suggest reimplementing 
> D's DbC system altogether. Because as it is, they are little 
> more than syntax dressing, which happens to be less convenient 
> that just writing out the asserts in the first place. They're 
> more like syntax _vinegar_ than sugar. Which explains why 
> hardly anyone uses them. Why write this:
>
> int fun(int a)
> in { assert (a); }
> do {
>     return a;
> }
>
> ...when you could just do this:
>
> int fun(int a) {
>    assert(a);
>    return a;
> }
>

My recollection is that the most significant reason to use 
contracts in D is because of contract inheritance. There's a lot 
of focus in this discussion on normal functions, when I would say 
that contracts really aren't even needed.

So a more useful situation to consider then is:

class Foo
{
     int fun(int a)
     in {
         assert(a > 0 && a < 10);
     }
     body {
         return a;
     }
}

class Bar : Foo
{
     int fun(int a)
     in {assert(a > 0);}
     body {
         return a;
     }
}

I would say keep the current behavior for backwards compatibility 
(maybe with the body/do change), but also allow the following 
code:

class Foo
{
     int fun(int a)
     {
         in {
             assert(a > 0 && a < 10);
         }
         return a;
     }
}

class Bar : Foo
{
     int fun(int a)
     {
         in {assert(a > 0);}
         return a;
     }
}

where the compiler would effectively re-write this into the code 
above. You wouldn't need to make a change to interfaces since 
they don't have bodies anyway.




More information about the Digitalmars-d mailing list