Support literal opaque types

[armanbilge]

This is a follow-up to:

• inline val for opaque type alias for literal type 'must have a literal constant type' #13851
• inline val for opaque type alias for literal type is 'declared as erased, but is in fact used' #13852
• Detect opaque aliases in inline val types #13857

The workaround suggested there is to use an inline def instead of an inline val, but it's instability prevents it from being helpful for pattern matching against etc.

Would it be possible to have an opaque type that is known to be an alias to a type literal?

For an example use-case see:

• Make constants inline val? scala-js/scala-js-dom#618

[LPTK]

Would it be possible to have an opaque type that is known to be an alias to a type literal?

What is a type literal? Do you mean a literal type? If it was known to be an alias of such type, the opaque type wouldn't be opaque at all.

Can't you just use a normal val?

[armanbilge]

Thanks for the reply. Apologies, I do mean a literal type. e.g. val one: 1 = 1.

If it was known to be an alias of such type, the opaque type wouldn't be opaque at all.

With the caveat that I have little theoretical understanding of such things: I have hard time buying this. I don't see why a type can't be both opaque and known to be a literal. Just, an opaque literal :)

Can't you just use a normal val?

Sure, but ideally it would be inlined :) To restate the example I linked to above:

opaque type AppendMode <: String = String

object AppendMode {
  val segments: AppendMode = "segments"
  val sequence: AppendMode = "sequence"
}

This is for the scala-js-dom library, where AppendMode is a String-based enum from the DOM:
https://developer.mozilla.org/en-US/docs/Web/API/SourceBuffer/mode

Here we are using an opaque type for the type safety it provides, but would prefer if the underlying value was inlined at the use-site. In Scala.js in particular, where SJSIR class files are statically linked before generating JS code, inlining would be much more amenable dead-code-elimination, etc.

If that's not motivation enough ... here's another example from one of my own libraries:

opaque type LogDouble = Double

object LogDouble:
  val Zero: LogDouble = Double.NegativeInfinity
  val One: LogDouble = 0.0
  val Two: LogDouble = 0.6931471805599453
  val MinPositiveValue: LogDouble = Double.MinValue
  val MaxValue: LogDouble = Double.MaxValue
  val PositiveInfinity: LogDouble = Double.PositiveInfinity
  val NaN: LogDouble = Double.NaN

This is part of an implementation of the Log semiring:
https://en.wikipedia.org/wiki/Log_semiring

Here, the opaque type is an extremely valuable tool, because it allows us to redefine the * operator as addition of the underlying Double values (since log-scaled numbers are multiplied by adding them), etc.

However, it would be ideal if the use of LogDouble.One could inline 0.0 at the call site, rather than dispatch a method call to getter for that val. Apologies if I'm being dense here ... but this doesn't seem unreasonable?

[LPTK]

With the caveat that I have little theoretical understanding of such things: I have hard time buying this. I don't see why a type can't be both opaque and known to be a literal. Just, an opaque literal :)

The problem is that inline val already has a specific semantics, which requires it to have a known (even from the outside) literal type. There is just no way of reconciling this with hiding the actual type of the val.

(I do think the special semantics given to inline val is strange and slightly icky, but that's what it is.)

What you want is a inline def that also has the stability of a val. You do not actually want or need opaque literal types.

You can easily find workarounds though. Here is one:

object lib:
  opaque type AppendMode <: String = String

  class Wrap(am: AppendMode) extends AnyVal:
    inline def unapply(s: String): Boolean = am == s

  extension (self: AppendMode) inline def test: Wrap = Wrap(self)

  object AppendMode {
    inline def segments: AppendMode = "segments"
    inline def sequence: AppendMode = "sequence"
  }

def test(x: String) = x match
  case lib.AppendMode.segments.test() => "ok"
  case _ => "ko"

test(lib.AppendMode.segments) // "ok"

The Wrap class is needed because String already defines an unapply method. Otherwise we could make the syntax just case lib.AppendMode.segments() => .... But Wrap should not incur overhead as it's value class (extends AnyVal).

[armanbilge]

What you want is a inline def that also has the stability of a val. You do not actually want or need opaque literal types.

Yes, exactly. Well put, thanks.

The problem is that inline val already has a specific semantics, which requires it to have a known (even from the outside) literal type. There is just no way of reconciling this with hiding the actual type of the val.

That's fair, thank you for explaining. IIUC the other important assumption here is that the set of literal types is fixed, and can't be extended?

Finally, I appreciate the example, but if you'll forgive me saying so, that looks ... not nice 😆 from a UX pov anyway. Also I thought AnyVal is a deprecated/discouraged thing in Scala 3 :)