-
Notifications
You must be signed in to change notification settings - Fork 1.1k
The union type of any pair of singleton types is equivalent to their supertype #829
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
…code There are two cases where we should not widen singletons in unions: - When we explicitly write the type, like `val x: 1 | 2` - When pattern matching binds an alternative, like `case x @ (1 | 2) =>` Fixes scala#829
…code Note that we do not keep singletons in pattern alternatives like `case x @ (1 | 2)` because if there are many alternatives like `JavaScanner#fetchToken`, we end up with deep subtyping checks. Fixes scala#829
…code Note that we do not keep singletons in pattern alternatives like `case x @ (1 | 2)` because if there are many alternatives like in `JavaScanner#fetchToken`, we end up with deep subtyping checks. Fixes scala#829
Another useful test is to check whether this compiles:
|
It does with #844 if you add a few parentheses to avoid precedence issues: object Test {
implicitly[(1 & (2 | 3)) =:= ((1 & 2) | (1 & 3))]
} |
Great! Do you have any thoughts on the precedence rules for type operators, in light of |
Yes, it's especially confusing for pattern matching: x match {
case x: 1 | 2 => // means case (x: 1) | 2, but is likely to be interpreted as case x: (1 | 2)
case x @ 1 | 2 => // means case (x @ 1) | 2, but is likely to be interpreted as case x @ (1 | 2)
} |
The idea to take precedence from Java is still valid I think. Tweaking here
On Thu, Oct 22, 2015 at 9:45 PM, Guillaume Martres <notifications@github.com
Martin Odersky |
Fair enough, but note that this means that porting uses of intersection types from scalac to dotty is not trivial because trait A
trait B
object Test {
(new A with B) match { case x: A with B => x } // OK
(new A with B) match { case x: A & B => x } // error
(new A with B) match { case x: (A & B) => x } // OK
}
` |
Superseded by #1551 |
There are a couple of ways of demonstrating this. The following does not produce a type error when it should:
whereas this does (correctly):
Intersection types do, however, appear to work correctly. This produces the expected type error:
The text was updated successfully, but these errors were encountered: