Why does Scala allow type casts outside a type hierarchy?

["Ionuț G. Stan"]

Hi all,

A friend of mine just discovered that the following cast typechecks:

scala> val s: String = null
s: String = null

scala> s.asInstanceOf[Int]
res2: Int = 0

After a few Google searches, I found this:
https://github.com/scala/scala-dist/pull/104/files, but it doesn't offer
an explanation about the type checking aspect and it's not clear whether
that rule should apply to *all* null values.

My question is, why does the Scala compiler even allow a call to the
asInstanceOf method in this case where the String and Int types are not
part of the same type hierarchy. This kind of cast is called a "stupid
cast" in TaPL.

Also, why does it even allow this:

null.asInstanceOf[Int]

knowing that we can't do this:

val x: Int = null

I know asInstanceOf is bad and such, but still... rendering it even less
typesafe than Java's cast mechanism is not really progress.

--
Ionuț G. Stan | http://igstan.ro

[Simon Ochsenreither]

null.asInstanceOf[T] is Scala's idiom for instantiating a "zero" or "default" value for an arbitrary type, comparable to C#'s default(T).

I think people have been talking about providing a more user-friendly wrapper like def default[T] = null.asInstanceOf[T], but nothing specific so far.

[Simon Ochsenreither]

Mh, that wasn't quite on-topic.

I'll try again:

Not sure if it might make sense to have a warning for casts which don't make sense from a static type perspective (we can't say "warning for casts which are guaranteed to fail" because as you realized if it's null it doesn't fail), because asInstanceOf is seen as the last-resort escape hatch which says "compiler, believe me in whatever I'm doing now".

Also, why does it even allow this:

null.asInstanceOf[Int]

knowing that we can't do this:

val x: Int = null

There is a difference between a type ascription and a cast, just like in Java:

    int foo = 123L;       // doesn't work
    int bar = (int) 123L; // works

["Ionuț G. Stan"]

On 08/09/14 12:01, Simon Ochsenreither wrote:
> Mh, that wasn't quite on-topic.

Indeed :)

> I'll try again:
>
> Not sure if it might make sense to have a warning for casts which don't
> make sense from a static type perspective (we can't say "warning for
> casts which are guaranteed to fail" because as you realized if it's null
> it doesn't fail), because asInstanceOf is seen as the last-resort escape
> hatch which says "compiler, believe me in whatever I'm doing now".

I guess my main point is that it doesn't make sense to allow that
null.asInstanceOf[AnyVal] idiom. We can't assign null values to AnyVal
instances, then we shouldn't be able to use asInstanceOf to do the opposite.

The semantics of asInstanceOf are quite weird, because its behaviour
depends not only on the runtime type tag, but also on the runtime value
of that object pointer. This is really confusing from my point of view.
When you cast to a different type, you don't expect a change in the
runtime behaviour except for a ClassCastException. With the current
behaviour, I have to think that from `null` I can go to `true`, `false`,
`1`, etc. or a ClassCastException.

So, IMHO, the quote "compiler, believe me in whatever I'm doing now"
should be "compiler, believe me in whatever I'm doing now at the type
level".

Following the current logic, null.isInstanceOf[AnyVal] should always
yield true, because we can always cast to a default value. However, the
spec says
(http://www.scala-lang.org/files/archive/spec/2.11/06-expressions.html#the-null-value):
"isInstanceOf[T] always returns false"

Shouldn't isInstanceOf and asInstanceOf obey this rule?

When v.isInstanceOf[T] returns false, then asInstanceOf[T] should throw
a ClassCastException.

> Also, why does it even allow this:
>
> null.asInstanceOf[Int]
>
> knowing that we can't do this:
>
> val x: Int = null
>
>
> There is a difference between a type ascription and a cast, just like in
> Java:
>
> int foo = 123L; // doesn't work
> int bar = (int) 123L; // works

I'm not sure I see the parallel here. It should have been:

int foo = null; // doesn't work: "cannot convert from null to int"
int bar = (int) null; // doesn't work: "cannot cast from null to int"

Grantedly, Scala shouldn't always be modeled by Java's behaviour, but in
this particular case the Java way of doing things is better because it
is more typesafe.

[Simon Ochsenreither]

Grantedly, Scala shouldn't always be modeled by Java's behaviour, but in
this particular case the Java way of doing things is better because it
is more typesafe.

Not sure I'd buy that argument. The whole point of casting is to make the compiler ignore types.

["Ionuț G. Stan"]

If that's its *only* purpose (and doesn't do runtime things like
converting nulls to default values for primitives) then there are two
levels of ignorance:

1. casts that may succeed, also called down casts
2. casts that will *never* succeed, also called stupid casts

An example of #1 that succeeds is this (let's ignore erasure for a moment):

val x: Seq[Int] = Vector(1, 2, 3)
x.asInstanceOf[Vector[Int]]

An example of #1 that doesn't succeed is this:

val x: Seq[Int] = Vector(1, 2, 3)
x.asInstanceOf[List[Int]]

An example of #2 is this:

val x: Seq[Int] = Vector(1, 2, 3)
x.asInstanceOf[scala.concurrent.Future[Int]]

The last example is a runtime error. I'm arguing that it should be a
compile-time error in Scala, too. The problem is that asInstanceOf does
more things than just please the compiler from a types perspective.


Here's where things get really weird:

scala> val x: String = null
x: String = null

scala> x.asInstanceOf[Boolean]
res10: Boolean = false

scala> val x: String = "not null"
x: String = not null

scala> x.asInstanceOf[Boolean]
java.lang.ClassCastException: java.lang.String cannot be cast to
java.lang.Boolean
at scala.runtime.BoxesRunTime.unboxToBoolean(BoxesRunTime.java:89)
... 33 elided

[Simon Ochsenreither]

So what's the alternative for people who are using the null.asInstanceOf[T] technique to get default values?

[Patrik Andersson]

How is that even remotely useful outside of primitives?

On 08 Sep 2014, at 13:32, Simon Ochsenreither <simon.och...@gmail.com> wrote:

So what's the alternative for people who are using the null.asInstanceOf[T] technique to get default values?

--
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-languag...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

["Ionuț G. Stan"]

On 08/09/14 14:32, Simon Ochsenreither wrote:
> So what's the alternative for people who are using the
> null.asInstanceOf[T] technique to get default values?

To provide a separate mechanism.

[Jesper Nordenberg]

The reason why the cast is allowed is the type checker treats asInstanceOf as a normal method defined in the Any type. Casting is used much more seldom in Scala than Java (mainly because of pattern matching), so the effort to add special handling of asInstanceOf in the type checker might not be worth the effort.

Note that for generic fields you can use underscore as generic default value, so no need to use asInstanceOf there:

class A[T] {

  var f: T = _

}

/Jesper Nordenberg

[Simon Ochsenreither]

To provide a separate mechanism.

How would the implementation look like?

["Ionuț G. Stan"]

On 08/09/14 14:40, Jesper Nordenberg wrote:
> The reason why the cast is allowed is the type checker treats
> asInstanceOf as a normal method defined in the Any type. Casting is used
> much more seldom in Scala than Java (mainly because of pattern
> matching), so the effort to add special handling of asInstanceOf in the
> type checker might not be worth the effort.

Hmm, that is an interesting observation. It probably answers the
question. It does for me, at least.

I guess the only question now is why let asInstanceOf's behaviour depend
on runtime values instead of runtime type tags only.

> Note that for generic fields you can use underscore as generic default
> value, so no need to use asInstanceOf there:
>
> class A[T] {
> var f: T = _
> }
>
> /Jesper Nordenberg
>
> On Monday, 8 September 2014 10:38:27 UTC+2, Ionuț G. Stan wrote:
>
> Hi all,
>
> A friend of mine just discovered that the following cast typechecks:
>
> scala> val s: String = null
> s: String = null
>
> scala> s.asInstanceOf[Int]
> res2: Int = 0
>
> After a few Google searches, I found this:
> https://github.com/scala/scala-dist/pull/104/files

> <https://github.com/scala/scala-dist/pull/104/files>, but it doesn't

> offer
> an explanation about the type checking aspect and it's not clear
> whether
> that rule should apply to *all* null values.
>
> My question is, why does the Scala compiler even allow a call to the
> asInstanceOf method in this case where the String and Int types are not
> part of the same type hierarchy. This kind of cast is called a "stupid
> cast" in TaPL.
>
> Also, why does it even allow this:
>
> null.asInstanceOf[Int]
>
> knowing that we can't do this:
>
> val x: Int = null
>
> I know asInstanceOf is bad and such, but still... rendering it even
> less
> typesafe than Java's cast mechanism is not really progress.
>
> --
> Ionuț G. Stan | http://igstan.ro
>

> --
> You received this message because you are subscribed to the Google
> Groups "scala-language" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to scala-languag...@googlegroups.com

> <mailto:scala-languag...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.

[Roland Kuhn]

8 sep 2014 kl. 12:47 skrev Ionuț G. Stan <ionut....@gmail.com>:

> On 08/09/14 13:31, Simon Ochsenreither wrote:
>> Grantedly, Scala shouldn't always be modeled by Java's behaviour,
>> but in
>> this particular case the Java way of doing things is better because it
>> is more typesafe.
>>
>>
>> Not sure I'd buy that argument. The whole point of casting is to make
>> the compiler ignore types.
>
> If that's its *only* purpose (and doesn't do runtime things like converting nulls to default values for primitives) then there are two levels of ignorance:
>
> 1. casts that may succeed, also called down casts
> 2. casts that will *never* succeed, also called stupid casts
>
> An example of #1 that succeeds is this (let's ignore erasure for a moment):
>
> val x: Seq[Int] = Vector(1, 2, 3)
> x.asInstanceOf[Vector[Int]]
>
> An example of #1 that doesn't succeed is this:
>
> val x: Seq[Int] = Vector(1, 2, 3)
> x.asInstanceOf[List[Int]]
>
> An example of #2 is this:
>
> val x: Seq[Int] = Vector(1, 2, 3)
> x.asInstanceOf[scala.concurrent.Future[Int]]
>
> The last example is a runtime error.

