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