DIP 1003 Formal Review

[H. S. Teoh via Digitalmars-d]

On Tue, May 16, 2017 at 09:48:07PM +0200, Timon Gehr via Digitalmars-d wrote:
[...]
> I'm saying no to this:
> 
> ...
> {
> 
> }{
> 
> }

It doesn't have to be formatted that way. For example:

	int foo()
	in { assert(blah); }
	{
		// not so bad after all
	}


[...]
> > 	int foo(T, U)(T t, U u)
> > 	if (sigConstraints!T && sigConstraints!U)
> > 	in (t > 0 && u < 10)
> > 	out(foo > 1 && foo < 5 )
> > 	{
> > 		// function body here
> > 	}
> > 
> > This is just tentative example syntax, of course.  We can argue over
> > its fine points later, but the point is that the current syntax is
> > far too verbose, and can easily be reduced to half the number of
> > lines.  Merely changing `body` to `do` does nothing to address this,
> > and seems to me to be just more useless churn, replacing one bit of
> > verbosity with another bit of verbosity.
> 
> It's a good option to have, but D is not an expression-based language,
> so this can be painful, as you cannot declare intermediate variables
> nor use statements.

Yes, I'm aware that one of the reasons for the current syntax was the
desire to allow arbitrary code inside contracts.  In practice, though, I
hardly ever encounter a use case that needed this, and even where it was
needed, the code was much better off being in a separate function so
that you could write, for example:

	bool elementsWithinRange(T)(T[] data, T lower, T upper) {
		foreach (e; data) {
			if (e < lower || e >= upper) return false;
		}
		return true;
	}

	int foo(T)(T[] data)
	in { assert(data.elementsWithinRange(0, 10); }
	body // ugh
	{
		...
	}

In the hypothetical new syntax, you could get rid of the assert
altogether for a much more concise expression of the in-contract.

IMO, if your contracts have become complex enough to require variables
and statements, then it's time to refactor them into properly-named
functions so that the person reading the code doesn't have to mentally
parse and execute the contract just to understand what requirements it's
trying to express.  D not being an expression-based language is not a
problem since contracts can call arbitrary functions. (In fact, I'd
argue it's an advantage, since it would require users to refactor their
contracts once it starts getting out-of-hand. The result should be
better readability.)


> > (Not to mention the IMO very ugly syntax clash with
> > do-loops, which will reduce code readability even more.)
> > ...
> 
> Do you think your new syntax is significantly more readable? (Just
> curious.)

It at least gets rid of the verbosity of the current syntax.  I don't
claim it's necessarily *significantly* more readable, but I'd consider
it to be one step closer.  Getting all the way there would be another
topic, and a very long, protracted one, given our track record.


T

-- 
"No, John.  I want formats that are actually useful, rather than over-featured megaliths that address all questions by piling on ridiculous internal links in forms which are hideously over-complex." -- Simon St. Laurent on xml-dev