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

Spec for asInstanceOf is inconsistent (and doesn't match observed behaviour) #1447

Open
scabug opened this issue Oct 25, 2008 · 6 comments
Open

Comments

@scabug
Copy link

scabug commented Oct 25, 2008

asInstanceOf is defined as follows in the spec:

/** Type cast; needs to be inlined to work as given */ */
def asInstanceOf[A]: A = this match {
  case x: A => x
  case _ => if (this eq null) this
            else throw new ClassCastException()

Unfortunately this doesn't typecheck because "this" is not an A. If you had the bound A >: Null then returning null would work there, but of course there's no depend on this behaviour. It also doesn't correspond to observed behaviour for AnyVals, nor the specified behaviour for casting null (See section 6.3).

See #668 for past attempts to fix this and why they break. It seems that the behaviour for casting null to AnyVal types really does need to be there, but it really should be in the spec if it's going to continue behaving that way.

@scabug
Copy link
Author

scabug commented Oct 25, 2008

Imported From: https://issues.scala-lang.org/browse/SI-1447?orig=1
Reporter: @DRMacIver

@scabug
Copy link
Author

scabug commented Oct 28, 2008

@odersky said:
Hi David, do you want to suggest a way to fix this? -- Martin

@scabug
Copy link
Author

scabug commented Oct 28, 2008

@DRMacIver said:
Unfortunately I've been trying to think of a good one and haven't come up with any. I'm not sure the definition in terms of pattern matching is fixable. I was hoping someone else would have a bright idea about it. :-)

@scabug
Copy link
Author

scabug commented Mar 28, 2010

@SethTisue said:
see also #1558

@SethTisue
Copy link
Member

this came up recently at a SIP meeting https://docs.scala-lang.org/sips/minutes/2017-12-06-sip-minutes.html /cc @milessabin @sjrd

@milessabin
Copy link

I'm not sure much can be done to make that pseudo code make literal sense. Apart from anything else, the A in the case x: A would be eliminated by erasure and so the first case would always apply and the second case would be dead code.

I think it should be treated as typechecking poetically rather than literally.

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

No branches or pull requests

4 participants