Match types amendment: extractors follow aliases and singletons by smarter · Pull Request #84 · scala/improvement-proposals · GitHub is a proposed amendment to SIP-56 (SIP-56 - Proper Specification for Match Types. by sjrd · Pull Request #65 · scala/improvement-proposals · GitHub) whifh lifts a limitation introduced by the SIP that wasn’t present in Scala 3.3, this limitation severely limits the ability to use match type extractors for extracting type members in a non-obvious way.
The existing text of the spec says that given:
class Base { type Y }
type YExtractor[t] = Base { type Y = t }
We can use case YExtractor[t] => as a valid extractor. However, the actual algorithm defined in the spec precludes us from non-trivial extractions because it doesn’t follow type aliases, so while we can extract Int from:
class Foo extends Base { type Y = Int }
We cannot extract it from:
class Foo extends Base { type Alias = Int; type Y = Alias }
And other more complex patterns.
The proposed spec change updates the algorithm described in the spec without touching the text of the spec to explicitly follow aliases and singleton types. Note that this behavior more closely matches how extraction works for type parameters, since those are automatically substituted and do not create type aliases.
The test case of the implementation at dotty/tests/pos/mt-deskolemize.scala at dropSkolem · dotty-staging/dotty · GitHub gives a motivating example (being able to extract the type of a literal representation of a domain class), I tried more involved encoding using typeclasses to represent this problem, but did not manage to get a working solution without the proposed SIP amendment.