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
Casting of AnyVal types behaves differently based on compile time type #1448
Comments
Imported From: https://issues.scala-lang.org/browse/SI-1448?orig=1 |
@DRMacIver said: I still think the first option is technically the correct one. But it probably requires a lot of code to be fixed. |
@odersky said: |
@gzm0 said: scala> 1L.isInstanceOf[Int]
res0: Boolean = false |
@retronym said: The test x.asInstanceOf[T] is treated specially if T is a numeric value type (§12.2). In this case the cast will be translated to an application of a conversion method x.toT (§12.2.1). For non-numeric values x the operation will raise a ClassCastException. |
@gzm0 said (edited on Dec 20, 2013 9:29:44 AM UTC): |
@gzm0 said: |
@gzm0 said: |
@gzm0 said: |
@paulp said: In the first comment martin says "We need to leave asInstanceOf as an operation that can cast an Any to a numeric type." I don't know if your quote means you didn't see the comment or that you don't yet know why this is sufficient to prevent you from fixing it. |
@paulp said: |
@paulp said: Thanks for your feedback and taking the time.
The problem is that it requires an additional Further, most of the concerns raised about disallowing casts for conversion were about breaking code. scala/scala#3295 (and comments) shows that we can properly deprecate such code and that it can easily be adapted (even the compiler just rewrites |
@paulp said:
Okay, but that was obvious from the beginning. I'm not sure if you're reading between the lines here or what so I'll be clearer: martin settles these issues by fiat. If "martin has asked me to" means he has changed his stance offline, then you should articulate that clearly, because this isn't about the technical question. |
@gzm0 said: More clearly: Martin was especially concerned with the fact that this makes boxing observable and thinks this (i.e. this ticket) needs to be fixed. He therefore proposed to lift the casts in unboxing from PR #3294 does this, nothing blows up, one additional |
@paulp said: |
@adriaanm said: |
Consider the following examples:
It seems that when you cast AnyVals of known types between eachother the compiler turns them into numeric conversions as with Java. However if you cast an Any to an AnyVal subtype it does not perform these conversions. This seems like very inconsistent behaviour to me (It's also counter to the specced behaviour).
There are two possible fixes here:
I strongly prefer the former (in particular it's what the spec says should happen). I suspect the latter is the one that will annoy people the least.
The text was updated successfully, but these errors were encountered: