Imported From: https://issues.scala-lang.org/browse/SI-440?orig=1
Reporter: @blair

@odersky said:
Milestone next_bugfix deleted

@adriaanm said:
This is more of a lint thing, as said by OP.

@blair said:
Are you suggesting that one use findbugs instead of having scalac warn you? I find this an odd resolution given there isn't a native lint tool for Scala.

@adriaanm said:
I find this odd logic. It's not because we don't have the tool that should do this, that we should add this to the tool we do have but that shouldn't do this.

@blair said:
Talk about a sentence that needs compiler to parse ;) Why shouldn't the computer warn about these?

One of the reasons people like using Clang instead of gcc/g++ to compile their code is because it gives more and better warnings and errors. I would think one would want the same from scalac. Am I missing something?

Christopher Sahnwaldt (jcsahnwaldt) said:
The Eclipse Java compiler can be configured to add warnings for unused private members. I think it can even be told to treat them as errors. Thos adds yellow or red wriggly lines in the editor. Very helpful. Don't know about the command line version.

@retronym said:
I don't disagree with Adriaan -- there are one or two lint tools in development that build on top of the compiler infrastructure (eg. scalastyle), and this would make a great feature for these.

But in the meantime, here an experimental implementation: paulp/scala@386464fe. Not really suitable for an end-user at it is based on the generated bytecode, so the warnings might refer to mangled names, etc.

BTW, IntelliJ highlights unused privates.

@adriaanm said:
From our perspective, it's yet another feature that detracts from core compiler development. From the user's perspective, compile times would go up even more (except if we put it behind a switch, of course, but then we might as well put it in a different tool).

I'd rather invest in a rich compiler "platform" that can be used by tools such as the ones Jason mentions than implement this ad-hoc analysis (no matter how useful).

This kind of analysis seems like something you would run once in a while, maybe on an integration server, or after a refactoring.

@blair said:
I agree, I'd rather see the Scala compiler developers spending time on core language features, e.g. more optimizations, that we would use all the time then a compiler warning, or a compiler platform.

The issue I had with closing the ticket was the "Out of Scope" resolution, which doesn't seem accurate, as a compiler is one place to check for programming errors. What about adding another "Will not implement" and provide the limited resources as a reason in the comment? I wouldn't have been so adamant about this issue then :)

@paulp said:
scala/scala@d0c4be6861