If you allow the Seq[Int] to be provided by another RHS then this cast might very well not be nonsensical at all: neither Seq nor Future are sealed and therefore we (and the compiler) cannot prove that the intersection of these two types is indeed empty; I might just write a class that implements both interfaces. This is the reason why casts like these are not rejected—and why it would be a bad thing to change it the way you want.

Regards,

Roland

> I'm arguing that it should be a compile-time error in Scala, too. The problem is that asInstanceOf does more things than just please the compiler from a types perspective.
>
>
> Here's where things get really weird:
>
> scala> val x: String = null
> x: String = null
>
> scala> x.asInstanceOf[Boolean]
> res10: Boolean = false
>
> scala> val x: String = "not null"
> x: String = not null
>
> scala> x.asInstanceOf[Boolean]
> java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Boolean
> at scala.runtime.BoxesRunTime.unboxToBoolean(BoxesRunTime.java:89)
> ... 33 elided
>
>
> --
> Ionuț G. Stan | http://igstan.ro
>

> --
> You received this message because you are subscribed to the Google Groups "scala-language" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to scala-languag...@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

Dr. Roland Kuhn
Akka Tech Lead
Typesafe – Reactive apps on the JVM.
twitter: @rolandkuhn

["Ionuț G. Stan"]

On 08/09/14 14:41, Simon Ochsenreither wrote:
>
> To provide a separate mechanism.
>
>
> How would the implementation look like?

A possible alternative: https://gist.github.com/igstan/b800988ddfc05cb44ec3

["Ionuț G. Stan"]

On 08/09/14 14:57, Roland Kuhn wrote:
>
> 8 sep 2014 kl. 12:47 skrev Ionuț G. Stan <ionut....@gmail.com>:
>
>> On 08/09/14 13:31, Simon Ochsenreither wrote:
>>> Grantedly, Scala shouldn't always be modeled by Java's behaviour,
>>> but in
>>> this particular case the Java way of doing things is better because it
>>> is more typesafe.
>>>
>>>
>>> Not sure I'd buy that argument. The whole point of casting is to make
>>> the compiler ignore types.
>>
>> If that's its *only* purpose (and doesn't do runtime things like converting nulls to default values for primitives) then there are two levels of ignorance:
>>
>> 1. casts that may succeed, also called down casts
>> 2. casts that will *never* succeed, also called stupid casts
>>
>> An example of #1 that succeeds is this (let's ignore erasure for a moment):
>>
>> val x: Seq[Int] = Vector(1, 2, 3)
>> x.asInstanceOf[Vector[Int]]
>>
>> An example of #1 that doesn't succeed is this:
>>
>> val x: Seq[Int] = Vector(1, 2, 3)
>> x.asInstanceOf[List[Int]]
>>
>> An example of #2 is this:
>>
>> val x: Seq[Int] = Vector(1, 2, 3)
>> x.asInstanceOf[scala.concurrent.Future[Int]]
>>
>> The last example is a runtime error.
>
> If you allow the Seq[Int] to be provided by another RHS then this cast might very well not be nonsensical at all: neither Seq nor Future are sealed and therefore we (and the compiler) cannot prove that the intersection of these two types is indeed empty; I might just write a class that implements both interfaces. This is the reason why casts like these are not rejected—and why it would be a bad thing to change it the way you want.

Indeed. That was a bad example from my part. On the other hand, String
and Int are definitely not part of the same type hierarchy.

