Consider syntax with significant indentation

[odersky]

I was playing for a while now with ways to make Scala's syntax indentation-based. I always admired the neatness of Python syntax and also found that F# has benefited greatly from its optional indentation-based syntax, so much so that nobody seems to use the original syntax anymore. I had some good conversations with @lihaoyi at Scala Exchange in 2015 about this. At the time, there were some issues with which I was not happy yet, notably how to elide braces of arguments to user-defined functions. I now have a proposal that addresses these issues.

Proposal in a Nutshell

• If certain keywords are followed by an end-of-line and an indented code block, assume
  block structure as if braces were inserted around the indented block. Example:

  def f(x: Int) =
    val y = x * x
    y + 1

  is treated as equivalent to

  def f(x: Int) = {
    val y = x * x
    y + 1
  }

  Or, for match expressions:

  xs match
    case x :: xs1 => ...
    case Nil => ...

  Or, using the new syntax for if-then-else:

  if condition then
    println("taken")
    x
  else
    println("not taken")
    y

  Or for for-expressions:

  for
    x <- xs
    y <- ys
  yield
    f(x, y)

• Use with + indentation as an alternative way to delimit statement sequences in objects and classes. Example:

  object Obj with
    class C(x: Int) with
      def f = x + 3
    def apply(x: Int) = new C(x)

• Also use with + indentation as an alternative way to pass arguments that were formerly in braces to functions. Examples:

  xs.map with x =>
    x + 2
  
  xs.collect with
    case P1 => E1
    case P2 => E2

Motivation

Why use indentation-based syntax?

• Cleaner typography: We are all used to write

  def f() = {
    ...
  }

  But if we look at it with fresh eyes it's really quite weird how the braces embrace nothing but empty space. Geometrically the braces point away from the enclosed space .... One could argue that other brace schemes are better. But there are good reasons why the scheme above is the most popular and in a sense arguments how to make braces look less awkward are themselves an indication that braces are fundamentally problematic. It's much simpler and cleaner to get rid of them:

  def f() =
    ...

• Regain control of vertical white space. Most of us are very particular how to organize horizontal whitespace, with strict rules for indentation and alignment. We are much less demanding on vertical whitespace. With braces, we cannot be, because vertical whitespace is fully determined by the number of closing braces. So two definitions might be separated by a single blank line, or by many (almost) blank lines if there are closing braces. One could avoid this by putting several closing braces on one line, but this looks weird and therefore has not caught on.

• Ease of learning. There are some powerful arguments why indentation based syntax is easier to learn.

• Less prone to errors. Braces are a weak signal, much weaker than indentation. So when
  brace structure and indentation differ, we misunderstand what was written. The code below
  exhibits a common problem:

  if (condition)
    println("something")
    action()

  Indentation fools us to believe that action is executed only if condition is true. But of course that's not the case, because we forgot to add braces.

• Easier to change. A situation like the one above happens particularly often when one adds the first println statement after the fact. To protect against modification problems like this, some people suggest to always write braces even if they only enclose a single statement or expression. But that sort of boilerplatey defensive programming is generally not considered good practice in Scala.

• Better vertical alignment. In the most commonly used brace scheme, an if-then-else reads like this:

  if (cond1) {
    ...
  } else if (cond2) {
    ...
  } else {
    ...
  }

  Instead of nicely aligned keywords, we find weird looking closing braces } at the beginning of the most important lines in this code. We are all used to this, but that does not make it good. I have recently changed my preferred style to:

  if (cond1) {
    ...
  }
  else if (cond2) {
    ...
  }
  else {
    ...
  }

This solves the alignment issue: The if and the elses are now vertically aligned. But it gives up even more control over vertical whitespace.

Impediments

What are the reasons for preferring braces over indentations?

• Provide visual clues where constructs end. With pure indentation based syntax it is sometimes
  hard to tell how many levels of indentation are terminated at some point. In the code below, it is still easy to see that j is on the same nesting level as g. But if there were many more lines between the definitions, it might not be.

  def f =
    def g =
      def h =
        def i = 1
        i
    def j = 2

  The proposal includes with end comments a way to mitigate this issue.

• Susceptibility to off-by-one indentation. It's easy to make a mistake so that indentation is off by a space to the left or the right. Without proper guards, indentation based syntax would interprete misalignment as nesting which can lead to errors that are very hard to diagnose.

  In the proposal, an indented block is always preceded by a keyword that must be followed by a nested expression or statement sequence. So it is impossible to accidentally introduce nesting by veering off to the right. I tried to experiment with the following additional rule, which would
  make it unlikely to accidentally terminate nesting by veering off to the left:

  • When terminating an indented block by a new statement that starts further to the left than the block, it is checked that the new statement aligns exactly with previous statements at the same indentation level.

  That rule proves to be quite constraining (for instance it would outlaw the chained filter and map operations in the example below), so it is currently not implemented.

• Editor support. Editors typically have ways to highlight matching pairs of braces. Without that support, it becomes harder to understand the nesting structure of a program. On the other hand,
  it's also straightforward to provide navigation help for indentation-based syntax, for instance by providing a command to go to the start of the previous or next definition at the indentation level of the cursor. According to @lihaoyi's comment, major editors do something like this already.

But neither of these points are the strongest argument against indentation. The strongest argument is clearly

• Cost of change. It would be expensive in many dimensions to change to indentation based syntax. To be sure, the present proposal for indentation based syntax still allows braces, so existing programs would still compile. But there are other costs as well. If the new indentation syntax is not universally adopted, we incur the cost that there will be two visually distinct ways to structure Scala code. People used to one way will be less comfortable reading the other. If the new indentation syntax does take over as a universal standard (which I would expect), we have rendered outmoded all blogs, books, StackOverflow answers and other technical information that used the old syntax. It will be a long time to change all that, and the transition will be awkward.

Proposal in Detail

Expanded use of with

While we are about to phase out with as a connective for types, we propose to add it in two new roles for definitions and terms. For definitions, we allow with as an optional prefix of (so far brace-enclosed) statement sequences in templates, packages, and enums. For terms, we allow with as another way to express function application. f with { e } is the same as f{e}. This second rule looks redundant at first, but will become important once significant indentation is added. The proposed syntax changes are as described in this diff.

Significant Indentation

In code outside of braces, parentheses or brackets we maintain a stack of indentation levels. At the start of the program, the stack consists of the indentation level zero.

If a line ends in one of the keywords =, if, then, else, match, for, yield, while, do, try, catch, finally or with, and the next token starts in a column greater than the topmost indentation level of the stack, an open brace { is implicitly inserted and the starting column of the token is pushed as new top entry on the stack.

If a line starts in a column smaller than the current topmost indentation level, it is checked that there is an entry in the stack whose indentation level precisely matches the start column. The stack is popped until that entry is at the top and for each popped entry a closing brace } is implicitly inserted. If there is no entry in the stack whose indentation level precisely matches the start column an error is issued.

None of these steps is taken in code that is enclosed in braces, parentheses or brackets.

Lambdas with with

A special convention allows the common layout of lambda arguments without braces, as in:

xs.map with x =>
  ...

The rule is as follows: If a line contains an occurrence of the with keyword, and that same line ends in a => and is followed by an indented block, and neither the with nor the => is enclosed by braces, parentheses or brackets, an open brace { is assumed directly following the with and a matching closing brace is assumed at the end of the indented block.

If there are several occurrences of with on the same line that match the condition above, the last one is chosen as the start of the indented block.

Interpreted End-Comments

If a statement follows a long indented code block, it is sometimes difficult as a writer to ensure that the statement is correctly indented, or as a reader to find out to what indentation level the new statement belongs. Braces help because they show that something ends here, even though they do not say by themselves what. We can improve code understanding by adding comments when a long definition ends, as in the following code:

    def f =
       def g =
          ...
          (long code sequence)
          ...
    // end f

    def h

The proposal is to make comments like this one more useful by checking that the indentation of the // end comment matches the indentation of the structure it refers to. In case of discrepancy, the compiler should issue a warning like:

// end f
~~~~~~
misaligned // end, corresponds to nothing

More precisely, let an "end-comment" be a line comment of the form

// end <id>

where <id> is a consecutive sequence of identifier and/or operator characters and <id> either ends the comment or is followed by a punctuation character ., ;, or ,. If <id> is one of the strings def, val, type, class, object, enum, package, if, match, try, while, do, or for, the compiler checks that the comment is immediately preceded by a syntactic construct described by a keyword matching <id> and starting in the same column as the end comment. If <id> is an identifier or operator name, the compiler checks that the comment is immediately preceded by a definition of that identifier or operator that starts in the same column as the end comment. If a check fails, a warning is issued.

Implementation

The proposal has been implemented in #2488. The implementation is quite similar to the way optional semicolons are supported. The bulk of the implementation can be done in the lexical analyzer, looking only at the current token and line indentation. The rule for "lambdas with with" requires some lookahead in the lexical analyzer to check the status at the end of the current line. The parser needs to be modified in a straightforward way to support the new syntax with the
generalized use of with.

Example

Here's some example code, which has been compiled with the implementation in #2488.

object Test with

  val xs = List(1, 2, 3)

// Plain indentation

  xs.map with
       x => x + 2
    .filter with
       x => x % 2 == 0
    .foldLeft(0) with
       _ + _

// Using lambdas with `with`

  xs.map with x =>
      x + 2
    .filter with x =>
      x % 2 == 0
    .foldLeft(0) with
      _ + _

// for expressions

  for
    x <- List(1, 2, 3)
    y <- List(x + 1)
  yield
    x + y

  for
    x <- List(1, 2, 3)
    y <- List(x + 1)
  do
    println(x + y)


// Try expressions

  try
    val x = 3
    1.0 / x
  catch
    case ex: Exception =>
      0
  finally
    println("done")

// Match expressions

  xs match
    case Nil =>
      println()
      0
    case x :: Nil =>
      1
    case _ => 2

// While and Do

  do
    println("x")
    println("y")
  while
    println("z")
    true

  while
    println("z")
    true
  do
    println("x")
    println("y")

  // end while

// end Test

package p with

  object o with

    class C extends Object
               with Serializable with

      val x = new C with
          def y = 3

      val result =
        if x == x then
          println("yes")
          true
        else
          println("no")
          false

    // end C
  // end o

[smarter]

Audacious :). A few things that come to mind:

