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
