Mirror.ProductOf instance for Value class

[cchantep]

For now, Value classes are not provided Mirror.ProductOf instances.

Something as below could be used.

  transparent inline def valueClassProduct[
      T <: AnyVal
    ]: Mirror.Product with Mirror.ProductOf[T] = ${ valueClassProductImpl[T] }

  private def valueClassProductImpl[T: Type](
      using
      q: Quotes
    ): Expr[Mirror.Product with Mirror.ProductOf[T]] = {
    import q.reflect.*

    val tpr = TypeRepr.of[T]

    if (defn.ScalaPrimitiveValueClasses.contains(tpr.typeSymbol)) {
      report.errorAndAbort(s"Cannot derive primitive value class: ${tpr.show}")
    }

    // ---

    val tprSym = tpr.typeSymbol
    val ctor = tprSym.primaryConstructor

    type IsString[U <: String] = U

    ctor.paramSymss match {
      case List(v: Symbol) :: Nil =>
        v.tree match {
          case vd: ValDef => {
            (
              ConstantType(StringConstant(tprSym.name)).asType,
              vd.tpt.tpe.asType,
              ConstantType(StringConstant(v.name)).asType
            ) match {
              case (
                    '[IsString[label]],
                    '[fieldType],
                    '[IsString[fieldLabel]]
                  ) =>
                type ProductOfValue = Mirror.ProductOf[T] {
                  type MirroredType = T
                  type MirroredMonoType = T

                  type MirroredLabel = label
                  type MirroredElemTypes = Tuple1[fieldType]
                  type MirroredElemLabels = Tuple1[fieldLabel]
                }

                '{
                  (new Mirror.Product {
                    type MirroredType = T
                    type MirroredMonoType = T

                    type MirroredLabel = label
                    type MirroredElemTypes = Tuple1[fieldType]
                    type MirroredElemLabels = Tuple1[fieldLabel]

                    def fromProduct(p: Product): MirroredMonoType = ???
                  }): ProductOfValue
                }
            }
          }

          case term =>
            report.errorAndAbort(
              s"Value class is expected to have a single field: ${term.show}"
            )
        }

      case args =>
        report.errorAndAbort(
          s"Value class is expected to have a single field: ${args mkString ", "}"
        )
    }
  }

Usage:

final class Bar(val value: String) extends AnyVal

valueClassProduct[Bar]
// defined class Bar
val res0: 
  deriving.Mirror.ProductOf[Bar]{
    MirroredType = Bar; MirroredMonoType = Bar; MirroredLabel = "Bar"; 
      MirroredElemTypes = Tuple1[String]
    ; MirroredElemLabels = Tuple1["value"]
  } = anon$1@4b8832f9

[Lasering]

Instead of using value classes why not use opaque types?

[cchantep]

Instead of using value classes why not use opaque types?

Both are supported, so derivation should be available for both.

[Lasering]

Yes it should be available for both. I was not trying to say otherwise.

Opaque types have the guarantee of no overhead, value classes don't because some times there is boxing involved. The way I see it is: you will eventually have to migrate to opaque types why not migrate right now and benefit from no overhead and support for Mirrors?

[cchantep]

This rationale of asking people to migrate all value classes to opaque types could make sense in the end ... Could ... But not sure ... Otherwise value classes would have been removed or at least been deprecated.

Anyway, that's not a good strategy to me to ask to migrate all the value classes whereas that's quite easy to have derivation for.

[Lasering]

From Scala 3 Overview

Value classes (superseded by opaque type aliases) are a special case. There are currently no deprecation plans for value classes, since we might bring them back in a more general form if they are supported natively by the JVM as is planned by project Valhalla.

[SethTisue]

Value classes also remain relevant when cross-building for Scala 2 and 3.

[WojciechMazur]

The topic of Mirrors for value classes was discussed today in the Scala 3 Core meeting.
Despite the usefulness of this feature, it was concluded that currently, we would not work on this feature. The reasoning for this decision was the fact that value classes are a difficult construct, both to maintain and extend, having multiple corner cases and special handling in different parts of the compiler. The compiler team does not have sufficient resources to deliver and test the generation and interaction of mirrors with different parts of the compiler, unless there is founding dedicated explicitly to this goal (original value classes were delivered based on the founding from a private company).

At the same time, the team is considering working on the Mirrors/derivation mechanism for the opaque types in the future. We do encourage you to discuss on the existing Pre-SIP for opaque types derivation