Skip to content

Fix #4785: change typing rule for _* args #4787

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

Closed
wants to merge 2 commits into from

Conversation

allanrenucci
Copy link
Contributor

In expression position, if a tree is of the form expr: _*, try to type
expr as an Array and as a Seq if there are errors

@allanrenucci allanrenucci force-pushed the type-wildcardstararg branch from 0c89b74 to 721c97e Compare July 12, 2018 15:07
In expression position, if a tree is of the form `expr: _*`, try to type
`expr` as an `Array` and as a `Seq` if there are errors
@smarter
Copy link
Member

smarter commented Jul 13, 2018

FWIW, the following code used to find the seq implicit but now finds the array implicit (it doesn't compile at all with 2.12):

object Test {
  implicit def array: Array[Int] = Array(0)
  implicit def seq: Seq[Int] = Seq(0)

  def foo(x: Int*) = x

  def main(args: Array[String]): Unit = {
    println(foo(implicitly: _*))
  }
}

Any reason to try the Array prototype first? Most of the time I expect users would pass a Seq, so that would be a lot of unnecessary retyping. I also wonder if you could use a union of Array or Seq as the prototype.

@allanrenucci
Copy link
Contributor Author

Any reason to try the Array prototype first?

We could try Seq first if there were no implicit conversion from Array to Seq defined in Predef

@smarter
Copy link
Member

smarter commented Jul 13, 2018

Maybe try Array first only for JavaDefined methods?

@smarter
Copy link
Member

smarter commented Jul 13, 2018

Wait, doesn't #4785 imply that this implicit conversion won't exist with 2.13, thus solving the problem?

@allanrenucci
Copy link
Contributor Author

No, still there.

@allanrenucci
Copy link
Contributor Author

Anyway, relying on an implicit conversion defined in the standard library to typecheck calls to Java methods with repeated arguments seems like a very bad idea to me. What if I compile with -Yno-imports?

Copy link
Contributor

@odersky odersky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we agreed that we would not support this. I.e. we should allow arrays only for Java varargs.

In other words:

  • If it's a Java vararg the argument has to be an array
  • If it's a Scala vararg the argument has to be an immutable.Seq.'

@odersky
Copy link
Contributor

odersky commented Jul 19, 2018

On further discussion, I think it's preferable to have automatic conversions for varargs. We already have a conversion from Seq to Array when passing a Seq argument to a Java vararg. We should have a dual conversion from Array to Seq when passing an Array argument to a Scala vararg. I believe the Array-> Seq conversion should make a defensive copy of the array in order to prevent mutations leaking into the vararg.

@allanrenucci
Copy link
Contributor Author

Superseded by #5577

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants