This page is no longer maintained — Please continue to the home page at www.scala-lang.org

auto boxing, no auto unboxing, why?

2 replies
extempore
Joined: 2008-12-17,
User offline. Last seen 35 weeks 3 days ago.

I assume there's some good reason for the way things are, but I can't
figure out what it is, so. We have these:

implicit def byte2Byte(x: Byte) = java.lang.Byte.valueOf(x)
implicit def short2Short(x: Short) = java.lang.Short.valueOf(x)
implicit def char2Character(x: Char) = java.lang.Character.valueOf(x)
implicit def int2Integer(x: Int) = java.lang.Integer.valueOf(x)
implicit def long2Long(x: Long) = java.lang.Long.valueOf(x)
implicit def float2Float(x: Float) = java.lang.Float.valueOf(x)
implicit def double2Double(x: Double) = java.lang.Double.valueOf(x)

We do not have these:

implicit def Byte2byte(x: java.lang.Byte): Byte = x.byteValue
implicit def Short2short(x: java.lang.Short): Short = x.shortValue
implicit def Integer2int(x: java.lang.Integer): Int = x.intValue
implicit def Long2long(x: java.lang.Long): Long = x.longValue
implicit def Float2float(x: java.lang.Float): Float = x.floatValue
implicit def Double2double(x: java.lang.Double): Double = x.doubleValue
implicit def Character2char(x: java.lang.Character): Char = x.charValue

Why is this?

Often I can figure out why something is or isn't by making the change
and letting the compiler loose, but the monkeys stayed in the barrel
this time. The only change I can see is that instead of this:

scala> val x: Int = new java.lang.Integer(5)
:5: error: type mismatch;
found : java.lang.Integer
required: Int
val x: Int = new java.lang.Integer(5)
^

We get this:

scala> val x: Int = new java.lang.Integer(5)
x: Int = 5

Which seems kind of better from over here in naiveland.

odersky
Joined: 2008-07-29,
User offline. Last seen 45 weeks 6 days ago.
Re: auto boxing, no auto unboxing, why?

Originally we did not intend to do auto-boxing nor auto-unboxing
to/from Integer. That was before structural types came sometimes in
2.6.x. In earlier versions, there was a class runtime.BoxedInt which
was different from Integer and not accessible to users. Structural
types demanded that BoxedInt became Integer and with it we got
autoboxing.

So in short, the question was never considered properly whether we
should also go the other way.

Cheers

extempore
Joined: 2008-12-17,
User offline. Last seen 35 weeks 3 days ago.
Re: auto boxing, no auto unboxing, why?

On Mon, Aug 23, 2010 at 09:46:53AM +0200, martin odersky wrote:
> So in short, the question was never considered properly whether we
> should also go the other way.

Great! When I bring up old stuff I always expect to get shot down, but
hearing "was never considered properly" once in a while makes it all
worth it.

So martin's reply is pretty neutral, but I'd say based on the currently
available info we should do it. So if anyone anticipates some issue
this might cause, please share.

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland