What I’m worried about with this proposal is that this will lead to more ecosystem fragmentation:
There are now two different good ways to make an optional T:
Option[T]T?
Each with different strengths and weaknesses
Even if in a vacuum T? dominates Option[T] in all cases (which it looks like it might), Option[T] still has the benefits of being “old”: more familiar, more widely taught, and present and supported in libraries.
This seems like a very big deal to me!, and I’m a bit surprised by the fact that it wasn’t brought up before(?)
The alternate proposals of SLC: `Conversion[A, Option[A]]` and Pre-SIP: Optional parameters by symetry with varargs don’t suffer from this downside, they both make Option[T] stronger, making it the best option in more cases
This leads to less choices for our users to make, which we should strive for
Furthermore, if the syntactic clarity is what we want, we can adopt one of the above and:
type T? = Option[T]
type T ? E = Either[E, T]
(meta: it’s also not quite clear if T ? E is part of this Pre-SIP, or only T?)
As for the unboxing aspect, it’s super cool (honest), but is this something we really need ?
I remember seeing people saying the performance impact of boxing Option was minimal, is it worth splitting the ecosystem for ?
In conclusion, I really believe if we were building Scala from scratch, this proposal would have been perfect: It’s clean, efficient, reduces boilerplate, and feels very Scala-y.
But Scala is already here, and it already has Option, which is already 99% good, and it even still has available ways to improve !