Scala 3 Macros: Allow dynamic amount of case's in match

[joschua-fink]

Something like this doesn't seem possible at the moment:

// inside macro
val l: List[Type[?]] = ???

'{ foo match {
  ${ l.map{ t => '{ case bar: t.Underlying => } }.reduce { (l, r) => '{ $l $r } } } }
} }

I expect this to be a common pattern occurring in macros, thus the feature request.

I'm also fine with using TASTy Reflect if this proves too difficult to implement. But for that I would welcome some documentation and examples for AST creation. I spent half a day trying to do this with TASTy Reflect to no avail, combing through the API documentation, dotty source code and dotty tests.

[LPTK]

The main difficulty is that you'd have to come up with a type system for this. I don't think anyone has the resources to do that at the moment, so a fully fleshed-out design proposal would have to be made.

[joschua-fink]

You mean since '{ case _: Int => } has no valid type for Expr[?]? I understand that it might be difficult in this case.

In that case my suggestion is to improve on the TASTy Reflect documentation, which I assume is planned anyway. I'm blown away by the capabilities when it comes to analyzing syntax trees, but when it comes to construction of them, I'm struggling at the moment as the documentation is basically non-existent (aside from the minimal generated API documentation).

As example: Trying to do the above in TASTy Reflect, I reverse engineered a quoted expression, but I found no way of constructing a Ident(_), necessary in the Match / CaseDef construct. Dotty itself, looking it its source code seems to have more constructors available, than TASTy Reflect exposes.

[LPTK]

Yes, since the Expr world is statically typed, it is less flexible and much harder to extend with new operations.

In that case my suggestion is to improve on the TASTy Reflect documentation

I agree, I also had some trouble finding how to do things through the current seemingly-incomplete and under-documented API.

[joschua-fink]

I think we can close this issue. A quick search didn't reveal any other issues to improve on the TASTy Reflect API documentation, so it is probably a good idea to open a separate issue as reminder. Is this repository or the main repository a better place for that?