-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Comments
Is it a binding if it doesn't have a name? I think what we have is right, like we have |
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? |
Erf ... in theory we could assign two different theoretical meanings to these.
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). |
To be perhaps clearer, I think both have their merits, but in most cases |
@sjrd so we should not have the deprecation warning in that case? |
Indeed, IMO it shouldn't be deprecated there. |
I agree. In type patterns, a |
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. |
We need to fix this bug to be able to emit the migration warning in 3.4 (#18869) |
Compiler version
3.3.1
Minimized code
as this is a type binding we should use
_
and not?
. The issue seems to come from parsing the type of the case withsimpleType
which always emits the deprecation.Expectation
It seems thatWe also allow?
should not be allowed.?
The text was updated successfully, but these errors were encountered: