extends Top as a better version of
extends AnyVal — there’s a tradeoff in expressivity, but I’d never use
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 https://github.com/alexknvl/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
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). 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.