Feedback sought: Optional Braces

[mbloms]

I feel far less religiously for this than other people. As I’ve already said in the other thread, optional braces makes sense for a lot of reason, one of which is productivity.

I’ve been embracing the brace-free syntax for about a year now (though I haven’t been coding Scala 3 constantly during that time). While some tooling has sometimes been awkward with the new syntax, I don’t think that’s an issue in the long term.

For exclusively writing code, the new syntax doesn’t bother me at all.

My concern is mostly that I find the current syntax hard to read. The : sort of floats around on the screen for me. I imagine this would suck really bad for someone with dyslexia. I’m also really wondering what the new syntax would mean for blind programmers.

I don’t think it’s serious to close the door on optional braces, but I really don’t see why this is something which must be done now. Shipping Scala 3 with optional braces on by default means it can never be rolled back or changed if it’s discovered to be sub optimal for any reason. The significance of this change should not be underestimated!

This is why I think the best solution by far would be to make it an experimental feature in 3.0 and make it official when it’s matured more.

I tried to expand on this reasoning in the angry sister of this thread:

@mbloms

If I may, I would like to try my best to make a constructive argument in favor of making optional braces an experimental feature in Scala 3.0:

Some members of the community obviously have reservations against optional braces, even if they can still be used. As I’ve heard Martin say in presentations: “Scala 3 is when the books will have to be rewritten.” Because of this, features need to get into the language now if they change foundations in such a way that books become outdated when they are added.

Optional braces is by definition not a breaking change. In my humble opinion, what’s important do get into the new books is semantics and things like how givens work. None of this would actually become irrelevant or outdated if and when braces become optional in the language. It would be a quite minor thing to introduce them in a reissue. Books written with brace-syntax would not become outdated and irrelevant just because optional braces is added in 3.0.4 and it says on the internet “Braces are optional now.”

I would go as far as arguing that if the brace-less syntax is really so confusing for people that they merit throwing out all books and documentation, then that in and of itself a huge argument against introducing it.

For this reason, I humbly suggest that optional braces is made an experimental, opt-in feature just like -Yindent-colons . Then the focus can be on the really interesting changes in 3.0, community can try optional braces at their own pace, if there are issues with the new syntax they can be sorted out, and if they are met with enthusiasm from most people, add them then.

Other reservations about the syntax: (click to expand)

@odersky

Spaces vs tabs: solved by a new interpretation of indentation widths. Spaces and tabs can be mixed, and at the same time the system still does not require an encoding of what a tab is.

This seems like a half measure to me. Other languages that’s made this change prints warnings when tab characters are found, for good reason.

@odersky

It’s hard to find what scope gets closed when a line closes multiple indentation levels: Solved by optional end markers.

end markers solve part of the issue but they are not perfect:

@mbloms

When I’ve read the Dotty code base, it’s been extremely useful to be able to easily find the beginning and end of a definition using Ctrl+M in Sublime Text.

end markers only solve part of the problem. It tells me what definition just ended, but that doesn’t really help me if I find myself in the middle of a definition and I want to find the beginning. I welcome an example of where it would be useful, but my spontaneous reaction is that it just adds noise where a } would’ve been clearer. It also makes me think of languages with begin … end block syntax, which I personally think is very hard to read. The end marker is also not unambiguous, as shown by this example:

class C:
  //Ridiculous amount of code
end C

object C:
  //Ridiculous amount of code
end C

If i now read end C , how can I know if I’m looking at the class C or it’s companion object?