DIP 1009 (Add Expression-Based Contract Syntax) Accepted
H. S. Teoh
hsteoh at quickfur.ath.cx
Wed Apr 11 14:55:45 UTC 2018
On Wed, Apr 11, 2018 at 05:23:58AM +0000, really? via Digitalmars-d-announce wrote:
> On Friday, 6 April 2018 at 17:36:20 UTC, H. S. Teoh wrote:
> >
> > Yeah, I think having expression syntax will make contracts more
> > readable. We'll just have to see.
> >
>
> Sorry, but I fail to see how (1) is more readable than (2)
>
> (1)
> in(s.length > 0, "s must not be empty")
>
> (2)
> in { assert(s.length > 0, "s must not be empty"); }
>
>
> In (1) The assert .. is removed.
> In (1) The scope indicators {} .. are removed.
> In (1) The semicolon..is removed.
>
> Removing all these things equates to being more readable??
>
> Sure, it makes it more concise, but more readable??
Yes, because it removes unnecessary syntactical noise from the line. All
of that verbose baggage -- braces, "assert", semicolons, is just
needless syntactic boilerplate that's repeated verbatim every single
time you write a contract, and all for what? Just to express a contract
consisting of a single, simple expression.
Besides, the `keyword(expression)` syntax has precedence in signature
constraints:
auto myFunc(Args)(Args...)
if (Args.length == 2) // <---
...
So now to add a contract:
auto myFunc(Args)(Args...)
if (Args.length == 2)
in (Args[0] < 100) // consistent with sig constraint syntax
...
> I assert that it does not. But now..do I use the assert keyword.. or
> not? Do I end with semicolon..or not??
>
> This just removes things that are still needed elsewhere in your code,
> but now... you have to remember that sometimes you need those things,
> and sometimes you don't.
[...]
It's no different from needing to "remember" that the condition of an
if-statement does not require {} and semicolons. According to your
logic, for consistency's sake we should start writing if-statements like
this instead:
if {
assert(myCondition == true);
assert(myOtherCondition == false);
} then {
...
}
I wouldn't say it's less readable, but again, needless boilerplate. If
you love so much boilerplate, perhaps Java may be a better language for
you.
T
--
Lottery: tax on the stupid. -- Slashdotter
More information about the Digitalmars-d-announce
mailing list