Should runtime type test without Typeable be a compiler error?

Dotty
1

I ran into an issue with Typeable not being in scope and found out Typeable doesn’t really work on composite types.

This got me thinking, if type testing like the code linked in the issue here: Typeable instance not being discovered on generic type typetest · Issue #12668 · lampepfl/dotty · GitHub

should be a compiler error by default?

Type erasure whilst powerful can be of surprise in cases like this to newcomers to the scala language without knowledge of JVM internals and considering how easy it is to create code as such, wouldn’t it be reasonable choice to create a compiler error if no implicit Typeable is found in scope instead of compiler warning?

1 Like
2

I agree, unchecked warnings should be errors by default, this came up again recently in Add an API for getting an erased type · Issue #209 · lampepfl/dotty-feature-requests · GitHub where @adamw said he preferred using a macro to emit an error explicitly because unchecked warnings are too easy to ignore.

4 Likes
3

A good first step here would be for someone to go through the ~200 unchecked warnings that scala 3 emits when it compiles the 2.13 standard library to verify that they are not false positives, then either fix the code or add @unchecked with some justification that it is sound: Travis CI - Test and Deploy with Confidence

7 Likes