-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Failure to refine @-bound variables (x @ <pattern>) when pattern is a literal #22954
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
Comments
I had the same question about your recent similar ticket, where it did not make a difference. For a constructor pattern, I would expect a type test; but I also had a question about the semantics of Scala 3 patterns here (because of the internal representation). I think I looked for documentation or spec in vain; but maybe there is institutional knowledge. Edit: related ticket is #16821 |
That's not something I'm trying to argue in this ticket (although I believe they should be effectively the same for literal types). Note that I only used |
On the related ticket, Dale pushes back on anything except an equality test. (Which I think is not sufficient.) |
Not exactly sure what you mean, but I'm just arguing that |
To explain what I mean, I think what you're asking is a spec change (which I think is a good change). But on the related ticket, they're not (even) willing to enforce what is already in the spec. (I don't know if this is a case of "just syntax", since |
FWIW, I think what I'm asking for is in the spec (but I sure don't mind updating the spec if it makes Scala better):
https://www.scala-lang.org/files/archive/spec/3.4/08-pattern-matching.html#pattern-binders According to the above, the type of variable
EDIT: The definition of "implies" in the spec is unfortunate. For example, any pattern implies (among others) the type |
Compiler version
3.6.4
Minimized code
Output
Expectation
The type of variable
x
inx @ "x"
should be refined toS & "x"
, analogous to how it works with non-literal patterns:Note
I believe this issue will be easier to fix than #22887, as this one is about assigning a more precise type to a newly bound variable, rather than locally (within a pattern case) refining type of an existing variable.
The text was updated successfully, but these errors were encountered: