"Tagged" Transparent New-Types are a distinct use-case that would benefit from mention in the documentation imho

[benhutchison]

Please interpret my suggestions in the context of the New Types section of the docs. (I ❤️ Iron BTW... totally agree why refined types are so important and useful. And Iron is honestly, significantly more usable than Refined used to be).

The problem: The docs speak as though there are two distinct use-case scenarios for new types, which correspond roughly to transparent vs opaque type aliases. They present an example, copied below ,to motivate the second, opaque type-based solution, describing it as to "avoid mixing different domain types with the same refinement".

opaque type Temperature = Double :| Positive
object Temperature extends RefinedTypeOps[Double, Positive, Temperature]

opaque type Moisture = Double :| Positive
object Moisture extends RefinedTypeOps[Double, Positive, Moisture]

case class Info(temperature: Temperature, moisture: Moisture)

val temperature: Temperature = ???
val moisture: Moisture = ???

Info(moisture, temperature) //Compile-time error

The problem is that it is possible to achieve this separation using transparent aliases only, no opaque types (Scastie). The docs currently advocate an opaque-type solution that also prevents upcasts to the base type, which brings additional complexity and is often not desired.

The key is to "tag" each refinement with a unique string that establishes a separate subtype, yet still within the base type.

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

type Tagged[S <: String] = DescribedAs[True, S]

type Temperature = Double :| (Positive & Tagged["Temperature"])
object Temperature extends RefinedTypeOps.Transparent[Temperature]

type Moisture = Double :| (Positive & Tagged["Moisture"])
object Moisture extends RefinedTypeOps.Transparent[Moisture]

val t = Temperature(2)
val m = Moisture(2)

def tempAndMoisture(t: Temperature, m: Moisture) = ()
tempAndMoisture(t, m)
tempAndMoisture(m, t) //Won't compile. Cannot mixup Temperature and Moisture

def num(n: Double) = ()
num(t); num(m) //But upcasts OK

The way I think about it is illustrated below. There are three distinct cases:

• Transparent aliases without tags permit both the Upcast and Cross-cast arrows
• Transparent aliases with tags permit the Upcast but not Cross-cast arrow
• Opaque aliases permit neither the Upcast nor the Cross-cast arrow

A problem I perceive atm in Scala 3 codebases generally is a lot of (IMO over-)use of opaque types when people just want the capabilities of transparent aliases, with tags. Please consider mentioning this option in the documentation 🙏 😄

[Iltotore]

Hello!

The key is to "tag" each refinement with a unique string that establishes a separate subtype, yet still within the base type.

How about opaque type Temperature <: Double = ...? For example this works:

opaque type Temperature <: Double = Double :| Positive
object Temperature extends RefinedTypeOps[Double, Positive, Temperature]

opaque type Moisture <: Double = Double :| Positive
object Moisture extends RefinedTypeOps[Double, Positive, Moisture]

val temperature: Temperature = Moisture(10) //Does not compile
val n: Double = Moisture(10) //Compiles

[benhutchison]

Right, yes, that works and doesn't need to add a Tagged["Temperature"].

Also, the subtype bound can include a refinement, eg

opaque type Moisture <: Double :| Positive = Double :| Positive

To me, the tagging style appears more uniform however, in that it uses the Iron Constraint mechanism for all type distinctions.

Whereas, the opaque modifier here acts to make the IronType "disagreeable", ie won't be equal to any other type that has the same bound. It's like part of the overall refinement is implemented by a different mechanism, opacity.

In this example, we see some confusing behavior if ever we try to mix opaque and transparent refinements.

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

object scope:
  opaque type Temperature <: Double :| Positive  = Double :| Positive
  object Temperature extends RefinedTypeOps[Double, Positive, Temperature]

  opaque type Moisture <: Double :| Positive = Double :| Positive
  object Moisture extends RefinedTypeOps[Double, Positive, Moisture]

  type Pressure = Double :| Positive
  object Pressure extends RefinedTypeOps.Transparent[Pressure]

import scope.*
val temperature: Temperature = Moisture(10) //Does not compile
val n: Double = Moisture(10) //Compiles
val n2: Double :| Positive = Moisture(10) //Compiles
val p: Pressure = Moisture(10) //Compiles
val m: Moisture = Pressure(10) //Does not compile

Also, I noticed the section on Typeclass Derivation where it says "Usually, transparent type aliases do not need a special handling for typeclass derivation as they can use the given instances for IronType. However, this is not the case for opaque type aliases".

Actually, I realise I'm not 100% clear on when typeclass derivation doesn't work on opaque types... would transparent+tag work better in this aspect?

[Iltotore]

Actually, I realise I'm not 100% clear on when typeclass derivation doesn't work on opaque types... would transparent+tag work better in this aspect?

Assume a typeclass like this:

trait Foo[A]:
  ...

given fooDoublePos: Foo[Double :| Positive] = ???

If I define a newtype like this:

type Temperature = Double :| Positive
...

Then fooDoublePos will be used when summoning a Foo[Temperature]

But if Temperature is opaque, (and does not have <: Double :| Positive) then it is considered a totally different type (which is the expected behaviour) so fooDoublePos is not a Foo[Temperature] (because outside of the definition scope, Temperature and Double :| Positive have nothing in common), hence the need for RefinedTypeOps.Mirror to easily derive instances for opaque newtypes.

[benhutchison]

Thanks, makes total sense 🙏

[benhutchison]

Actually, I have found another, imo compelling, apparent reason why Opaque Aliases with a Bound (eg opaque type Moisture <: Double :| Positive = Double :| Positive) are preferred over Transparent Aliases with a Tag (eg type Moisture = Double :| (Positive & Tagged["Moisture"]))

The problem with transparent aliases is that they don't seem to have a companion object. After all, they are not a distinct type, just a reference to another type. Without a companion object, it is not possible to user-define extension methods for the refined type. The way I use tagged refined types, this is a major limitation.

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

type Tagged[S <: String] = DescribedAs[True, S]

object scope:
  opaque type Moisture <: Double :| Positive = Double :| Positive
  object Moisture extends RefinedTypeOps[Double, Positive, Moisture]:
    extension (m: Moisture)
      def foo = "foo"

  type Pressure = Double :| (Positive & Tagged["Pressure"])
  object Pressure extends RefinedTypeOps.Transparent[Pressure]:
    extension (p: Pressure)
      def foo = "foo"
     

import scope.*
Moisture(10).foo
Pressure(10).foo //Won't compile, extension not resolved

scastie

A mystery is, is that lineobject Pressure extends extends RefinedTypeOps.Transparent[Pressure] actually relying on object Pressure being a companion in Scala sense? I suspect not.. Perhaps it is just creating constructor methods for Pressure but not relying on Implicit Scope of Pressure (as extension methods do).