New patmat warnings on destructure

[japgolly]

reproduction steps

using Scala 2.13.4

val List(x, y) = List(1, 2)

problem

Warning appears:

[error] It would fail on the following inputs: List(_), Nil
[error]       val List(x, y) = List(1, 2)

There wasn't a warning until 2.13.4.

Should the new patmat strictness (which is awesome btw) apply to destructures like this? It would be valuable in this case:

val a = List(1, 2)
val List(x, y) = a

but when the right-hand side is a single known and specific pattern (in our case _ :: _ :: Nil), the warning is spurious.

[SethTisue]

I don't think we can expect the compiler to inspect the rhs, any more than we expect it not to warn here:

scala 2.13.4> List(1, 2) match { case List(x, y) => true }
                  ^
              warning: match may not be exhaustive.
              It would fail on the following inputs: List(_), Nil

so I believe the current recommendation here is:

scala 2.13.4> val List(x, y) = List(1, 2): @unchecked
val x: Int = 1
val y: Int = 2

[som-snytt]

Workaround is

val List(x, y) = List(1, 2): @unchecked

[SethTisue]

jinx

[som-snytt]

I was even too slow to say jinx. Do you have a jinx hot key?

[japgolly]

Ideally List(1, 2) match { case List(x, y) => true } wouldn't produce warnings either though. 🙂 I mean I think we'd all agree that in a perfect world it wouldn't produce warnings. I presume you don't expect it to be resolved because it would be too hard to implement (and fair enough if that's actually the case), but, is it really? It might be good to confirm because I imagine the fix would be one or both of the following which don't sound crazy hard to me:

1. perform the check before widening / dealiasing the rhs (so that the type is retained as _ :: _ :: Nil)
2. teach the compiler to understand that when List.apply is called with a deterministic number of args, the return type will be more specific (like _ :: _ :: Nil in our case). Hmmm yeah I could see how that could be quite a major undertaking. Would it be hardcoded to List? Would it affect inferred types in other places? Probably this is the piece that's not feasible to implement right?

I've never worked on the internals of scalac so my understanding is pretty limited. Is the above correct and is that why it's not feasible to fix this?

[SethTisue]

that all seems about right, but there is an additional major roadblock, namely:

the type is retained as _ :: _ :: Nil

but there is no such type — :: only has a single type parameter — this is List we're talking about, not HList

(and although I haven't checked, my guess is that the exhaustivity checker probably already handles HList fine. at least, I can't think why it wouldn't)

[dwijnand]

I think we're ok here, given the trajectory for 3.0 and 3.1: https://dotty.epfl.ch/docs/reference/changed-features/pattern-bindings.html

Sometimes one wants to decompose data anyway, even though the pattern is refutable. For instance, if at some point one knows that a list elems is non-empty one might want to decompose it like this:

val first :: rest = elems   // error

This works in Scala 2. In fact it is a typical use case for Scala 2's rules. But in Scala 3.1 it will give a type error. One can avoid the error by marking the pattern with an @unchecked annotation:

val first :: rest : @unchecked = elems   // OK

This will make the compiler accept the pattern binding. It might give an error at runtime instead, if the underlying assumption that elems can never be empty is wrong.

[SethTisue]

good to have the discussion here on-the-record — thanks for the report

[SethTisue]

note that Scala 2 doesn't accept val first :: rest : @unchecked = elems (as on the Scala 3 doc page), it only accepts val first :: rest = elems: @unchecked 🤔

[som-snytt]

Note that Scala 3 doesn't use @unchecked on the RHS as is most natural.

[Jasper-M]

If I had to choose between val first :: rest : @unchecked = elems, val first :: rest = elems: @unchecked or waterboarding, I would choose val first :: rest = elems: @unchecked.

[SethTisue]

@som-snytt jinx again

Yeah, I agree that the Scala 2 style is preferable, primarily because it is consistent with (foo: @unchecked) match ..., where one also annotates the scrutinee, not the pattern. Somebody want to open a Dotty ticket?

[som-snytt]

I'm afraid to annoy them with my observations, but someone might be brave enough to submit a ticket at https://github.com/lampepfl/dotty-feature-requests.