SI-8044 Allow binding backquoted varid in patterns

[som-snytt]

Previously, a varid could not be backquoted, so that it was not
possible to introduce variables with names such as type in a
match expression.

This commit allows backquoted varids in case x @ _ and
case x: Int. In neither position is a stable id accepted,
that is, an id with leading uppercase.

Therefore, this commit merely relaxes the backquoted varid to
be taken as a normal varid in these contexts.

[lrytz]

I'm a little bit worried about this adding another rule for people to remember.
Somebody learning Scala:

• Ah, nice feature, back-quoted identifiers for things like type or something with spaces
• Ah, pattern matching has this funny rule: lower case binds, upper case matches
• Ah, I can match on a lower-case using backticks, so backticks have a different meaning here
• Ah, in syntactic positions in a pattern where an identifier can only introduce a binding, backticks are back to the other behavior

[retronym]

The argument for the defence is that it is nice to have a quoting mechanism that works in all cases is nice if you're writing a code generator that targets pattern syntax. (IIRC that was the motivating use case behind the bug report.)

That said, I'm do find the prosecution's arguments persuasive. Reasonable doubt goes the way of the status quo.

@som-snytt WDYT, a dozen days later?

[som-snytt]

The defense would highlight on cross-examination that people who are liable to be confused are already confused on day one by case X =>, witness this SO exchange.

Since that is the only context that suffers from weird rules, after they learn about backquoting the varid case x => on day two, they can get their pattern matching certificate and go home happy.

Backquotes have no other special powers, unless you adopt my idea that backquoted underscore introduce a fresh name.

If regularity is a virtue, then why not allow case X @ _? This compromise means varids are still required for binding, so this is less controversial.

Most importantly, it makes possible what is otherwise impossible (and also reasonable). My use case was varids like type and class which are especially common. This will be no argument to anyone who uses spellings such as "tpe" and "defence."

[adriaanm]

We've discussed this during our biweekly world domination meeting, and we find for the case for more backticks. So, we're in favor of your PR, buuuuuut:

• {case X@p => X} should also be accepted -- is this already the case with this PR?
• upstream tooling should be notified -- ideally, file an issue to cross-link between scalariform's tracker, intellij, and anything you could think of. We'll make sure to highlight in release notes.
• we'd also like to make sure @odersky is on board with this.

[som-snytt]

Currently it accepts only backquoted varids, only because "varid" is a thing. If anything goes, then I think @retronym 's original suggestion to allow binding X without quotes is valid, and if that's true, can I also bind operators like star, with or without backticks?

I might have just persuaded myself that anything goes.

case Seq(* @ _*) => *
case `X`: Int => X
case C(`X`) => X
case C(`X`: Int) => X

I just ran out of clever things to say. I can imagine the SO questions. I'll go code up the Abide rule for "no backticks in type pattern."

Also, don't tell Dad.

[lrytz]

{case X@p => X} should also be accepted -- is this already the case with this PR?

@adriaanm what I meant (@som-snytt points out that Jason mentions it on the ticket): for full regularity 1 match { case X @ 1 => X } should be allowed. And also *.

[som-snytt]

I'll add an improvement commit for that soon, and see how it looks.

[som-snytt]

Added case * @ _ and case X @ _. Rebased.

[som-snytt]

This PR also partially addresses "how do I define multiple vars with non-varid names?"

http://stackoverflow.com/a/12815725/1296806

scala> val (A @ _, B @ _) = (1,2)
A: Int = 1
B: Int = 2

It's not super-great. The fellow on SO had the intuition that backquotes should invert the test for varid:

scala> val (`A`, `B`) = (1,2)

So that didn't error b/c I just defined A and B; it's a no-op match here. But suppose it introduced A and B because of the backquotes.

[som-snytt]

Rebased just because it caught my attention. Boy, it sure would be nice if it didn't catch my attention again.

[som-snytt]

Rebased and added test for

case List(1, `Rest of them` @ _*) => `Rest of them`

That is actually the most common use case for @ syntax in match, as it doesn't have an alternate syntax.

I hope @adriaanm is not on vacation. I guess he accrues both US and Euro vacadays.

[som-snytt]

Timeout on docs.comp.

[adriaanm]

/rebuild

oh, ci!

[adriaanm]

LGTM