Automatic conversion from uncostrained type no longer works in Scala 3.1.1 about iron

[mcallisto]

Thank you for all the replies, I see your point.
I am not able to give a sound opinion right now, I will try to experiment a little more in depth.

[Iltotore]

Hello.
Scala 3.1.1 introduced some inline/type-inference bugs fixed in 3.1.2. Can you test Iron with this version ?

Your code works if we specify Int > 0 in your pow method. Since we cannot prove that Int is a Int > 0 at compile-time, Iron tries to use the compile-time value of z but Scala 3.1.0 restrained this behaviour to only fully inlined values.

Iron will receive a major release around this summer which will forbid this manipulation in profit of a more explicit fully safe refined type system.

To fix this issue, simply specify Int > 0 instead of Int for z in pow.

Also note since Iron 1.2.0, you can simplify your code into (Scastie):

import io.github.iltotore.iron.{*, given}
import io.github.iltotore.iron.constraint.{*, given}
import io.github.iltotore.iron.numeric.constraint.{*, given}

def mult(x: Int > 0, y: Int > 0): Raw[Int] = refined {
  x * y
}

def pow(z: Int > 0): Raw[Int] = mult(z, z)

pow(5)

[mcallisto]

Tried now on Scastie with 3.1.2 RC1 and the error seems to stay the same.

Specifying Int > 0 is of course doable, but this manipulation kept the code simpler, no need to propagate the constraint.

[Iltotore]

Specifying Int > 0 is of course doable, but this manipulation kept the code simpler, no need to propagate the constraint.

I dont think this explicitation is redundant. Also note it ensures the algebraic consistency of the program/method without depending on the call itself (while your example might not work if the passed argument is unknown at compile time). In fact, forcing this explicitation makes refined types behaving like "normal" Scala types.

Anyway, I am still open to discussion and suggestions about this topic.