• This leave at least one usage where brackets are required: making an anonymous class extending a trait with no additional member

  trait A
  new A {}

• I'm not a fan of the overloaded meaning of with here, even in Dotty it's still used to make anonymous classes with multiple parents, how do you interpret the following code?

  new X with
    Y

  Is this new X(Y) or new X with Y ?

[smarter]

It would also be interesting to compare this proposal with the existing https://github.com/lihaoyi/Scalite

[odersky]

how do you interpret the following code?

new X with
  Y

As new X with {Y}. So you should not write code like that. I believe it's really bad code formatting anyway, you should have written

new X
  with Y

scalafix will be able to help, I am sure.

[smarter]

Taking a step back, what is the with for anyway? What prevents us from being able to write:

xs.map x =>
  x + 2

xs.collect
  case P1 => E1
  case P2 => E2

[lihaoyi]

Woo!

Some thoughts:

Providing visual cues

To be honest, I think that two-space indents is the main culprit for making the given example hard to read:

def f =
  def g =
    def h =
      def i = 1
      i
  def j = 2

Using 3 or 4-space indents, it's much clearer in most fonts:

def f =
    def g =
        def h =
            def i = 1
            i
    def j = 2

That is the reason all my Scalite examples use 3-space or 4-space indents. Two-space indents works if you have curlies but in most fonts is confusing for indentation-delimited blocks.

I've also experienced working on a large Coffeescript codebase (also indentation-delimited) with 2-space indents, and basic block scoping was definitely confusing and easy to misread compared to our 4-space-indented Python codebase.

w.r.t. Editor support, many editors already support indentation-highlighting to some extent, e.g. IntelliJ's {Ctrl,Cmd}-W "Extend selection " and Sublime Text's Shift-Cmd-J "Expand Selection to Indentation". Going to the start/end of a block is then a matter of highlighting it and then pressing left/right, and presumably it wouldn't be hard to add a shortcut if we wanted it to be a single command.

I think with is too verbose a keyword to use for this purpose

Consider the difference between OCaml style

let foo = bar in 
let baz = qux

vs Java-style

int foo = bar; 
int baz = qux

It's only one character, but I think it makes a huge difference. Python uses : which is close to ideal; in Scala we can't because : is reserved for type ascriptions, but I think it's worth looking for something lighter weight than with

I think functions and classes have a nice symmetry we shouldn't break

def foo(i: Int, s: String = "") = {
  def bar() = s * i
  println(bar())
}

class Foo(i: Int, s: String = ""){
  def bar() = s * i
  println(bar())
}

foo(3, "lol")
new Foo(3, "lol")

Both take zero-or-more argument lists, both take a block of statements, both run every statement in the block the block. The main "semantic" difference is that functions return the last statement, whereas classes return the entire scope (ignoring "invisible" differences like bytecode representation, initialization-order limits, etc.)

Given the symmetry, If we're going to allow multiline functions with =

def foo(i: Int, s: String) =
  def bar() = s * i
  println(bar())

I think it makes sense to allow multi-line classes with the same syntax

class Foo(i: Int, s: String) =
  def bar() = s * i
  println(bar())

Notably, this is the syntax that F# has chosen https://fsharpforfunandprofit.com/posts/classes/

Given that multi-line while conditionals and for-generators are allowed, what about if-conditionals

Will this work?

if                                                          if ({
    println("checking...")                                    println("checking...")
    var j = i + 1                                             var j = i + 1
    j < 10                                                    j < 10
do                                                          }) {
    println("small")                                          println("small")
    1                                                         1
else                                                        } else {
    println("big")                                            println("big")
    100                                                       100

I think it should, for symmetry

I think that we should be able to leave out with in lambdas

xs.map x =>
  x + 2

xs.collect
  case P1 => E1
  case P2 => E2

As @smarter mentioned. It might take some hacks (since we don't know it's a lambda until we've already fully tokenized the argument list, and we'll need to go back in time to insert the synthetic curly). Not sure if there's a technical reason it can't be done, but syntactically I think it's unambiguous to a reader, since lambda-argument-lists don't tend to be that long.

[odersky]

@lihaoyi Thanks for your long and constructive comment. Some recations:

To be honest, I think that two-space indents is the main culprit for making the given example hard to read.

You might well be right. The proposal is silent about how many spaces are to be used. It's a separate discussion, but one which is entangled with the current one.

I am against using = for starting a class body because it's semantically wrong. A class is certainly not the same as its body of declarations. Instead, a class definition introduces a new entity which comes with some declarations.

Multi-line if condition: sure, let's add it.

Leave out with in lambdas: What would the grammar be for this? One of the advantages of the current proposal is that it does not need parser hacks. A smarter lexical analyzer is all that's needed. Also, I think it's important to guard against accidental off-by-one indentations turning into significant nesting.

[RichyHBM]

Just to make sure, IF implemented, would this be an optional flag/command passed to the compiler to indicate this is an indentation file, or would it be more like python where you are forced to use indentation?

Whilst python's indentation based syntax is cool in theory, I have found it to be rather annoying in practice. If you use various different text editors/IDEs that may treat spaces/tabs differently it means you can break your code just by opening it up in a new editor.

You might well be right. The proposal is silent about how many spaces are to be used. It's a separate discussion, but one which is entangled with the current one.

I know this isn't the discussion for the amount of spaces, and I don't intend it to be that. But it is a very real issue that many people are passionate about and I feel it would cause lots of issues. The possible alternative would be to just use tabs and allow the users to set them to the amount they prefer, but then you are probably looking at a space vs tabs discussion..

And just to add to this, Scala is a language that is already criticized as complicated for new comers, I feel adding another restriction would just add to this. Currently you can write your code as you like but having weird code issues based on you not having placed indentation in the right place is just another hurdle.

[Jasper-M]

I have to agree the indentation based syntax is pretty nice on the eyes in a trivial example. But keeping in mind the cost of change and the fact that indentation based is not strictly better than curly braces based, I think it's probably better not to add it.

[Sciss]

An exciting proposal. I can follow most arguments. The two things that I don't like is 'lambdas with with' and 'interpreted end-comments'. The first one frankly just looks awkward, so I would be with @lihaoyi here to not use the with keyword in this case. Also, the number of alternative ways of writing a map just explodes:

xs.map(x => ...)
xs.map { x => ... }
xs map { x => ... }
xs.map with x => ...
xs map with x => ... // ?

When I look through the examples, the lambda ones are the ones that stand out as outlandish to me.

The interpreted-end-comments I find very problematic. You are instructing the compiler now to make sense of line comments. I also think this will make life miserable for parser, editor and IDE authors. People can still use curly braces, no? Then we can stick to braces if the block has many lines that make it difficult to see the end. As I understand, there will be already at least a period where both curly braces and indentation are allowed. My guess is, people will use indentation for short (< 10 lines) blocks, and keep braces for longer blocks. Perhaps this mix is actually a good solution in terms of readability. If not, why not use a real keyword end, such as

def f =
   def g =
      ...
      (long code sequence)
      ...
end f

def h

?

As several people have said, using indentation almost certainly means we will have to use at least three spaces to come out clearly and visibly, Perhaps this setting could be a scalacOption with an optional (linter) switch to emit warnings if the code uses other indentation size.

Overall, I think this is great and I hope it will be implemented. People (including myself, I think) have argued against this when Python came along, but people have also gotten used to it, and I think the success of Python and the cleanness of Ocaml/F# clearly speak in favour of reducing the visual clutter.

I'm looking forward to having if then constructs and the possibility to have multi-line conditions in if and
while without the awkward ({ ... }).

[lihaoyi]

Three more notes:

I agree that // end comments look terrible

If we want them to be a part of the syntax, we should introduce syntax for them. Or we could let people use curly-brackets optionally.

I think both cases aren't necessary; in Python people get by just fine without end delimiters, but anything is better than // end comments!

How optional will this syntax be?

Will it be a per-project setting? Per-file? Perhaps even more fine-grained, where you can mix in curlies and indentation-based syntax?

Can we get rid of do-while loops?

This

 do
    println("x")
    println("y")
  while
    println("z")
    true

Is isormorphic to the while-loop

while
    println("x")
    println("y")
    println("z")
    true
do
    ()

In fact, the while-loop version is superior, because the while block in a do-while does not have access to the things in the while block, whereas in the while-do-() case the conditional has everything defined in the while block in scope. This has proven extremely useful to me on many occasions, and given that this new syntax (potentially) makes while-do-() as nice to use as do-while, I think we can really just drop the do-while syntax case entirely

[Sciss]

while
   println("x")
   println("y")
   println("z")
   true
do
   ()

Sorry, but that is horrible. That reminds me of C code where everything is written in the for statement, like for {do some stuff) ;;

[lihaoyi]

We could let the syntax leave out the do

while
   println("x")
   println("y")
   println("z")
   true

Not so bad? At least I think it's not too bad...

[bmjsmith]

This offers no objective improvement to the language at a cost that is not insignificant. More overloaded keywords is the last thing that helps newbies and supporting two styles or switching between them is burdensome. Developers in general will not reach a consensus on indentation vs delimiters any more than they will on tabs vs spaces or which line your curly brackets go on. Please don't facilitate wasting effort debating this (or having to switch) in every project and leave it as it is.

[Jasper-M]

Also, what about the "scalable language" thing, where you can implement your own language constructs?

def until(pred: =>Boolean)(body: =>Unit) = while (!pred) body

And then

var i = 0
until (i == 10) {
  i += 1
  println(i)
}

Does that work as seamless with indentation as well?

Edit: to answer my own question: not in the current proposal. You would have

var i = 0
until (i == 10) with
  i += 1
  println(i)

[optician]

About motivation:

Cleaner typography

With whitespace approach you'll definitely use at least 4-space indent that cuts off available horizontal space. Line breaks would appear more often.

Regain control of vertical white space.

Please could you provide example?

Ease of learning. There are some powerful arguments why indentation based syntax is easier to learn.

Opinion based. My experience with novices and all histories I heard don't have evidences of such problem.

Less prone to errors.

Indentation error is new syntax error for language. So it difficult to say it less prone to errors. Working in REPL also would be harder.

Easier to change.

Agree. But imho one case is not big deal.

Better vertical alignment.

Agree. I use the same style. So problem is absent.

[shawjef3]

There is another impediment: Replacing braces with whitespace breaks the principle of don't-repeat-yourself, which I believe most code authors believe in. Braces are a factoring on lines of code to say they are in a particular scope. Removing braces means that each line defines what scope it is in.

[reverofevil]

Great news.

If certain keywords are followed

Could it be simplified to a much simpler rule: enclose every extra level of tabulation with a pair of curly braces? I've implemented significant whitespace this way in my own similar language, and had no issues with context at all.

Susceptibility to off-by-one indentation

That's easily solved by also enforcing tabs at the beginning of the line. As a side effect, there would be no more need to have an exact count of spaces per tab in style guides.

[odersky]

Wow, this proposal has generated a lot of heat (should have expected that!) I think for now my proposed strategy will be:

• have this or a variant of it as an optional feature in early versions of Dotty, controlled by a command-line flag.

• get automatic reformatters that can switch between braces and indentation.

• experiment with the feature and get feedback from users.

Once the experiments are in, decide on whether we want to keep this.

[ivan-klass]

I like the idea of indent syntax. However, in a big project it can be hard to change all the codebase at once, so I think this compiler option should be controlled per-file. Also we can think of more powerful syntax migration mechanism or convention, for example, like "from future import " in Python.
As for "with" for lamdas, it personally looks kinda awkward to me, but acceptable.

[Blaisorblade]

👍 on some context-sensitive syntax. It might also be a good occasion to try revisiting other issues with Scala syntax...

[...] That rule proves to be quite constraining (for instance it would outlaw the chained filter and map operations in the example below), so it is currently not implemented.

I'm afraid of too much flexibility, based on my experience with layout-sensitive syntax in Haskell.

I can't fully pinpoint the problem there, and I'm sorry this isn't too constructive yet, but I know that indenting Haskell code, and offering editor support for it, is a rather nontrivial matter (I've used some Emacs indentation modes, and I've never been fully happy with any of those—see http://haskell.github.io/haskell-mode/manual/13.16/Indentation.html for a list).

The topic is so tricky that one of these indentation modes deserved a 10-page JFP paper (which I haven't studied), "Dynamic tabbing for automatic indentation with the layout rule", http://www.cs.tufts.edu/~nr/cs257/archive/guy-lapalme/layout.pdf.

TL;DR. I'm happy if we don't drown in flexibility. I could be fine with following a style guide—as long as the rules allow for satisfactory styles.

EDIT: please tag me if you want to reply to me and have me read your answer—gotta unsubscribe from this busy issue.

[EncodePanda]

OH "While we at it, can we add dynamic typing as well?" :)

[ghost]

In this same mindset, we should go one step further and remove lane delimiters from streets. Also stop, yield signs, traffic lights, and create implicit rules that people can follow in their heads. That would make streets look more elegant.

[EncodePanda]

That was a joke, lol.

[obask]

I feel like forcing number of indents is a terrible idea: Haskell and LISP use num of spaces equal to previous line keyword, like:
(do-some-stuff people
_______________user)
Instead of:
(do-some-stuff people
__user)

[jpallas]

I think @lihaoyi's point above about with and : cannot be overemphasized. Python's syntax works in large part because : (at end of line) reliably signals a new block and does so in a visually distinctive way that a keyword cannot. But Python doesn't have the challenge of blocks within an expression. There might simply be no good way to do this for Scala.

[lihaoyi]

Wow, this proposal has generated a lot of heat (should have expected that!)

Surely this is expected. The response is actually milder than I'd expect; imagine submitting a curly-brace PIP to the Python community!

[jpallas]

imagine submitting a curly-brace PIP to the Python community

>>> from __future__ import braces
  File "<stdin>", line 1
SyntaxError: not a chance

[kmizu]

Certainly, the new syntax proposal is great. At the same time, the current style is not so problematic in real Scala world. Such a big change should not be introduced to solve a little problems in my opinions.

[shawjef3]

@keithasaurus My thinking is that a do block without a 'while` would be valid, because such a block in existing code is valid. Example:

class X {
  {
    println("valid")
  }
}

[floating-cat]

Looks no one mention Sass (a stylesheet language). Sass consists of two syntaxes, you can use the indented syntax if you use .sass file extension, brackets style if you use .scss file extension. Sass 3 introduced the latter one which is fully compatible with the syntax of CSS. Because Sass is much simpler to Scala, Sass two visually distinct ways don't have the similar problems mention above like Scala, but maybe we can still learn something from Sass. Though I am not sure whether use two different file extension is a good idea for Scala or we can use both style in the same file.

If you use use IntelliJ IDEA and copy-paste Java code into Kotlin file, and IDE will suggest to convert it. I think we can follow the same way if we adopt this proposal, the IDE or code editor could suggest to convert it to the indented/brackets style if you copy code from StackOverflow or other places. Though the pitfall still exists if you paste you code in the incorrect indented place.

[som-snytt]

Why did Martin use braces in the first place? To keep his pants up, of course.

This is an especially fun thread. I'm grateful to listen in on a vigorous and invigorating debate about a language getting long in the tooth.

Overloading : seems OK, as it is bound to pass _ on StackOverflow for "What are all the uses of colon in Scala?" Besides sequence wildcard, the meaning of trailing colon for operator associativity means you must remember to insert a space because colon is not punctuation. def *: Double.

White space also matters for nl inference. I forget the precise rules, so I take a refresher course on Coursera every year, the one called, nl? np!

So really we have been primed for significant white space. I don't even know why we must still call it white space, as it depends on your color scheme. White space supremacy ought to end with dotty.

Since a space is just an underscore without a score, one might honor a certain project by calling it the underscoreless, and we are concerned here with significant underscorelessness.

[godenji]

Can adapt to either syntax, though staying the course with existing brace based syntax is the path of least resistance (i.e. do nothing). Braces/indentation aside, it would be wonderful if Dotty somehow "fixed" the following syntactic requirements:

if(cond) x else y
if cond then x else y

foo match {
  case x: Bar =>
  case x: Baz =>
}

foo match {
  x: Bar =>
  x: Baz =>
}

If the case keyword were relegated to case class and case object definitions that would be wonderful. Apparently implicit functions will allow the removal of thousands of implicit method annotations from the Dotty compiler; eliminating case from pattern matching blocks would remove perhaps millions of case entries from current Scala code bases in the world.

[AlexGalays]

It has novelty value but this has got to have the lowest priority ever 😈

Never heard of anyone struggling with braces; heard about plenty of people struggling with other things.

[V-Lamp]

If both syntaxes are available at once, then it becomes one more choice on the developer's head: "Should I use braces or not for this expression?". A well iterated point on improving productivity is to minimize the amount of daily choices one makes. Scala has always been on the "more than one way" side, but I feel this takes it to a needless extreme.

If only one syntax is allowed, then there has to be a compiler flag. Within an organisation you can enforce a uniform coding style (and set of flags), but not across the internet. Imagine the horror on StackOverflow: "You need to set this compiler flag to X to run this snippet". What about copy-pasting "legacy" code snippets from SO into a brace-less dotty codebase?

From a language designer perspective, this is a minor parser change, but from a user perspective it is like a new language. As AlexGalays says above, the value of this compared to its risk/cost feels tiny.

As with every major language version, the risk of split on major versions is very real (Python...). It would be great for Scala to focus instead on minimizing that overhead across use cases and even after the first wave of adoption (and I know there is active work on this with Scala meta but this does not cover all use cases) and ensure a smooth and rather uniform transition. A thriving Scala is in our common interest 😃

[koeninger]

I've seen significant whitespace in python lead to errors that permanently destroyed end user data.

If you're changing anything about blocks, it should be to require braces even for one liners. It's safer.

[LPTK]

@DarkDimius

My biggest concern is copy-paste friendliness.

If braces are allowed to be used within indent-based code, copy-pasting should not be an issue.
For example, say you want to copy this snippet of code:

    // sample code to copy-paste
    ls.map with
        _ + 1

The trick for copy-pasting code while conserving relative indentation is to always include the linebreak above the code snippet before pressing Ctrl-C, so that what you select would be:

    // sample code to copy-paste[   <- selection starts here
    ls.map with
        _ + 1]   <- selection ends here

