Scala 3.3.0: RefinedTypeOps members not visible outside module containing definition

[ajaychandran]

Describe the bug
Scala environment: JVM/Scala.JS/ScalaNative
Scala version: 3.3.0
Iron version: 2.1.0-3-69fb90-SNAPSHOT

Reproduction steps
Given the following new type:

package xxx

import io.github.iltotore.iron.*

opaque type Answer = String :| (StrictEqual["yes"] | StrictEqual["no"])
object Answer extends RefinedTypeOps[Answer]

val a = Answer("yes") // compiles when in same file

Moving the last line to a different file results in a compilation error:

object Answer in package xxx does not take parameters

Expected behavior
Compilation success.

Current behavior
Compilation failure.

[Iltotore]

It compiles for me:

refinedtypeops.scala

import io.github.iltotore.iron.*
import io.github.iltotore.iron.constraint.all.*

opaque type Answer = String :| (StrictEqual["yes"] | StrictEqual["no"])
object Answer extends RefinedTypeOps[Answer]

refinedtest.sc

//> using scala "3.2.2"
//> using repository "sonatype:snapshots"
//> using lib "io.github.iltotore::iron:2.1.0-3-69fb90-SNAPSHOT"
//> using file "refinedops.scala"

val a = Answer("yes")
println(a)

Tested with Scala 3.2.2 and 3.3.0.

EDIT: After cleaning the cache, it looks like Scala 3.3.0 has a regression on inline methods.

[Iltotore]

It seems that in Scala 3.3, imports got a bit stricter. This code works on both 3.2.2 and 3.3.0:

import io.github.iltotore.iron.*
import io.github.iltotore.iron.constraint.all.*

opaque type Answer = String :| (StrictEqual["yes"] | StrictEqual["no"])
object Answer extends RefinedTypeOps[Answer]

//> using scala "3.3.0"
//> using repository "sonatype:snapshots"
//> using lib "io.github.iltotore::iron:2.1.0-3-69fb90-SNAPSHOT"
//> using file "refinedops.scala"
//> using file "refinedfile.scala"

//You need to import the associated constraints in Scala 3.3.0
import io.github.iltotore.iron.constraint.all.*

val a = Answer("yes")
println(a)

Hope that helps.

However, the error message you got is unclear and is probably a bug from Scala 3.3. Fortunately the workaround is simple.

[ajaychandran]

My project consists of multiple modules built using Mill.
The compilation error only occurs when making the call from a different (dependent) module. That is, calls compile when made from a file in the same module.

//You need to import the associated constraints in Scala 3.3.0
import io.github.iltotore.iron.constraint.all.*

This did not work.

Will investigate further.

[Iltotore]

I will try to test it in two separated modules. Honestly it looks like a bug from Scala 3.3 to me since this "from dependent module" configuration is already tested in 3.2.2 in the test module.

[ajaychandran]

I will try to test it in two separated modules. Honestly it looks like a bug from Scala 3.3 to me since this "from dependent module" configuration is already tested in 3.2.2 in the test module.

Yep, downgrading to 3.2.2 resolved the issue.

[Iltotore]

Linked issue: scala/scala3#17984

[Iltotore]

A workaround for Scala 3.3 is to use RefinedTypeOpsImpl (a bit more boilerplate) instead of RefinedTypeOps when using the custom types in another module, until the bug linked above is fixed.

[Zelenya]

I'd like to clarify for others and future me (cause it took me sometime to understand the workaround). This works across modules:

opaque type Answer = String :| (StrictEqual["yes"] | StrictEqual["no"])
// object Answer extends RefinedTypeOps[Answer]
object Answer extends RefinedTypeOpsImpl[String, StrictEqual["yes"] | StrictEqual["no"], Answer]

[Iltotore]

A related issue has been opened on Dotty's repository: scala/scala3#17984 (comment)

This (currently broken) interaction with opaque types will be actually be removed in the future. This will force opaque new types to use RefinedTypeOpsImpl.