On Wednesday, 21 June 2017 at 12:05:55 UTC, Moritz Maxeiner wrote:
On Wednesday, 21 June 2017 at 09:53:40 UTC, meppl wrote:
On Wednesday, 21 June 2017 at 09:27:20 UTC, MysticZach wrote:
On Wednesday, 21 June 2017 at 08:15:34 UTC, MysticZach wrote:
On Wednesday, 21 June 2017 at 04:16:22 UTC, Moritz Maxeiner
Adding `if (...)` should not be different from adding `in
(...)` or `out (...)` in terms of syntax rules: it's
inconsistent. If you want to have that `do` there, I would
argue that it should also become required if only an `if (...)`
is present, so
---
int myFunc(Args...)(Args args)
if (Args.length > 2)
{ ... }
---
should then become illegal and must be rewritten as
---
int myFunc(Args...)(Args args)
if (Args.length > 2)
do { ... }
---
I doubt that's going to happen, though (too much code
breakage), and I also don't like it. Simply drop the `do`.
I tend to agree. I think the grammar for `out` contracts is still
murky, though, because the normal existing case is:
OutStatement:
out ( Identifier ) { OutContractsBody }
out { OutContractsBody }
My fix would be to require two sets of parentheses for the new
conditional, like so:
OutStatement:
...
// new version
out ( Identifier ) ( IfCondition )
out ( ) ( IfCondition )
This makes the grammar unambiguous and clean. And because
normally `out` contracts want to check the return value, the last
case, `out ( ) ( ... )` will be the rare one. If you do
accidentally forget the extra set of parens on the `out`
contract, you would get "Error: `do` expected before function
body after a bracketed `out` contract" at the end of the function.
(If, however, it a happens to be a nested function, and the next
statement in that function happens to be `do`, then the parser
will think the `do` loop is the function body... Mmmm, is this
worth worrying about??)
