Proposal: Change `@` to `as`

[odersky]

I have a late syntax change proposal: Change @ as the pattern matching binder to as.

Example:

  x match 
    case s as Success(x, in1) => ...
    case f as Failure(_, in1) => ...

  e match
    case (xs as hd :: tl, y) => ...

Why @ is not a good choice for pattern matching:

• It is an obscure symbol with a different meaning. I find the two worst operators to use in programming languages are @ and $ since both have everyday uses that have nothing to do with their role in programming. We have avoided $ so far, let's get rid of @ as well.

• It comes with the wrong precedence. @ binds more weakly than every other infix operator, yet being a non-standard symbol it would suggest that it binds more strongly.

By contrast, as is readable and it comes with the right precedence. It also reinforces learning in relation to givens. In both cases x as would be an optional label.

An objection could be that in patterns, as would be followed by a pattern whereas in givens it's followed by a type. But there's precedence for that: | plays a similar dual role: it connects patterns in patterns and types in types.

Migration

For 3.0, allow both as and @. For 3.1. either deprecate @ or disallow it altogether and offer an automatic rewrite.

[som-snytt]

More precedence for precedence: lampepfl/dotty-feature-requests#120

Changing the symbol instead of the precedence feels quite normal.

Maybe allow case (xs @$ hd :: tl, y) => under -Xbad-@$s.

[sjrd]

TBH I don't like that we are still introducing completely new changes this late in the process. We're already swamped in changes that we cannot keep track of.

Independently of that, this seems to be a very cosmetic change that is not justified by anything else than "it does not look nice; let's use something nicer".

If we really have to change how binding works in pattern matching, I'd like something deeper. I would like a real analogy with |. I would like to express the example as:

  x match 
    case s & Success(x, in1) => ...
    case f & Failure(_, in1) => ...

  e match
    case (xs & hd :: tl, y) => ...

This is very semantic: I want the scrutinee to match both the pattern on the left (which is a capture, so a binding) and (&) the pattern on the right (which is destructuring). The captures/bindings on both sides of & would be visible in the guard and the body.

There would be no restriction on what we can put on the left and on the right. We could actually put a pattern on the left (I have occasionally wanted to match on something that had to satisfy two different patters/extractors). The very concept of a binding would cease to exist. All we would have would be captures. That would actually simplify the language.

[odersky]

@sjrd Rolling this into conjunction is indeed very elegant. But I believe it is also a lot more obscure for the reader who is not familiar with the idiom. For the cases with as it's immediately clear what they mean. For the cases with &, not so much.

[odersky]

Independently of that, this seems to be a very cosmetic change that is not justified by anything else than "it does not look nice; let's use something nicer".

It's more like: I find it awkward teaching this. Can we avoid that? It's not a matter of nicety but of promoting the right intuitions for students.

[julienrf]

I find @sjrd’s suggestion very elegant.

To add to Martin’s introductory post, here is what the proposal would look like in the other situations where we currently use @:

// val someX @ Some(x) = Some(42)
val someX as Some(x) = Some(42)

// for (xs @ hd :: tl <- eventuallyInts) ()
for (xs as hd :: tl <- eventuallyInts) ()

[odersky]

Note that as/@ is actually not completely subsumed by a hypothetical &. For instance, we use this pattern in Flags.scala:

val (_, Captured @ _, NoInits @ _) = newFlags(32, "<captured>", "<noinits>")

This makes an uppercase identifier a bound variable. I believe there's no other way to do this, except for writing separate val definitions.

[LPTK]

It's worth noting that both SML and OCaml use as for pattern binding, which I've always found very nice to read, especially as opposed to Haskell and Scala's cryptic @.

---

There was also the idea of allowing as inside expressions too, where it could play the role of an "inline" val binder, which can be useful when debugging, and in situations like:

val keys = Set(a as newKey("a"), b as newKey("b"), c as newKey("c"))

instead of the verbose:

val a = newKey("a")
val b = newKey("b")
val c = newKey("c")
val keys = Set(a, b, c)

[He-Pin]

Rust is currently using @, I think as is easier for beginners.

[mpilquist]

Would as be a soft keyword and hence still usable in type and term names?

[odersky]

Yes, as can stay a soft keyword. It would be interpreted as a binder only when used as an infix operator in patterns.

[djspiewak]

So I'm a fan of the proposed syntax, just not a fan of making more waves so late in the game. Most usage of Dotty right now is cross compiling with Scala 2, so it's not a huge impact, but I feel like the bar should be pretty high for such changes.

One immediate problem that this creates, for example, is the fact that "as" is actually a commonly used function name across the Cats ecosystem. I believe it's also quite common in a number of other libraries (with varying meaning). All of those would need to be stuffed into backticks during migration (this is a problem that "then" really doesn't have for some reason), and that's more pain on the ecosystem and more pain on users.

(Edit: the soft keyword proposal above resolves this concern)

If I could rewind a decade and make the change you're suggesting, I would be all in favor of it. But at this stage, I feel it's a little too much in a process which is already fraught with variables.

[som-snytt]

Worth noting that pattern alternation doesn't currently parse as infix:

scala> 42 match { case n @ 42 | 17 => n }
1 |42 match { case n @ 42 | 17 => n }
  |                ^^^^^^
  |                Illegal variable n in pattern alternative

Scala 2.12 allows an extractor named $bar:

scala> (42, 17) match { case n @ 42 `|` 17 => n }
val res3: (Int, Int) = (42,17)

[odersky]

@djspiewak One possibility would be to try it out now, and if anything major breaks backtrack. The only thing that would break is if some code uses as as an infix operator in patterns.

[djspiewak]

Lower case "as" can't be used infix in patterns without quoting (I believe) so I think that case is alright.

I'm cool with "try it and see", so long as we watch carefully as we do. 🙂

[odersky]

Lower case "as" can't be used infix in patterns without quoting (I believe) so I think that case is alright.

It can be used, actually:

case class as(x: Int, y: Int)
val x = as(1, 2) match
  case 1 as 2 => ???

But maybe nobody did use it that way.