Add reflect MatchCase TypeRepr

[nicolasstucki]

This represents the MATCHCASEtype type in TastyFormat and hides the scala.runtime.MatchCase internal encoding.

This is an alternative to #10690

[abgruszecki]

I'm not certain how I feel about this. In comparison to the other PR, it seems to still have the following issues:

1. It exposes the MatchCase tycon, while there's no real need to expose it to users of Reflect
2. It requires Reflect users to understand internal MatchType structure, in particular it gives zero idea to someone who reads the API on how to destruct MatchType and how to construct it
3. Compared to master API, it still has the effect of potentially forcing us to freeze MatchType internals, if the ecosystem starts depending on them by constructing/destructing MatchTypes in staging

OTOH, if I consider how we expose pat-mat patterns in Reflect, this approach seems analogous.

[nicolasstucki]

We discussed it with @odersky and @OlivierBlanvillain and come to the conclusion that this was the best approach.

It exposes the MatchCase tycon, while there's no real need to expose it to users of Reflect

This is precisely what we need to expose at it is the concept that is in the TASTy spec

It requires Reflect users to understand internal MatchType structure, in particular it gives zero idea to someone who reads the API on how to destruct MatchType and how to construct it

That is true for any feature in the reflect API. Now that documentation mentions the expected shapes of types.

Compared to master API, it still has the effect of potentially forcing us to freeze MatchType internals, if the ecosystem starts depending on them by constructing/destructing MatchTypes in staging

No, now we only depend on the MATCHCASEtype abstraction in the TASTy format and not on the internal encoding details with scala.runtime.Match. This gives us full flexibility to change its internal encoding without breaking the ecosystem.

[abgruszecki]

It requires Reflect users to understand internal MatchType structure, in particular it gives zero idea to someone who reads the API on how to destruct MatchType and how to construct it

That is true for any feature in the reflect API. Now that documentation mentions the expected shapes of types.

That's a fair point in the sense that the Reflect API is supposed to be low-level and not often used, but I think this is far less true for most features of Reflect than it is for match type cases. I'd expect that there are already a lot of people out there that understand that source code is represented as trees, which gets you 95% to understanding how to use most of Reflect. In contrast, we encode information in the shape of match trees in Scala3-specific way. Somebody who sees the Reflect API for the first time will have absolutely no idea how match cases are represented.

I guess good documentation is one way of dealing with this.

Compared to master API, it still has the effect of potentially forcing us to freeze MatchType internals, if the ecosystem starts depending on them by constructing/destructing MatchTypes in staging

No, now we only depend on the MATCHCASEtype abstraction in the TASTy format and not on the internal encoding details with scala.runtime.Match. This gives us full flexibility to change its internal encoding without breaking the ecosystem.

I don't understand this, are you saying that we will be free to modify what the reference to scala.runtime.MatchCase is? What seems to me much more important is that we can change the shape of patterns without breaking staging code, which this PR does not accomplish. I guess the API for term patterns has the exact same issue, but we've had much more experience with that representation.

[OlivierBlanvillain]

I agree that it's unfortunate that MatchCase leaks all the way to the user, but if this is how Tasty reflect is designed, i.e., to reflect the internal representation of trees and types, then we have to roll with it for now.

The diff LGTM.