Imported From: https://issues.scala-lang.org/browse/SI-6524?orig=1
Reporter: @Sciss

@hubertp said:
Duplicate of #4425 and #3353.

@Sciss said:
I don't see this as a duplicate; those are bugs which deal with default arguments for implicit parameters in the unapply method; i.e. with arguments supplied to the pattern matcher, not the results from the pattern matcher. Anyway, my main case is named arguments which is unrelated to those issues.

@hubertp said (edited on Oct 15, 2012 5:24:18 PM UTC):
Well, from the title of the bug that looks like 'named and default arguments'. And fixing those bugs means defining the correct behaviour for the things your want. So, they are definitely related (and I would say sort of duplicates).

See for example Lukas' comment on #3353:
"There's a whole space to explore on the interaction of named/default arguments and pattern matching. If we start doing this, we will end up with this kind of blocks during pattern matching (and btw, blocks don't need to have symbols)."

I didn't close this bug because you kind of rely on the bugs I mentioned. And I guess if we want to be formal SIP would be the proper way.

@Sciss said (edited on Oct 15, 2012 5:38:14 PM UTC):
Of course it is loosely related, because this issue (which is not a bug but a feature request!) and the two bugs linked both involve default arguments. But this:

    object Foo {
      object X { def unapply(x : Int)(y: Int) = Some((2,2)) }
      42 match { case _ X _ => () }
    }

has nothing to do with allowing named and default arguments in pattern match cases, unless I am missing something, and I'm trying hard to think of how they would be related, or how this feature request relies on those bugs? In the other example

    object X { def unapply(x : Int)(y : Option[Int] = None) = None }

the point seems to be allowing to match using an unapply method which has multiple parameter lists (explicit or implicit) for which defaults exists. How would fixing those bugs produce correct/desired behaviour in this case?

@hubertp said:
The first example has nothing to do with it, agreed. Still, the interaction between named and default arguments in pattern matching which is decided here will influence how the bugs I mentioned should be properly solved (and vice versa). We have enough mess in the bug tracker without that so anyone who deals with them should at least know of that connection.

@Sciss said:
For reference, here is the scala-debate thread. There are some valid points against this, particularly when custom extractors are used, there is no defined naming for the "arguments" (because they are the elements of the return tuple).

Shelby Moore III (shelby) said:
My thought is to prefer:

1. case Advance(time, isSeek)
2. case Advance(time, isSeek = false)
3. case Advance(t = time, isSeek = false)

instead of:

1. case Advance(time = time, isSeek = isSeek)
2. case Advance(time = time, isSeek = false)
3. case Advance(time = t, isSeek = false)

Named tuples may aid unification with custom extractors.

val t = new Tuple2(42,1){def first = _1; def second = _2}

t.first
res7: Int = 42

t.second
res8: Int = 1

Shelby Moore III (shelby) said (edited on Jul 24, 2013 2:03:40 AM UTC):
At the aforementioned discussion thread, one suggestion is to use == instead of = when matching a named parameter to a value:

2. case Advance(time, isSeek == false)
3. case Advance(t = time, isSeek == false)

This allows the order to be consistent:

2. case Advance(time, false == isSeek)
3. case Advance(t = time, false == isSeek)

I also suggested that default parameters only apply when no parameters are being extracted, i.e. there are only values specified for the parameters. This maintains the symmetry with constructors.

Should a SIP be created for this ticket?

@Sciss said:
The problem with == is that you can't distinguish it from a Boolean expression which is totally valid, too. Of course, the difference is that isSeek is an argument name. So this produces the same confusion as with catching symbols versus backtick escaping, e.g.

val isSeek: Boolean = ???

def m(a: Any) = a match {
  case Advance(t = time, { println("hi there"); false == isSeek }) => ...
}

To use the value, you would need to write false == isSeek``

Here is another suggestion, using the left-arrow from for-comprehensions:

case Advance(t <- time, false <- isSeek)

case Person(LegalToDrink(a) <- age)
case Person(ltd @ LegalToDrink(a) <- age)
case Person(ltd: LegalToDrink <- age)

The advantage of this IMO is that it doesn't introduce any new syntactic concept or variant, but is well established. On the other hand, in for-comprehensions the left-arrow indicates that the symbol is a looping variable, something that is not the case here.

A third suggestion would be to require guards for ==. Something like

    case Advance(t <- time) if !isSeek =>

One would then be free to use = instead of <-, e.g.

case Advance(t = time) if !isSeek =>

case Advance(val t = time) if !isSeek =>

Shelby Moore III (shelby) said (edited on Jul 25, 2013 4:01:29 AM UTC):
Sciss, I think the == named matching syntax (which is your idea from the aforementioned discussion group) can be distinguished from a boolean expression forming a unnamed matching value because the value of isSeek does not pre-exist in the former case. I prefer the == syntax because it is the more obvious (unified with pre-existing syntax) than for-comprehension left-arrow (to me at least) and more regular/unified/less verbose than guards.

P.S. Note the typo in the bug description; it should be SIP (Scala Improvement Process) not SID (document).

What's the status of this feature?

We currently have no plans to implement this. Since this involves a language change, it would require a SIP.

This would be a great project for somebody who wants to tackle something a bit more ambitious (yet not fundamentally difficult).

This is something a lot of people have wanted for a long time, so any volunteer who appeared would get lots of support and encouragement.

Adding it to Scala 2 first, then forward-porting to 3, is a possibility, but it's equally plausible to target 3 first, then (optionally) backport. Note that we can't go forward with this in 2 unless the 3 team is on board.

@Sciss said:
For reference, here is the scala-debate thread. There are some valid points against this, particularly when custom extractors are used, there is no defined naming for the "arguments" (because they are the elements of the return tuple).

I haven't read the thread yet, but since 2013 two relevant things have happened:

1. Scala 3 extended custom extractors to return Product ("Product Match" in https://dotty.epfl.ch/docs/reference/changed-features/pattern-matching.html); and
2. we've added productElementNames to Product

So I think this might no longer be a blocker.

This is under discussion at https://contributors.scala-lang.org/t/pattern-matching-with-named-fields/1829

For reference, here is the scala-debate thread.

New link (though behind http-use warning): https://grokbase.com/t/gg/scala-debate/12ad0n33b0/default-and-named-arguments-in-extractors

SIP: scala/improvement-proposals#44