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

[Moritz Maxeiner via Digitalmars-d]

On Wednesday, 21 June 2017 at 01:06:40 UTC, MysticZach wrote:
> On Tuesday, 20 June 2017 at 21:04:16 UTC, Steven Schveighoffer
>
>> IMO, this whole proposal doesn't carry enough weight, either 
>> your version or the DIP itself. I would not be in favor. 
>> Current syntax is understandable, and not too verbose IMO.
>
> That's a fair opinion. I wish I had a crystal ball to see how 
> many more people would use contracts if this DIP were accepted.

Well, one more datapoint for your prediction model, then: Not me. 
I like DbC, but both what D currently has (too verbose) as well 
as what this DIP does (see below) is not acceptable to me:
Enhancement 1 introduces significant cognitive dissonance for me 
and I would argue that it also introduced a language 
inconsistency by polluting the space between normal function 
signature and body with ";". My brain keeps screaming "NO" when I 
see it. Maybe I could get used to it, but if I allow "less than 
ideal (within the limits of the language, of course)" as an 
acceptable goal, I can just stick to checks like assert in the 
function body; at least I (and most people reading my code) are 
already familiar with that.
Enhancement 2 is fine in and of itself, but compounds the issues 
caused by 1
Enhancement 3 introduces even more cognitive dissonance for me by 
breaking the model that contracts are part of a functions 
signature, not its body. I can also already do checks in the 
function body as shown in the following, this enhancement is (at 
best) superfluous to me:

---
int myFunc(Args...)(Args args)
   if (Args.length > 2)
{
     assert (args[0] != 0);
     assert (args[1] > 1);
     int result;
     scope (success) assert (result > 0);
}
---

vs DIP Enhancement 3

---
int myFunc(Args...)(Args args)
   if (Args.length > 2)
{
     in assert (args[0] != 0);
     in assert (args[1] > 1);
     out (result) assert (result > 0);
}
---

What *I* need from a DIP that addresses DbC in D (to make it 
viable for me) is to make the simple case as easy as possible to 
read while not introducing language inconsistencies.
With that in mind I am strongly in favor of the syntax H. S. Teoh 
already proposed:

---
int myFunc(Args...)(Args args)
   if (Args.length > 2)
   in (args[0] != 0)
   in (args[1] > 1)
   out (result => result > 0);

int myFunc(Args...)(Args args)
   if (Args.length > 2)
   in (args[0] != 0)
   in (args[1] > 1)
   out (result => result > 0) { ... }
---

- in contracts take a parenthesis delimited bool expression
- out contracts take a parenthesis delimited bool function 
literal.