Hello, I have discovered inconsistency / non-orthogonality in pattern matching.
final case class Cl(a: Int, b: String)
val x = Cl(10, “test”)
// both case and non-case work
for { case Cl(age, _) ← Some(x) } println(age)
for { Cl(age, _) ← Some(x) } println(age)
// only case works
for { case Cl(a = age) ← Some(x) } println(age)
for { Cl(a = age) ← Some(x) } println(age) // compile error
I think it is important for this to be orthogonal, as you are forced to use “case“, but without the compiler checking that the match is total.
On a related note, this is inconsistent as well:
val Cl(age, _) = x
val Cl(a = age) = x // compile error
Why is SIP-43 missing on this list, if it appears to have been implemented?
It seems unimplemented AFAICT, the pull request was closed with unmerged commits.
The SIPs list, which I once had bookmarked as a valuable reference, is still currently very confusing for any purpose.
Pattern matching with named fields is uncontroversially:
I’m not sure what the web editor intends to do with my link, alas. It is this link. I think.
The “val def” example makes me go what?
1 |val C(i = j) = c
| ^
| Illegal combination of named and unnamed tuple elements
Yes, I omitted the other element, that’s the whole point of the feature.
It’s OK with naming the other element in order to ignore it.
val C(i = j, s = _) = c
I hope it is a bug. I don’t use the feature, as all of my FOMO is directed toward capture checking.
I’m aware that named tuples are supertypes of unnamed, but it’s not obvious how that fact intersects here.
The reference says:
Named patterns are compatible with extensible pattern matching simply because unapply results can be named tuples.
In other words, “it is obvious that..”, in the famous mathematical paraphrase.