You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
/** Type cast; needs to be inlined to work as given */*/defasInstanceOf[A]:A=thismatch {
casex: A=> x
case _ =>if (this eq null) thiselsethrownewClassCastException()
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.
The text was updated successfully, but these errors were encountered:
@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. :-)
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.
asInstanceOf is defined as follows in the spec:
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.
The text was updated successfully, but these errors were encountered: