Support String interpolator inline `unapply`

[nicolasstucki]

To write a string interpolator with an apply and unapply. Both could be macros.

old code

In Scala 2 we would have written

implicit class XOps(s: StringContext) {
  object x {
    def apply(exprs: Any*) = macro ...
    def unapplySeq(...) = macro ...
  }
}

Possible encoding

A possible encoding in Dotty is

object XOps {
  opaque type StringContext = scala.StringContext
  def apply(sc: scala.StringContext): StringContext = sc
}
extension (inline ctx: StringContext) inline def x: XOps.StringContext = XOps(ctx)
extension (inline ctx: XOps.StringContext) inline def apply(inline exprs: Any*) = ${ ... }
extension (inline ctx: XOps.StringContext) inline def unapplySeq(...) = ${ ... }

This encoding ensures that both the StringContext and arguments are inlined and accessible by the macro.

The apply can work out of the box for x"...", even with a macro (see #8572).

But unapply is not taken into account, even without macros.

expectation

object XOps {
  opaque type StringContext = scala.StringContext
  def apply(sc: scala.StringContext): StringContext = sc
}
extension (inline ctx: StringContext) inline def x: XOps.StringContext = XOps(ctx)
extension (inline ctx: XOps.StringContext) inline def unapplySeq(arg: Any) = None

def test = 
  ??? match 
    case x"$a" => 

should compile.

Detailed description of the Semester project

Problem

We want to implement string interpolation extractors using macros:

def processSqlQuery(query: String) =
  query match
    case sql"select $col from $table" => println(s"You are selecting $col from $table")

The problem is that the old, Scala 2, encoding involves passing StringContext, which is an argument to the implicit class, to the macro that implements the extractor. We need to pass StringContext because it contains all the information on the string being extracted, and the macro needs that information to be useful. However, being a constructor argument to a class, StringContext is not statically known. Hence, it cannot be passed to a macro since being statically known is a requirement for (inlined) macro arguments.

Solution

Investigate possible encodings for the string interpolator macro-based extractors. The output of the project will be a report on the encodings investigated and why they can or cannot be used. Ideally, if a good solution is found, you can also implement it as part of the semester project, but this is not mandatory.

[nicolasstucki]

Requires #8530

[nicolasstucki]

And requires lampepfl/dotty-feature-requests#112 (or a fix targeted to sting interpolators)

[odersky]

This would mean we need to allow unapply as an extension method.

[dwijnand]

This would mean we need to allow unapply as an extension method.

For general unapplies, I mean when used with a match it seems to work already:

class Foo(val x: Int, val y: Int)
object Foo { val default = new Foo(0, 0) }

extension (F: Foo.type) def unapply(x: Foo): (Int, Int) = (x.x, x.y)

@main def test(): Unit = new Foo(2, 3) match
  case Foo(x, y) => println(x + y)

$ scala -3.head foo.scala
5

[nicolasstucki]

Another idea would be to allow extension modules to give prefixes to extension methods.

extension (inline sc: StringContext) object x:
  inline def apply(elems: Any*) = ...
  inline def unapplySeq() = ...

Those objects can only contain methods and can not extend anything.

Not sure how this would be encoded.

// in a patten
x"abc$d"
// is desugarred as 
StringContext("abc").x.apply(d) 
// is typed as 
x.apply(StringContext("abc"))(d)

It should end up desugared into something like this probably.

object x:
  inline def apply(inline sc: StringContext)(elems: Any*) = ...
  inline def unapplySeq(inline sc: StringContext)() = ...