Now, say you want to paste the code in the following program:

class A with
    if x > 0 then
        println(123)
        // want to insert code on the following line:
        

You only need to press { (modern editors will insert the closing } automatically)...

class A with
    if x > 0 then
        println(123)
        // want to insert code on the following line:
        {}

And then press Ctrl+V, which would result in valid code:

class A with
    if x > 0 then
        println(123)
        // want to insert code on the following line:
        {
    ls.map with
        _ + 1}

The IDE would then have no trouble reformatting this code using the preferred whitespace style, if desired. (Or you can easily do it manually later.)

class A with
    if x > 0 then
        println(123)
        // want to insert code on the following line:
        ls.map with
            _ + 1

[DarkDimius]

@LPTK, what I'm saying is not that "with proper tooling and by carefully copying proper parts of code it will work", but that you'll have substantially more errors if some-thing doesn't work out. All tools have to agree on how you copy code and how you paste it. All users should also be careful to copy code correctly by following some "tricks", as you called it. I don't think we should add more "tricks" that people should learn.

[alejandrolujan]

I feel strongly against this for three main reasons:

1. As stated above by others, copy-pasting would very likely be affected by this (until/if IDEs catch up, who knows how long) which is a huge deal IMO.
2. I get many complaints from newcomers about the underscore, in the lines of "why does it mean 10 different things depending on context?". Introducing more overloaded terms will negatively impact learning curve IMO.
3. I regularly use my IDEs capacity to highlight the block of code surrounded by a pair of curly braces. How long until they catch up to meaningful whitespace and provide similar functionality?

But, fundamentally, I agree with others on the argument that this is not currently a problem at all.

[lostmsu]

@alejandrolujan Number 3 seems to be rather artificial. While it's bad IDEs will have to catch up, they will have to catch up with any syntax change. That should never stop one from happening to begin with.

[adamw]

Leaving aside considerations if this would work fine or not, I think that Scala already has too many syntactic options, which might be confusing even for somebody working with Scala for a longer time. Adding more would only add to the confusion, probably with little benefit.

[ryantheleach]

@lostmsu It's relevant because we are removing 'excess?' information.

Think of the verbosity of Java, that enables IDE's to have sufficient side channel information to correct a whole ton of newbie errors with the syntax, that just won't fly in Scala due to the meaning being far more ambiguous due to the amount of overloaded / optional keywords / different arrangements of keywords, and ultimately more efficient compression of information.

Anything that potentially harms IDE's from correcting and aiding newbies to the language should be avoided.

[realzeus]

The advantage of braces is that they provide fully deterministic syntax.

if (condition)
  println("something")
  action()

Currently it will be always with full determinism reformatted to

if (condition)
  println("something")
action()

• Think about mixes of Space (0x20) and Tab (0x09) characters for indentation
• think that editors allow to define the width of Tab (sometimes 8, sometimes 4, and sometime 2 spaces)
• thing that some editors are configured to automatically replace tabs with spaces while others replace spaces with tabs and everyone has own understanding of tab width
• think about automatic merging in different version control systems

