`?` in match type cases

[nicolasstucki]

Compiler version

3.3.1

Minimized code

import language.future

type F[X] = X match
  case List[_] => Int // `_` is deprecated for wildcard arguments of types: use `?` instead

type G[X] = X match
  case List[?] => Int

as this is a type binding we should use _ and not ?. The issue seems to come from parsing the type of the case with simpleType which always emits the deprecation.

Expectation

• The deprecation warning should not be emitted
• It seems that ? should not be allowed. We also allow ?

[dwijnand]

Is it a binding if it doesn't have a name? I think what we have is right, like we have case xs: Tuple2[?, ?] for term matches.

[nicolasstucki]

Interesting. It under that notation, the following seems inconsistent.

type G[X] = X match
  case ? *: ? => Int
  case _ => Int

@sjrd Is that one of the things that will be disallowed with the new match type spec?

[sjrd]

Erf ... in theory we could assign two different theoretical meanings to these.

• _ is a capture that is ignored (there is spec text for this in the SIP)
• ? is not a capture; it is just a wildcard type argument to a normal type (there is no specific spec text, but it falls into all the cases of types without nested captures that appear as patterns)

That said, for all practical purposes, they will behave the same. Or at least I think so (there might be some really fun things with type constructors that have interdependent type parameters).

[sjrd]

To be perhaps clearer, I think both have their merits, but in most cases _ should be encouraged, if only by analogy to _ in term pattern matches. In the majority of match types where we want a wildcard, we mean "there's something here but I don't care", which is what _ stands for. We rarely mean ?.

[nicolasstucki]

@sjrd so we should not have the deprecation warning in that case?

[sjrd]

Indeed, IMO it shouldn't be deprecated there.