Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Repeated parameter A* doesn't behave like Seq[A] on a pattern match #5967

Closed
scabug opened this issue Jun 23, 2012 · 8 comments
Closed

Repeated parameter A* doesn't behave like Seq[A] on a pattern match #5967

scabug opened this issue Jun 23, 2012 · 8 comments
Assignees
Labels
Milestone

Comments

@scabug
Copy link

@scabug scabug commented Jun 23, 2012

This doesn't compile:

def f(a: Int*) = a match {
  case 0 :: Nil => "List(0)! My favorite Seq!"
  case _ => a.toString
}
error: constructor cannot be instantiated to expected type;
 found   : collection.immutable.::[B]
 required: Int*

But this does:

def f(a: Int*) = (a: Seq[Int]) match {
  case 0 :: Nil => "List(0)! My favorite Seq!"
  case _ => a.toString
}

I think it's obvious, but per the spec, the identifier a should already have the type Seq[Int] inside the body of f in either case, yet in the first case, the compiler seems to think that a has a type which is a strict subtype of Seq[Int] and which List does not extend.

Seems related to (if not a dupe of) #4176.

@scabug

This comment has been minimized.

Copy link
Author

@scabug scabug commented Jun 23, 2012

Imported From: https://issues.scala-lang.org/browse/SI-5967?orig=1
Reporter: Ryan Hendrickson (ryan.hendrickson_bwater)
Affected Versions: 2.10.0-M4
See #4176

@scabug

This comment has been minimized.

Copy link
Author

@scabug scabug commented Jun 25, 2012

@retronym said:
Easy enough to remedy, but the solution feels a bit dirty. Suggestions for improvement welcome.

https://github.com/retronym/scala/compare/ticket/4176

@scabug

This comment has been minimized.

Copy link
Author

@scabug scabug commented Jun 25, 2012

Ryan Hendrickson (ryan.hendrickson_bwater) said:
Sorry if this is a dumb thought, but would it be less dirty to fix this in typedIdent rather than typedMatch? I'm thinking something like changing that final call to stabilize (line 4751 in your commit) from

stabilize(tree2, pre2, mode, pt)

to

val tree3 = stabilize(tree2, pre2, mode, pt)
tree3 setType dropRepeatedParamType(tree3.tpe)

Unless this is bad for some reason, it seems like it represents the general idea of "identifiers referring to repeated parameter symbols should have Seq type rather than type" better than fixing it ad-hoc for pattern matching. (And maybe—I haven't tried this, just a shot in the dark—it would mean you don't need dropRepeatedParamType inside widenIfNecessary anymore to ensure that val a2 = a doesn't get a's ness.)

@scabug

This comment has been minimized.

Copy link
Author

@scabug scabug commented Jun 25, 2012

@retronym said:
Sounds like a good suggestion; I'll see how it pans out.

@scabug

This comment has been minimized.

Copy link
Author

@scabug scabug commented Jun 25, 2012

@adriaanm said:
not sure that would work, since I think we rely on the special type for overload resolution (see some of the recent bugs regarding overloading and varargs)

@scabug

This comment has been minimized.

Copy link
Author

@scabug scabug commented Jun 25, 2012

Ryan Hendrickson (ryan.hendrickson_bwater) said:
Changing typedIdent shouldn't change anything about the type of the parameter symbol, which is what gets looked at when overload resolution is performed, right?

@scabug

This comment has been minimized.

Copy link
Author

@scabug scabug commented Jun 25, 2012

@adriaanm said:
right, my mistake

@scabug

This comment has been minimized.

Copy link
Author

@scabug scabug commented Jul 1, 2012

@scabug scabug closed this Jul 2, 2012
@scabug scabug added this to the 2.10.0 milestone Apr 7, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.