Is there an explanation of the reasoning behind various -Xlint options?

Question
11

  • -Xlint:inaccessible: The code shouldn’t produce the warning there, if so then you probably found a bug and then you probably want to report it. - BTW, you may be interested in this.

  • -Wunused:explicits:

this is not optimisation. This is a future proof design

Again, I am not saying you are doing something wrong, I just think you are thinking too much for the future. A good design is not the one that works for all the future use cases, is the one that is easy to change in the future.

But if this strategy works for you then go ahead, just disable this warning. You even mentioned that you never found an unused parameter to be an error or a bug, I disagree but those are just personal experience / feelings.

Yes, splitting everything into completely abstract interfaces and concrete implemenations addresses this issue, but there is a reason why traits and even Java interfaces can now have default implementations.

Again, I personally never override an implementation, they are abstract or final. But I understand that is something very few people would agree with. But in that case, you only have the unused warnings in one place, you can easily silence them using the @unused annotation.

And method parameters cannot be replaced with constructor parameters, because the function of methods is to be called for different arguments.

Sorry for not being clear, my point is that most of the time I needed an extra parameter in a subclass, I found it easier / better to pass that in the constructor of such subclass. It may be just my bias to design.

  • Erasure example. Well, that will trigger an Wunused:implicits so it’s not really different.

I believe (but could be wrong) the compiler doesn’t emit unused warnings for the DummyImplicit, otherwise again a single @unused annotation doesn’t feel too bad.

But, I don’t want to keep the cycle, happy to agree to disagree in this one.

I hope you can find the set of rules that work the best for you and your coding style. I am personally very happy with sbt-tpolecat, since for me all the things it flags are 99% of the time potential bugs :slight_smile: