On the contributors forum a discussion is taking place about replacing @unchecked and turning refutable patterns into static errors. But what would be the correct way for the user to circumvent this warning (which will become an error on later Scala versions) in the first place? My question comes from the use of this pattern in my code which issued no warnings before:
def work(file: File, tests: File => Boolean *): List[Boolean]
The idea is that the method opens a file, performs a fixed number of tests at once, and then returns the same number of answers. So if you do:
val (result1 :: result2 :: Nil) = work(file,test1,test2)
you will know that it will issue no runtime errors, but the compile cannot know this of course. But what is surprising, at least to me, is that the warning seems only indirectly related to the underlying problem, namely that the number of items must be equal. This code gives the same compile time warning on all lines:
val (_ :: _ :: Nil) = List(1) // compile time warning, runtime error val (_ :: _ :: Nil) = List(1,2) // compile time warning val (_ :: _ :: Nil) = List(1,2,3) // compile time warning, runtime error
It is only at runtime the first and third line fail.
Now, if I try to define my own list class (called
:|: instead of
Empty instead of
Nil) with a compile time fixed number of items, this still gives the same warning, albeit that the wrong number of items is now an error at compile time:
val (_ :|: _ :|: Empty) = Series(1) // compile time error val (_ :|: _ :|: Empty) = Series(1,2) // compile time warning val (_ :|: _ :|: Empty) = Series(1,2,3) // compile time error
What would be the correct way to program this, so that no warning is issued at compile time when the number of items is correct, and a compile time error when it is not?