Yes, we want Scala to be both a widely taught language and a widely used language. Java’s success was to a large extent based on that it, for a long period, has dominated as teaching language at universities around the world, providing an increasing number of developers who know the language…
I believe it is indeed possible to balance the language design so that it fits both teaching and practice.
It might be difficult to get those who stick to “old” braceful style to abandon 2 space indent, and I guess we will have braceful and braceless styles mixed, even in the same file, for a long time.
And perhaps editors will not very soon support “brace-sensitive indent size” where 3 spaces are inserted in braceless indent and 2 spaces are inserted in braceful indent in the same file…
Perhaps this will be the toughest challenge if trying to standardize on 3 spaces in braceless code? The mixed brace style code, I mean.
I agree. Even though I am (mostly) in favor of the braceless style, I am not sure yet whether it is gonna fly within the company where I work. The more changes there are, the less likely I expect it wil be accepted.
On a more personal note, I find 4 spaces way too much. Scala generally takes up more horizontal space than Python and if you use line length limiter you burn through this quite quick.
Leaving aside for a moment which indentation width is best, I think the challenge of changing from e.g. 2 to 3 spaces is exaggerated.
I might be wrong, but I think what will probably happen is that people will start writing new code, and in particular new source files without braces, rather than going around and changing old code. Having editors indent 3 spaces by default in new source files wouldn’t be too hard. For existing code, I think most IDE’s infer the indentation based on what’s in the current file.
Everyone won’t follow that standard anyway. When I was new to Scala, I always indented 4 spaces, because that’s what I did in all other languages, and I mostly used sublime, which indented 4 spaces by default. There are other examples:
Changing the standard would be a incremental process, and not everyone would follow it. That doesn’t really make it undoable.
Yes, perhaps you’re right that it might work to change from 2 to 3 indent spaces gradually and eventually with focus on new code.
Perhaps an official Scala 3 poll on 2|3|4 indent in braceless code sent out to the community based on Martins nice example code above?
I agree - indent size 3 is optimal; 2 is “ok” but sometimes a strain on the eyes without braces, 4 is too wide.
Anecdotally, when I moved from Java to Scala, I started out with 3 spaces because going from 4 to 2 was too hard for me to read. Two years or so later, I started reformatting all my code from 3 spaces to 2 spaces instead.
During my – admittedly limited – experiments with Dotty I’ve come to very much appreciate the quiet/indentation syntax.
One thing I’ve been having issues with with is the already mentioned inconsistencies with regards line endings / new blocks. (This is of course not an issue for the braces-syntax.)
I find myself again and again having to thing about what construct requires what line ending. I would favor a more regular solution even at the cost of added verbosity.
It seems like a big step backwards to have to resort to a macro to get what’s currently pretty basic functionality 
I don’t agree. IMO the basic functionality should work like this:
task(
val x = ...
val y = ...
f(x, y)
)
That indented code after an operator is parsed as a block is a bonus.
Plus historically it has often been the case that user-code solutions were preferred over adding special constructs to the language (such as in this case passing arguments between braces instead of parentheses).
I’m not talking about what I think it should look like, I’m talking about how it currently works. Right now, in Scala 2, the language makes it easier to to build a DSL, not harder. You don’t have to resort to a macro to create something that looks like it is part of the language, because braces are treated as a block.
Removing this feature adds a non-trivial barrier to writing that first embedded DSL, which would be an unfortunate step backwards.
These for me are very strong arguments for with. Why wouldn’t you want a language to become more regular and easier to explain, especially with focus on teaching?
Inside braces, 2 spaces feels fine
Outside, 4 spaces is roomy and spacious
What to do with whom and where?
8 spaces says Go
Aaargh No!
Split the difference between 2 and 4 as 3
Or maybe 0 to 8, the spaces union
For a more perfect Scala fusion
Actually I agree on this point but by now brace-optional syntax is a fact of life, so I guess we should make the best of it. And IMO all other suggestions to start a block are not good in general, and most would be terrible for DSLs.
This one might make the simpler DSLs a bit harder to implement (but still, you don’t need a macro) but at least it makes it possible to implement interesting DSLs.
Fair enough, just getting flashbacks to having to manually create Java Builders to work around the lack of named parameters.
I get that harm mitigation is a reasonable thing1. I’m also concerned that the way it is currently manifesting is “how we can adjust the rest of the language to accommodate this,” rather than, “how can we mitigate risk by isolating this until we know more.”
I’m worried this whole mess is well on it’s way to snowballing from “hey, what do you think of this experiment,” to frantic patches touching every other aspect of the language, in ways that are going to make my life much less pleasant.
1 From what I can tell, we’re very much in “lipstick on a pig” territory 
Honestly none of you “weird” examples look bad to me. I don’t think I would find them confusing and/or unreadable. Sadly there is just too much subjectiveness in this topic. What “feels right” for some might be terrible for others and vice versa.
Mind you, the syntax used was this:
[details=(Minimized to make people hate me less)]
...
[/details]
Which is different than the gist you posted.
So I just ran @bjornregnell’s survey in my company’s engineering team, with the same samples and prompts. These folks are basically the complete opposite of @bjornregnell’s students:
Current set of responses is:
| Prompt | Votes |
|---|---|
| Optional braces but add keyword with | 1 |
| Optional braces but add delimiter colon | 17 |
| Optional braces, nothing extra | 4 |
| “Why can’t they just stick to the old way” | 19 |
(The last prompt was not asked, but came up organically and was voted up)
A lot of the concern around this effort is around the migration cost: migrating our backend systems (currently on 2.12), migrating Apache Spark (which we just got onto 2.12), which is what you would expect in an environment with a lot of stuff we maintain.
But assuming the last option isn’t on the table right now due to @odersky’s BDFL card, Optional braces but add delimited colon is currently the winner by an overwhelming margin.
Was it possible to vote for more than one option?
Will it not be confusing that only givens are written with with but other stuff with a colon?
Surveys based on an extremely small syntax sample are fine, but don’t tell the full story. We’d need to see the opinions of people who have actually used the syntax for a while. But if everyone persists in preferring colons, then I’ll accept it as the clear winner!