Status of unboxed `Option` type

Scala Standard Library
#1

In 2018 there was talk about adopting an unboxed Option type for Dotty/Scala 3. Sébastien worked on it then. References:

It seemed like this was working and that some incomplete performance tests were done, and then… nothing. Is there a reason besides manpower not to continue working on this?

From a performance (hopefully) and marketing perspective, being able to say that we have an Option type that doesn’t box would be a positive. You would also be able to tell beginners (and not so beginners) not to fear Option because it has no runtime cost (at least for reference types).

Related: Pre-SIP: Unboxed wrapper types

7 Likes
#2

Any comment, maybe @sjrd?

#3

I guess nobody wanted it enough to push it before Scala 2.13 was released. Since then, we’re stuck with the binary API of the Scala 2.13 library, so there’s nothing we can do anyway.

#4

Thanks. Couldn’t/wouldn’t the binary API remain the same? I would have expected the change to be transparent if this was to be a replacement for Option (as opposed to a separate UOption).

#5

No, the erasure is, by necessity, different. Option[T] erases to Option, but UOption[T] erases to Object. It must do so in order to be able to store a None, a WappedNone or T.

1 Like
#6

Like this: Opt? There is also a @specialized variant if you are as undecided as me. It’s Scala 2, when I finally sit down to do a Scala3 fork, the former will become a newtype instead of a value type, although it will lose the distinction between Some^n(x) for n>1.

I wasn’t aware anyone else was interested, and considering the number of ‘premature optimisation is the root of all evil’ responses I get to about every question, I didn’t bother to advertise, especially that at one point Option actually was erased to Any, so didn’t think a move back would be even considered, especially that a no-alloc Option comes with quite a few caveats which might be too subtle for inexperienced learners.