Consider increase of efforts needed to detect and fix these errors.

I have worked with Python enough to say that these errors are very hard to find - every time you have to understand the entire block to check if indentation is correct. It's much more complicated than "missing brace".

[Atry]

I like the with lambda syntax.

@odersky Is it possible to loose the requirement of indentation? It would be very useful for asynchronous programming, for example:

def readFromDatabase(key: String): Future[String] = ???
def shutdownDatabase(): Future[Unit] = ???
def doSomethingWithJava(platformConfiguration: String): Future[Result] = ???
def doSomethingWithDotty(platformConfiguration: String): Future[Result] = ???

readFromDatabase("language").flatMap with language =>
readFromDatabase("version").flatMap with version =>
(
  if (language == "Scala" && version == "3.0") {
    readFromDatabase("dotty").map with dottyConfiguration =>
    doSomethingWithDotty(dottyConfiguration)
  } else {
    readFromDatabase("java").map with javaConfiguration =>
    doSomethingWithJava(javaConfiguration)
  }
).flatMap with result =>
shutdownDatabase().map with case () =>
result

The with lambda syntax can be used as a replacement of async/await

[realzeus]

Concerning vertical and horizontal alignment: Scala, Java or Python do not depend on horizontal spacing.

val a=1+2*3
val b = 1 + 2*3
val c = 1 + 2 * 3