Anyway, after Jesper Nordenberg's email, I'm less disturbed by this
behaviour. Although, it shows why casting should be separate syntax in a
language.

[Nick Stanchenko]

What about 5.asInstanceOf[Any].asInstanceOf[String] ?

Those who seek fill find :)

Nick

[Ruebenacker, Oliver A]

Hello,

> > There is a difference between a type ascription and a cast, just like in
> > Java:
> >
> > int foo = 123L; // doesn't work
> > int bar = (int) 123L; // works
>
> I'm not sure I see the parallel here. It should have been:
>
> int foo = null; // doesn't work: "cannot convert from null to int"
> int bar = (int) null; // doesn't work: "cannot cast from null to int"
>
> Grantedly, Scala shouldn't always be modeled by Java's behaviour, but in
> this particular case the Java way of doing things is better because it
> is more typesafe.

Keep in mind that Scala's Int is a combination of Java's int and Integer. Java's Integer can be null.

Best,
Oliver

>
>
> --
> Ionuț G. Stan | http://igstan.ro
>

> --
> You received this message because you are subscribed to the Google Groups
> "scala-language" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to scala-languag...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

***********************************************************************************************************************

This email message and any attachments are intended solely for the use of the addressee. If you are not the intended recipient, you are prohibited from reading, disclosing, reproducing, distributing, disseminating or otherwise using this transmission. If you have received this message in error, please promptly notify the sender by reply email and immediately delete this message from your system. This message and any attachments may contain information that is confidential, privileged or exempt from disclosure. Delivery of this message to any person other than the intended recipient is not intended to waive any right or privilege. Message transmission is not guaranteed to be secure or free of software viruses.
***********************************************************************************************************************

["Ionuț G. Stan"]

On 08/09/14 16:52, Ruebenacker, Oliver A wrote:
>
> Hello,
>
>>> There is a difference between a type ascription and a cast, just like in
>>> Java:
>>>
>>> int foo = 123L; // doesn't work
>>> int bar = (int) 123L; // works
>>
>> I'm not sure I see the parallel here. It should have been:
>>
>> int foo = null; // doesn't work: "cannot convert from null to int"
>> int bar = (int) null; // doesn't work: "cannot cast from null to int"
>>
>> Grantedly, Scala shouldn't always be modeled by Java's behaviour, but in
>> this particular case the Java way of doing things is better because it
>> is more typesafe.
>
> Keep in mind that Scala's Int is a combination of Java's int and Integer. Java's Integer can be null.

Actually, I did, but it didn't change the problem from my point of view.

[Andrew Phillips]

> Here's where things get really weird: 

>

> scala> val x: String = null 

> x: String = null 

>

> scala> x.asInstanceOf[Boolean] 

> res10: Boolean = false

See also http://scalapuzzlers.com/#pzzlr-029...

ap

[Ruebenacker, Oliver A]

 

     Hello,

 

scala> null.asInstanceOf[Int]

res8: Int = 0

 

scala> 0:Any

res9: Any = 0

 

scala> null.asInstanceOf[Int]:Any

res10: Any = null

 

  Essentially, the compiler unboxes null to default value, and may optimize away subsequent unbox/box operations even though it will not give the same result for null.

 

     Best, Oliver

 

--

You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-languag...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Naftoli Gugenheim]

Even if null.asInstanceOf[Int] is a needed idiom, it doesn't mean you have to allow (null: String).asInstanceOf[Int]. When would that idiom be useful without the null literal? Also it's not just a difference in syntax or runtime values; null on its own has inferred type Null, so the differentiation is at the type level.

On Monday, September 8, 2014, Simon Ochsenreither <simon.och...@gmail.com> wrote:

So what's the alternative for people who are using the null.asInstanceOf[T] technique to get default values?

--

[Naftoli Gugenheim]

On Monday, September 8, 2014, Jesper Nordenberg <jesper.n...@gmail.com> wrote:

The reason why the cast is allowed is the type checker treats asInstanceOf as a normal method defined in the Any type.

Still, the type system allows for more complex type checks, via implicit evidence. I don't know exactly how that would look offhand, or if there's a way to encode "impossible to intersect." On the other hand if there would be such a typeclass then asInstanceOf could be made more sound in a way that would not be a "special case" but just by composing other language features --- something that scala tries to do a lot (or used to). (Also it may require isInstanceOf to be defined on an implicit class so it could have the "MyType.")

 

--

[Paolo Giarrusso]

I agree it's odd that `null.asInstanceOf[Int]` works. But:

On Monday, September 8, 2014 11:53:49 AM UTC+2, Ionuț G. Stan wrote:

