Consider removing single-line expression blocks, requiring braces

[FascinatedBox]

Lily currently has two kinds of block types: Single-expression blocks, and multi-expression blocks. The difference is that the latter has curly braces around the body of the block.

One part of Lily's syntax that I really enjoy is that a single set of curly braces works for a whole block. It eliminates needing to put braces along every branch, and there's no ambiguity in it for the parser.

Well, mostly.

One problem I've had with Lily's syntax for a long time is the 'dangling else question'. It goes roughly like this:

if x:
    if y:
        do thing
    else:
        do other thing

A user might intend for the 'else' to be for the if y: case, or maybe they want it against the if x: case. Currently, Lily assumes the former. But the user may expect a different behavior. No matter how Lily handles it, it's possible for the user to have indentation that's misleading.

I've been burned by this on more than one occasion when writing scripts for the language. I don't want to take an approach of counting whitespace to hint the user since that seems unlike the rest of the language.

What I'm thinking of is to remove the option of single-line blocks entirely. It'll mean there's more weight (an empty brace pair) when writing simple if blocks. However, there are a number of gains:

The dangling else is solved, because braces are mandatory and denote the end.

It simplifies the language, removing the question of "use braces or not for single-line conditions?". This is similar to how the language forbids using self.<property> in place of @<property> to enforce consistency.

Debugging no longer involves having to add braces around a single-expression construct to add debugging, then needing to remember them later.

I'm leaning pretty strongly in favor of doing this. I tried to have these kinds of syntax issues done away with in the run up to 1.0, but never considered this until recently.

I'll save this issue as one to be solved in part of the next release. It's unfortunately going to break what code that's out there, but I don't see any other changes of this magnitude happening.

[Steve J Donovan]

I would agree with this. It feels convenient but bites hard.

[FascinatedBox]

Almost done. Since there's no mechanism for reporting non-fatal errors, the lack of a brace will now be a syntax error. That seems better than hotfixing in such a mechanism for just this case.