I view extends Top
as a better version of extends AnyVal
— there’s a tradeoff in expressivity, but I’d never use AnyVal
. extends Top
or opaque types don’t let you change equals
, but if you want the features of either, you need to switch to typeclass-based equality (not multiversal equality).
Type itself doesn’t, but you still box in generic contexts unless you specialize:
type T = Int // defined type alias T
def foo[U](u: U) = u //foo: [U](u: U)U
foo[T](1) //res0: T = 1 //boxing HERE
A better discussion of what boxes when is in the README for GitHub - hobwekiva/newtypes (@jvican that might help for revisions of the SIP) — I doubt you can improve on the generated code much.
I think that might be a valid and important usability concern about the concrete syntax. Maybe this should be written type Foo(a: Int) extends Top
, newtype Foo(a: Int)
, or yet something else. In all cases, Foo
would extend Top
but not Any
/AnyVal
/AnyRef
.
As long as it’s not forgotten about, this should be discussed separately so that we get the right semantics before bikeshedding the details (Pre-SIP: Unboxed wrapper types - #52 by jvican). And I’m not implying at all concrete syntax doesn’t matter, it’s just harder to discuss.
EDIT: @jvican is the plan to sketch out this proposal before choosing? It can be fine if Martin leaves details as exercises to the reader, but we still need to see the worked out version. I understand parts of the result doesn’t look very different from your earlier document on “newtype classes” ( extends Newtype
), but that’s not clear. Also, details on Top
are spread in a discussion over the Dotty repo that didn’t quite reach a conclusion.