I am a heavy user of optional braces, and now fewer braces as well.
But I am concerned about readability of code that uses fewer braces with large blocks of code, as there is no end marker that can be used with them.
I’m raising this now as this style of code should become more common as more code adopts boundary/break.
But also testing frameworks like MUnit, which rely on by-name parameters, are affected:
class FooSuite extends munit.FunSuite:
test("this test is very long"):
test("second long test"):
I believe that the syntax should provide an optional way to close these anonymous blocks if you are using the fewer braces style.
the least “ambiguous” syntactically would probably be end do, but do may be surprising as there was no “starting” do, but I’d say end do would then unambiguously mean “anonymous function”. (or perhaps we introduce at the same time an optional do before anonymous functions).
Perhaps the method name could be used (e.g. end locally, end test), but I think this is problematic because up to now this exclusively meant “end the definition foo”, never application of.
@oderskypreviously suggested allowing end on its own, and if the parser can do it then maybe that is best. However this is not backwards compatible because end on its own is treated as a normal identifier.
Also, one would like to freely convert between braced/braceless without loss of clarity.
I would omit the second, extraneous end in your example. The beauty of optional things is in opting out.
I think this need has arisen before, but I can’t find a ticket. There is a ticket for begin syntax, where the question was how to mark the end of a constructor, end <init> (as opposed to the end of the class definition, end C).
For the interaction of end with operator syntax:
I hope to come up with a mnemonic like My Dear Aunt Sally but for end markers.
An end token is optional, but a curly end brace is not. This is significant with the combination of scala-fmt that can add end tokens automatically. So as I write the code, I can use a colon and indent and not worry about closing the brace and having all closing braces align correctly, and scala-fmt can still observe this as valid code and automatically add the end token.
As an outspoken curly braces hater I would switch back to them instantly in case I would encounter code like the above.
End markers are many times worse than curly braces!
At least you can write the curly nonsense like }}}. But you can’t do that with end markers. Also they are highlighted as keywords! That’s infinitely annoying! (The braces nonsense is at least grayed out with most code highlight themes.)
I would not care if there would be some tooling solution against all that curly and end nonsense. But this tooling solution needs to be in place before anything is done which would make thing even worse than the current situation!
It sounds to me like engineering sophisticated rules to provide an alternative option in situations that braces can easily disambiguate today is adding questionable complexity to the language.
As an outsider, a big part of my learning process is to recognize the idiomatic patterns of the language. Adding different flavors of syntax to accomplish the same semantics is impeding that goal because different people like their meals with different spices.
As the title mentions “fewer braces blocks” and not “braceless blocks”, I think one can justifiably wonder whether braces might simply be the right tool for the job. Parentheses are used to disambiguate expressions everyday and most people seem to be fine with that.