-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Open
Labels
Description
Compiler version
Scala 3.7.1
The issue also exists on 3.3.5 and 3.6.4, which very likely implies that the issue exists on every version.
Notably, compiler with version less than 3.7 encounter additional bugs related on union type on top of the current bug.
JVM version is not related to the problem. Nor is the running environment.
Affected Component
The compiler itself.
Minimized code
enum E:
case A
case B
case C
type NotC = E.A.type | E.B.type
def doSomething(): (Int, NotC) = (1, E.A)
def bee(nu: NotC): Unit =
println("bee")
@main def main(): Unit =
val nu = doSomething()
val (x, nnu) = nu
bee(nnu)
Output
Compiling project (Scala 3.7.1, JVM (24))
[error] ./main.scala:16:9
[error] Found: (nnu : E)
[error] Required: NotC
[error] bee(nnu)
[error] ^^^
Error compiling project (Scala 3.7.1, JVM (24))
Compilation failed
Expectation
bee
Additioinal Note
Please see here: https://www.reddit.com/r/scala/comments/1l5cpg4/weird_behavior_of_union_type_widening_on_method/
for a full discussion regarding the issue.
I kept the bug report as minimal as possible as instructed, but the context might be helpful.
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
som-snytt commentedon Jun 17, 2025
The trip through pattern matching:
but I wonder if #23373 will address it.
(I would try it now, but WSL just crashed and corrupted my repo.)
WhiteZh commentedon Jun 17, 2025
Hi, I wonder how did you obtain the "trip though pattern matching"?
Additionally, after I've read the "trip through pattern matching", I think it might be worth mentioning that if I annotate the type of
nnu
like this (changed line 15):the code will compile but with a warning of unchecked type narrowing:
Other type annotation such as annotating
nu
or(x, nnu)
as a whole would still result in compilation errors.noti0na1 commentedon Jun 17, 2025
It compiles fine with my PR:
But I guess we should still try to fix the widening?
noti0na1 commentedon Jun 17, 2025
I would suggest we update the code to following to illustrate the widening issue more clear:
WhiteZh commentedon Jun 17, 2025
Agree. That was similiar to how I wrote it initially. I later expanded it as I thought it would make each step clearer.
WhiteZh commentedon Jun 17, 2025
Worth mentioning that the problem doesn't apply to all generic types. As this code works:
som-snytt commentedon Jun 18, 2025
@WhiteZh use
-Vprint:all
to see how code is expanded/translated, whereall
can be a "phase name".If they accept #17563 someday, one could skip over explaining what a phase is, as a baby step.