Interaction of boxing and pattern matching; 2 and 3 behave differently #13399
SethTisue
started this conversation in
General Discussion
Replies: 2 comments
-
to further muddy the waters, whatever in the Scala 3 implementation that is allowing
|
Beta Was this translation helpful? Give feedback.
0 replies
-
Maybe related https://github.com/lampepfl/dotty/pull/11327/files where conformance was enforced for stable idents. "Would it make sense to check this also for other values that are not modules?" such as literals.
|
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Scala 2:
Scala 3 (3.1.0-RC1-bin-20210825-ce0e25c-NIGHTLY-git-ce0e25c):
The argument for the Scala 3 behavior is that
(1: Integer) == 1
, so the same thing ought to work in pattern match form.But it seems to me that the spec specifically forbids this. SLS 8.1.4 says:
Note the second sentence.
Int
andInteger
are unrelated types, so the type of1
does not conform to the pattern type (Integer
), so it seems that Scala 2 is adhering to the spec in rejecting the code.Should the Scala 3 pattern matcher be made to follow the spec, or would it be better to change the spec to allow its present behavior...?
Note that the Scala 3 compiler does sometimes enforce that sentence of the spec:
it rejects the match even though the same thing written with
==
directly works.You can also do a test where implicit conversions exist between otherwise unrelated types and the Scala 3 compiler will still reject the match.
So whatever the Scala 3 compiler is doing to handle
Int
vsInteger
must be specific to boxing-of-primitives, rather than applying to implicitly convertible types in general.(This came up in the context of #13290, where we found an example of
(x: Integer) match { case 1 => ...
in a test case.)Beta Was this translation helpful? Give feedback.
All reactions