Following the current logic, null.isInstanceOf[AnyVal] should always
yield true, because we can always cast to a default value. However, the
spec says
(http://www.scala-lang.org/files/archive/spec/2.11/06-expressions.html#the-null-value):
"isInstanceOf[T] always returns false"

Shouldn't isInstanceOf and asInstanceOf obey this rule?

When v.isInstanceOf[T] returns false, then asInstanceOf[T] should throw
a ClassCastException.

Let me answer just on this bit. I agree this is confusing, but it's "right" — that's the same as Java's instanceof: null is a special case.

Everybody (me included) tends to think that "v isInstanceOf [T]" is equivalent to "v can be casted to T". Instead, it means "v is an actual instance of T", so excluding null. There's quite some code which would get less useful or (a bit) more complicated to write otherwise — for instance take a correct manual implementation of equals, if you're one of those enlightened souls who can write one without looking up how.

I think I only learned this when implementing a compiler for a Java subset for a class, so misunderstanding this is entirely reasonable.

["Ionuț G. Stan"]

On 13/09/14 18:36, Paolo Giarrusso wrote:
> I agree it's odd that `null.asInstanceOf[Int]` works. But:
>
> On Monday, September 8, 2014 11:53:49 AM UTC+2, Ionuț G. Stan wrote:
>
> Following the current logic, null.isInstanceOf[AnyVal] should always
> yield true, because we can always cast to a default value. However, the
> spec says
> (http://www.scala-lang.org/files/archive/spec/2.11/06-expressions.html#the-null-value

> <http://www.scala-lang.org/files/archive/spec/2.11/06-expressions.html#the-null-value>):

>
> "isInstanceOf[T] always returns false"
>
>
> Shouldn't isInstanceOf and asInstanceOf obey this rule?
>
> When v.isInstanceOf[T] returns false, then asInstanceOf[T] should throw
> a ClassCastException.
>
>
> Let me answer just on this bit. I agree this is confusing, but it's
> "right" — that's the same as Java's instanceof: null is a special case.
> Everybody (me included) tends to think that "v isInstanceOf [T]" is
> equivalent to "v can be casted to T". Instead, it means "v is an actual
> instance of T", so excluding null. There's quite some code which would
> get less useful or (a bit) more complicated to write otherwise — for
> instance take a correct manual implementation of equals, if you're one
> of those enlightened souls who can write one without looking up how.
>
> I think I only learned this when implementing a compiler for a Java
> subset for a class, so misunderstanding this is entirely reasonable.

Thanks. Yes, you're right. Java will return false for `null instanceof
A` for all types A, but still let you cast that null to a type of A.

It makes sense when you think of null as a bottom type. At that point,
the cast is effectively an upcast, not a downcast.

Any ideas as to why instanceof can't always return true when the runtime
value is null?

[Oliver Ruebenacker]

     Hello,

  I think it is a design decision based on a practical consideration: usually, you ask whether something is instanceof if you want to call some methods on it, and you can't call methods on null.

  On the other hand, casting null can be important if you want to pass null as an argument to an overloaded method and the casted type is needed for overload resolution.

     Best, Oliver

--
Ionuț G. Stan  |  http://igstan.ro

--
You received this message because you are subscribed to the Google Groups "scala-language" group.

To unsubscribe from this group and stop receiving emails from it, send an email to scala-language+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Oliver Ruebenacker

Solutions Architect at Altisource Labs

Be always grateful, but never satisfied.

[Naftoli Gugenheim]

... after all, Java doesn't have type ascription...

 

     Best, Oliver

--
Ionuț G. Stan  |  http://igstan.ro

--
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-language+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Oliver Ruebenacker

Solutions Architect at Altisource Labs

Be always grateful, but never satisfied.

--
You received this message because you are subscribed to the Google Groups "scala-language" group.

To unsubscribe from this group and stop receiving emails from it, send an email to scala-languag...@googlegroups.com.

["Ionuț G. Stan"]

On 15/09/14 08:58, Naftoli Gugenheim wrote:
> ... after all, Java doesn't have type ascription...

Casting is considered a form of type ascription, albeit more flexible.

http://books.google.ro/books?id=ti6zoAC9Ph8C&printsec=frontcover&source=gbs_ge_summary_r&cad=0#v=onepage&q=%22ascription%20becomes%20quite%20a%20bit%20more%20interesting.%20It%20is%20often%20called%20casting%20in%20these%20languages%22&f=false

[Naftoli Gugenheim]

That was exactly my point -- that's why people cast null to determine which overload, as Oliver said. :)