Opaque types and inline defs limitation

[soronpo]

Tried to use opaque types to create a compile time constrained Positive integer type:

import compiletime._

opaque type Positive = Int
object Positive {
  inline def apply(inline value : Int) : Positive = {
    inline if (value <= 0) error(code"failed on: $value")
    else value
  }
}

val eight = Positive(8)
val negError = Positive(-1) //expect error here

Unfortunately I got the error Implementation restriction: No inline methods allowed where opaque type aliases are in scope.

Please remove this restriction.

[odersky]

This will be next to impossible to achieve. Opaque types rely on location for type-checking. Inline methods rely on moving code to the caller. I see no way to (re-)typecheck inlined code at the call site and at the same time keep typing as if it was at the original location.

[kwark]

Does this mean refinement types are next to impossible with scala3? At least using opaque types?

[soronpo]

Does this mean refinement types are next to impossible with scala3? At least using opaque types?

They will be possible, but via literal-type operations. We just need to add an Error type for this purpose. See scala/scala3#7951

[neko-kai]

@kwark You could potentially move your inlines to where opaque type are not visible:

package example
type X = x.X
object X { 
  inline def apply ...
  private[example] object x {
    opaque type X
  }
}

[letalvoj]

Following @neko-kai example, since the desired behaviour can be achieved by introducing an extra scope which hides the opaque type, would it be possible to use a simmilar approach internally in the compiler?

I can easily see programmers failing on this particular feature while implementing their own refined types.

[gabfssilva]

I came up with:

import scala.compiletime.*

opaque type Positive = Long

object Positive extends PositiveRefined:
  private[refined] def unsafe(input: Long): Positive = input

trait PositiveRefined:
  def safe(v: Long): Positive | IllegalArgumentException =
    if v >= 0 then Positive.unsafe(v)
    else IllegalArgumentException("value must be >= 0")

  inline def refine(inline v: Long): Positive =
    if v >= 0 then Positive.unsafe(v)
    else error("value must be >= 0")

And, to use it:

val positive: Positive = Positive.refine(1) //compiles just fine
val negative: Positive = Positive.refine(-1) //compilation error: value must be >= 0

val runtimeLong = 10L

Positive.safe(runtimeLong) match
  case p: Positive => ???
  case e: IllegalArgumentException => ???

AFAIK no boxing is being made at runtime whatsoever if we use the refine method

[soronpo]

@gabfssilva
FYI, this workaround will soon be disallowed: scala/scala3#12815

[gabfssilva]

After this PR, the other way around would be this:

opaque type Positive = Long

object Positive:
  private[refined] def unsafe(input: Long): Positive = input

object PositiveRefined:
  def safe(v: Long): Positive | IllegalArgumentException =
    if v >= 0 then Positive.unsafe(v)
    else IllegalArgumentException("value must be >= 0")

  inline def refine(inline v: Long): Positive =
    if v >= 0 then Positive.unsafe(v)
    else error("value must be >= 0")

and then, instead of Positive.refine, we'd use: PositiveRefined.refine.

[odersky]

Good news: Once scala/scala3#12815 is merged, the restriction will be lifted. So no workarounds are needed anymore.

[soronpo]

Thank you so much Martin! It's nice to see a PR going from more restriction to no restriction at all 👍

[johnynek]

Thank you so much for the work on this @odersky! I think opaque type and inline def go together pretty naturally. Also it's awkward to have language features that don't compose. I think this simplifies the teaching of scala 3.

[soronpo]

Fixed by scala/scala3#12815