Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

? in match type cases #18808

Closed
nicolasstucki opened this issue Nov 1, 2023 · 9 comments · Fixed by #18887
Closed

? in match type cases #18808

nicolasstucki opened this issue Nov 1, 2023 · 9 comments · Fixed by #18887

Comments

@nicolasstucki
Copy link
Contributor

nicolasstucki commented Nov 1, 2023

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
Copy link
Member

dwijnand commented Nov 1, 2023

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
Copy link
Contributor Author

nicolasstucki commented Nov 1, 2023

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
Copy link
Member

sjrd commented Nov 1, 2023

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
Copy link
Member

sjrd commented Nov 1, 2023

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
Copy link
Contributor Author

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

@sjrd
Copy link
Member

sjrd commented Nov 1, 2023

Indeed, IMO it shouldn't be deprecated there.

@odersky
Copy link
Contributor

odersky commented Nov 3, 2023

I agree. In type patterns, a _ is pefectly natural, and we don't want to deprecate it.

@nicolasstucki
Copy link
Contributor Author

We still need to remove the wrong deprecation warining on match cases.

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

This warning should not be shown.

@nicolasstucki nicolasstucki reopened this Nov 6, 2023
@nicolasstucki nicolasstucki added this to the 3.4.0 milestone Nov 7, 2023
@nicolasstucki
Copy link
Contributor Author

We need to fix this bug to be able to emit the migration warning in 3.4 (#18869)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants