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