are all the same. So, we are free to use spaces for emphasizing some code to other readers, not compiler. And compiler's behavior is always deterministic.

We have the same freedom with braces:

• put every closing brace on a separate line
• put all closing braces on a single separate line
• put all closing braces in the end of last meaningful line

With significant indentation it will be prescribed when to put a new line.
It will make map and filter chaining more verbose.

[LannyRipple]

I wouldn't mind this at all if I could mix and match. For small things I think it would be an improvement but I'd want to be able to fall back to {} where I needed to or desired. I think the proposal for "Significant Indentation" should be changed from

an opening/closing {/} will be implicitly inserted

to

an opening/closing {/} will be implicitly inserted unless found as the next token (which, for an opening brace, will turn off Significant Spacing until it is invoked again)

Mandatory significant spacing makes a program brittle. Without significant spacing I can make the computer work for me to format the program as I like. With significant spacing I have to hand-hold the computer to reach a correct program. (Computers should work for humans and not the other way around.)

[ctoomey]

I'd be in favor of this for a clean-sheet language, but as others have said, at this point it's only going to make things more confusing for newcomers and introduce more disparity between different developers' and teams' code.

Instead of this, I'd rather see a standard formatting along with a tool to enforce it ala gofmt. Having all Scala code formatted the same would be a lot more beneficial than adding one more way to make it different IMO.

[felixmulder]

Thank you all for your feedback. Both me and the rest of the Dotty team have been delighted to see the spirited, and civilized debate on this issue.

One of the key goals of Dotty is simplification, and this of course extends to the syntax of the Scala language itself. The implementation of the proposal as-is, is incredibly straight forward in the parser and scanner but does not require more alterations to other parts of the compiler pipeline - as demonstrated in #2488.

That being said: the proposal as it is now, adds a bit too much leniency to the syntax of Scala.
The language might be better served evolved at a slower pace in a more principled manner.

We're very happy with the different suggestions in this thread and will perhaps draw on them as inspiration in the future. For now - I'm closing this issue as we will not be moving forward with this suggestion as is (also: our inboxes are overflowing).

If this feature, or any other is something that you feel should be further discussed, please open a thread on https://contributors.scala-lang.org/

Cheers,
Felix & @lampepfl/dotty-team

[tr00per]

Just make Scala look like Haskell: https://www.haskell.org/onlinereport/haskell2010/haskellch10.html#x17-17500010 ;)
But seriously, Layout is cool, IMHO works better than what Python offers.

[SRGOM]

I don't use IDEs, I use vim and I like being able to close my eyes and hit ggVG=. Literally the only reason I avoid python is indentation-defined-blocks. It gets really hard to stay confident.

[SRGOM]

@felixmulder & @odersky Thank you guys for being so open about suggestions and welcoming and accepting negative feedback.

To be clear, while some remarks from people may have been dismissive and off-the-cuff, all of us have huge respect for the scala team and of course, Martin.

[reverofevil]

@felixmulder That was the most epic trolling in the PL community I've ever seen: introduce long awaited feature and discard it on the same week. Made me a good chuckle. Thanks!

[harald-gegenfurtner]

Let me just repeat this one statement:

Indentation does not scale well.

[guizmaii]

What I love with Scala, it's the confidence I have in the code. This proposal could lower the confidence I could have in my code. So, IMHO, it's not a good path to follow for a language that sell himself as "safe".

[felixmulder]

I think it's time to lock this now - thanks for the discussion guys! As aforementioned: http://contributors.scala-lang.org for more discussions ❤️