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
by-name argument creates spurious type mismatch #5886
Comments
Imported From: https://issues.scala-lang.org/browse/SI-5886?orig=1 |
Bruno Bieth (mustaghattack) said: "".getClass must haveClass[String] Doesn't compile anymore |
@adriaanm said: |
@retronym said: There doesn't appear to be any material difference in
|
@retronym said: retronym/scala@scala:2.10.x...retronym:ticket/5886 What was it trying to prevent? |
@paulp said (edited on Jan 14, 2013 5:00:40 PM UTC): It seems relevant that "x: T" is stable but "x: => T" is not, as I discovered when I tried to return x.type from f1. I'm not 100% sure why "x: () => T" is more acceptable (I'm not 100% sure of the rest of this either, or much of anything else really) but it makes sense on some level which I won't try to articulate. But in the end, either we can come up with a way that allowing f1 to work is unsound, or we should make it work. These handwavy attempts to retrofit logic onto ancient code are unacceptable. |
@paulp said: def fn(arr1: Array[_ <: AnyRef], arr2: Array[_ <: AnyRef]) And see if you can somehow exploit the absence of that check to assign between those arrays. |
@adriaanm said: |
@retronym said: |
@adriaanm said: |
@paulp said: |
The text was updated successfully, but these errors were encountered: