Shorthand syntax for opaque subtypes?

Language Design
1

I’ve been playing around with opaque types quite a bit, and I’m frequently hitting the following pattern with them:

opaque type A <: B = B

I was thinking recently that this is probably a common pattern for opaque types that are subtypes. The repetition here bugs me a bit, so I was thinking that maybe just having the subtype bound would suffice as syntatic sugar:

//equivalent to opaque type A <: B = B under the covers
opaque type A <: B

This way of defining opaque types wouldn’t conflict with the current way, because this syntax is currently illegal, and it wouldn’t prevent someone from writing special cases when the opaque type isn’t directly backed by what it’s a subtype of:

opaque type A <:  B 
opaque type C <: Object = B
2

Could be potentially confusing because it looks like you define an abstract opaque type, which is actually illegal. While you can have a non-opaque abstract type type A <: B which not the same thing as type A = B.

1 Like
3

Maybe something like :<= instead. Adding a new operator sucks, but this kind of pattern didn’t exist before in Scala.

4

I’m considering proposing transparent opaque X[T] = T, to mean that, but I also have additional requirements and I wonder if they overlap with your usecase.

1 Like
5

I was going to propose opaque type X[T] extends T

But I’m not sure it’s a good idea, you can put a lot more things after <:/= than you can after extends

6

:<= is a nice moustache and goatee.

<:/= looks like a bird with a / beak. <:/= on my screen the font makes it birdlike.

It’s great to see Scala experience a symbolic renaissance.

1 Like
7

I think we need to try hard not to add sugar that obscures which concepts are actually being employed here. It’s fast enough to read B = B, even if B is actually a big complex type, so this sugar saves more on typing time, which isn’t as important as comprehension

4 Likes