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