Well, this post came from me tryig to find a suitable set of Xlint warnings I agree with, after all. I am not waging a war against them 
-Explain flag is of course nice, but it only will come into use if you enable a specific Xlint option and then trigger it, while I hoped to look through everything, learn something in the process, and decide on a subset of options in one go, rather than switching everything on and then disabling one by one if found annoying.
@Jasper-M At the risk of making a fool of myself, why in the given parameterized case the implicit method for List[T] is not picked up? Does it have to do with Scala’s somewhat unfortunate overloading rules? I actually never overload implicit methods just to be sure, because unlike anything else, this is a costless limitation.
-
-Xlint:inaccessible We have a sealed keyword for traits and classes, but it is limited to one file. My files for roots of class hierarchies tend to get huge anyway due to scaladocs, so I wanted to achieve the same effect, but restricted to either my compilation unit (i.e. nothing outside of my jar) or simply a given package, so I can put those implementations in separate files.
-
-Wunused:explicits - this is not optimisation. This is a future proof design and this strategy proved beneficial many times for me, especially in the unified signature case. I don’t think I ever once in my life found myself in a situation where an unused parameter was a mistake, oversight or bug. Yes, splitting everything into completely abstract interfaces and concrete implemenations addresses this issue, but there is a reason why
traitsand even Java interfaces can now have default implementations. It is just convenient. And method parameters cannot be replaced with constructor parameters, because the function of methods is to be called for different arguments. -
Erasure example. Well, that will trigger an
Wunused:implicitsso it’s not really different.
Type system and compiler warnings are two different things to me. Yes, many warning rules are very useful, but the nature of warnings, as martinijhoekstra said, is that there a valid use cases. In my very personal viewpoint, warnings should be reserved for:
- use cases which will be disallowed in a future version;
- cases which are 99% of time, like not modifying loop variable inside the loop, method doing nothing but calling itself, etc. I actually think IntelliJ is doing a very good job here, I have switched off maybe three rules out of dozens, and that includes one which simply didn’t work as intended.
Because if the compiler thinks that something as simple as all above rules is very likely an error, then the language is flawed in that area, and, ideally, should be changed to avoid the trap, perhaps adding a safer method/syntax in the place of the old one. Because ultimately yes, code producing warnings is bad - at least once merged into a public branch in a VCS.