Tweaks to indent syntax

[odersky]

• Cleanup syntax.md
• Allow significant indentation after if.
• Allow with in front of templates and make indentation significant after it.
• Allow with in front of type refinements and make indentation significant after it.
• Simplify syntax of given instances for extension methods

[dottybot]

Hello, and thank you for opening this PR! 🎉

All contributors have signed the CLA, thank you! ❤️

Commit Messages

We want to keep history, but for that to actually be useful we have
some rules on how to format our commit messages (relevant xkcd).

Please stick to these guidelines for commit messages:

1. Separate subject from body with a blank line
2. When fixing an issue, start your commit message with Fix #<ISSUE-NBR>:
3. Limit the subject line to 72 characters
4. Capitalize the subject line
5. Do not end the subject line with a period
6. Use the imperative mood in the subject line ("Add" instead of "Added")
7. Wrap the body at 80 characters
8. Use the body to explain what and why vs. how

adapted from https://chris.beams.io/posts/git-commit

Have an awesome day! ☀️

[godenji]

Where did with come from?

Thought that line ending + indent would suffice for object/trait/class/enum definitions. Seems very strange to end every line with with.

[odersky]

See #7136 for a discussion, in particular the last comments.

[liufengyun]

LGTM

Some points for future consideration:

Self syntax

Regarding the self syntax, if we indent them as follows (no indent), it does not look bad, and it's easier to parse what's the self requirement:

trait T with
self: C =>
  ...

The syntax for patmat

Given that we have

  enum Option[+T] with
    case Some(x: T) extends Option[T]
    case None       extends Option[Nothing]

Should we change the syntax of patmat to:

  match opt with
    case Some(x) =>
    case None    =>

This change will also align with the patmat syntax of ML-family of languages.

The syntax for given

Programmers will get confused about whether to use with or not when a list of non-local definitions follows:

  given intOrd: Ord[Int] with
    def (x: Int) compareTo (y: Int) =
      if (x < y) -1 else if (x > y) +1 else 0

  given stringOps: (xs: Seq[String])
    def longestStrings: Seq[String] =
      val maxLength = xs.map(_.length).max
      xs.filter(_.length == maxLength)

[liufengyun]

typo: terated

[liufengyun]

Inspired by this PR, I'm thinking a "more natural" syntax for extension methods. The idea is that templates can be augmented with extension clauses, i.e.:

Extension         ::=  ‘extends‘   ‘(‘ id ‘:‘ Type ‘)‘  ‘{’ DefDef { DefDef } ‘}’
ClassDef          ::=  id ClassConstr [Template] {Extension}
ObjectDef         ::=  id [Template] {Extension}

For example, we can write the following code:

trait Ord[T] extends (x: T) with
  def <(y: T) = x.compareTo(y) < 0
  def >(y: T) = x.compareTo(y) > 0
  def compareTo(y: T): Int
end Ord

given IntOps: Ord[Int] extends (x: Int) with
  def compareTo(y: T): Int = x - y

// a bunch of extension methods
given StringOps extends (a: String) with
  ...

// parameterized given
given AnyOps[T] extends (a: T) with
  ...

// Flags example
object Flags with
  ...
extends (x: FlagSet) with
  def bits: Long = opaques.toBits(x)
  def | (y: FlagSet): FlagSet = ...
end Flags

// or, split the definition into a separate trait
trait FlagSetOps extends (x: Flags.FlagSet) with
  def bits: Long = opaques.toBits(x)
  def | (y: Flags.FlagSet): FlagSet = ...

object Flags extends FlagSetOps with
   ...

Advantage:

1. It justifies the magic implicit resolution rule for extension methods: why an extension method is available when a given instance enclosing the method is present?

2. It clears any doubt about the referent of this inside extension methods. This is a problem for current syntax, as in template-like context, we expect this to be something different from the outer context.

3. There is no need for the problematic infix syntax, e.g.,def (self: String) + (that: String): String.