transparent macro : Unexpected loss of refinement

[ftucky]

Compiler version

3.2.2,
3.3.1-RC1-bin-20230328-5c2efc5-NIGHTLY

Minimized code

Transparent Macro:

import scala.quoted.{Quotes,Type,Expr}

// Library part
trait View

// type class
trait ViewOf[M]:
  type Out <: View

object ViewOf :
  transparent inline def whiteMacro[M]: ViewOf[M] = ${whiteMacroImpl[M]}

  def whiteMacroImpl[M:Type](using quotes:Quotes) : Expr[ViewOf[M]]  =
    val res = Type.of[View] match
      case '[tpe] => '{
          new ViewOf[M]:
            type Out = tpe
        }
    
    println(res.show)
    res
  end whiteMacroImpl
end ViewOf

Usage:

whiteMacro[Nothing]

Output

{
  final class $anon() extends refine.ViewOf[scala.Nothing] {
    type Out = refine.View
  }

  (new $anon(): refine.ViewOf[scala.Nothing])
}

Expectation

The returned type is expected to be refined:

{
  final class $anon() extends refine.ViewOf[scala.Nothing] {
    type Out = refine.View
  }

  (new $anon(): refine.ViewOf[scala.Nothing] {
    type Out >: refine.View <: refine.View
  })
}

Observations:

(1) When the upper bound of Out in trait ViewOf[M] is removed, correct behavior is restored:

trait ViewOf[M]:
  type Out

(2) When the type assigned in the anonymous class does not come from the type match, correct behavior is restored:

      case '[tpe] => '{
          new ViewOf[M]:
            type Out = View
        }

(3) When a type ascription is placed on the anonymous class, correct behavior is restored. (thank you, @smarter )

      case '[tpe] => '{
          (new ViewOf[M]:
            type Out = tpe
          ) : ViewOf[M] { type Out = tpe }
        }

More context

https://stackoverflow.com/questions/74549477/scala3-crafting-types-through-metaprogramming/74575615#74575615

[sjrd]

That seems as designed to me, and not related to macros to me. If you manually write such an anonymous class at call site, it will also lose its refinement due to type inference. You would also have to explicitly type is as a refinement to preserve it.

(3) When a type ascription is placed on the anonymous class, correct behavior is restored.

So that is the correct solution (not a workaround).

[bishabosha]

refinements of anonymous classes are only inferred if they derive from scala.Selectable

[ftucky]

OK, then observations (1) and (2) (where refinement of an anonymous class not deriving from Selectable is inferred) are bugs !

[smarter]

What's going on here is a bit subtle:

1. ViewOf has a defined member Out, normally this means that new ViewOf[M] { type Out = ... } should have an inferred type that preserves the refinement. The logic to do this is in https://github.com/lampepfl/dotty/blob/b8d2966e2f45e21f2800cd125ac72d80e5f2cb2a/compiler/src/dotty/tools/dotc/core/TypeOps.scala#L421-L432
2. This works fine when the member of ViewOf is the fully abstract type Out but fails if we add an upper-bound like type Out <: View
3. The reason this fails is that the logic I mentioned above only kicks in if the refinement is a more precise type than the original type. Here, we check that tpe is a subtype of View, but because tpe is fully abstract this fails!
4. Normally, this should lead to a follow-on override error, but this doesn't happen because we don't do override checks inside quotes, see Quotes are not checked for override errors / @deprecated usage / @experimental usage #17400
5. I don't think that we can give tpe a more precise type right now, but once SIP-53 - Quote pattern explicit type variable syntax #17362 is merged we should be able to do:

     case '[type tpe <: View; tpe] => '{
         new ViewOf[M]:
           type Out = tpe
       }

6. Meanwhile, it's possible to work-around this by ascribing a refinement type explicitly:

     case '[tpe] => '{
         (new ViewOf[M]:
           type Out = tpe): ViewOf[M] { type Out = tpe }
       }

   ... or by using an intersection:

     case '[tpe] => '{
         new ViewOf[M]:
           type Out = View & tpe
       }