Singleton subtyping, and can we mark scala.Singleton as experimental?

[joshlemer]

Just to try to draw out something actionable before diving further into alt-designs, do we all agree that the current incarnation of Singleton as an upper bound should be marked experimental for the 2.13 release, while these alt-designs cook?

[soronpo]

That’s part of SIP23 which was approved (and already used is some projects). Personally, I would rather any changes in this concept are passed through a SIP process, including a deprecation/language flag.

[smarter]

@joshlemer

Just to try to draw out something actionable before diving further into alt-designs, do we all agree that the current incarnation of Singleton as an upper bound should be marked experimental for the 2.13 release, while these alt-designs cook?

I’m not sure what’s special about 2.13 here, scala.Singleton has existed and has had this behavior since before 2.13.

[joshlemer]

@kai

scala.Singleton is not new though. It already exists, and is rather widely used (in scala-reflect API at least)

@smarter

scala.Singleton has existed and has had this behavior since before 2.13.

wow, I did not know this, sorry folks

[adriaanm]

Or even bolder! Explicit kinds (sneaking them in through a magic context bound?)

def foo[T: Kind[Singleton]](t: T) = ...

[kevinwright]

I do like the idea of a magic context bounds, it’s the closest I’ve seen to Miles’ desire for a general purpose elaboration mechanism.

I recant my idea of a caret in the same position as +/- and instead give you… elaboration bounds

def foo[T ^ Singleton](t: T) = ... 

Just as bold, but slightly less magical.

Given how commonly ^ is used for higher-kinded multiplication (a.k.a exponentiation), I like how the intuition works on this.

[kevinwright]

@milessabin

The scalac plugin API uses trailing annotations … see the CPS plugin, for example.

CPS did that for return types, for type parameters (e.g. @specialized) it’s a prefix.

[smarter]

@kevinwright

Just as bold, but slightly less magical.

I’m not sure, if the only way to define an “elaboration bound” is by hardcoding its behavior in the compiler, then the syntax you propose doesn’t seem any better than using a keyword for each hardcoded behavior, and it raises more questions, like what’s Singleton ? Is it a type ? If so, what are the values of this type ? etc.