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
long-standing spec issues with asInstanceOf #4437
Comments
Imported From: https://issues.scala-lang.org/browse/SI-4437?orig=1 |
@odersky said: Agreed on (2). Let's endorse it. Reassigning to Paul for the time being, but feel free to pull other people in as needed. |
@soc said: |
@soc said: Shall we close this bug and move issue 1 to a new bug number? |
This is one of those things which makes our lives harder for no benefit that I can see.
It has nice pointy teeth (this one is #1448):
This sort of thing just seems wrong:
But if it can only be used successfully on the final numeric types and not AnyVal and Any, what advantage does it have over 5.toLong?
I don't see how it makes conceptual sense either. A cast suggests that the value in question already has the correct representation, and the type system only needs to be informed that it's a B in addition to being an A. But casting an Int to a Long clearly requires a conversion because they have different sizes. And indeed it is specified as applying a conversion.
So what are we getting out of this self-identified "treated specially"-case which we wouldn't have by deprecating-and-eliminating it?
The spec says:
This is not true, and cannot reasonably be made true at present. Example usages in trunk include:
For reasons I don't know, the syntax "var x: T = _" only works for fields, not locals. Without it there is no way to initialize a generic type unless you have a pre-existing value or are willing to cast null in defiance of the spec. So by default, null.asInstanceOf[T] has become the "best practice" way to initialize such values (given that it's the only way.) We need to either endorse it (and change the spec) or offer an alternative and bring the spec into line with reality. Right now there is a "shadow spec" on this point.
My suggestion is to just endorse it, since in practice I don't think we can change it. Even if "var x: T = _" were enabled for local declarations, #602 gets into the real problem. If you parameterize a java type on a primitive, it will come back full of nulls, because in reality it's holding boxes. If nulls are treated as uninitialized values of the right type (i.e. 0 or false) then things work. If not then they won't. I don't think that situation can be finessed.
The text was updated successfully, but these errors were encountered: