DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins

[Moritz Maxeiner via Digitalmars-d]

On Saturday, 22 July 2017 at 03:05:55 UTC, aberba wrote:
>
> How about this in current syntax? (that's what I do)
>
> int func(int a)
>     in
>     {
>         assert(a >= 0);
>     }
>     out(result)
>     {
>         assert(result >= 2);
>     }
> body
> {
>     return 2 * a;
> }

I can only restate my opinion against the above as "too verbose" 
for the common use case of simple conditions such as null 
pointer, range empty, etc. Until in contracts are injected at the 
call site, the above is essentially equivalent to this less 
verbose version:
---
int func(int a)
{
     assert (a >= 0); // > should be used here, though

     int result;
     scope (success) assert (result >= 2);

     return result = 2*a;
}
---

> an improvement could be:
>
> int func(int a)
>     in assert(a >= 0);
>     out(result) assert(result >= 2);
> body
> {
>     return 2 * a;
> }
>
> just like an in-line if-else statement

Summary of issues with that (that you can also find in the Round 
1 discussion):
- Free semicolons within the function signature are inconsistent 
with the rest of D
- The `body` keyword is redundant here; imho it should also have 
been removed (deprecation first) from the current contract syntax 
instead of being replaced by `do`, because it's inconsistent with 
the rest of D to require a keyword to delimit the *end* of an 
optional element, but since those (shell) contracts are extremely 
verbose, anyway, it doesn't matter much
- There already is the verbose syntax to specify contracts as 
"shells" that are to be explicitly filled with whatever checks 
one needs (assert, enforce, etc.), i.e. requiring the user to 
couple a contract with its implementation; the new syntax allows 
the user to specify contracts as what they originally are (in the 
DbC context): abstract promises between caller and callee with 
the user not needing to worry about the implementation.
- Imho the reason why current contract syntax is used only by few 
people is its verbosity; the more succinct the new syntax, the 
higher chance I think it has of yielding more widespread use