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
