Helper for unused parameters

[fommil]

This makes @som-snytt's wonderful work on unused warnings sooo much easier to enable

class unused extends deprecated("unused", "")

There are many valid usecases for ignoring a parameter. For example, in scalaz's .xmap.

[pjrt]

Why not something similar to what we do in Haskell: parameters which start with _ are not considered "not used". This allows you to turn off the warning for specific parameters, instead of turn it off for the whole scope (and doesn't require ugly annotations).

[som-snytt]

@pjrt The difficulty with a naming convention is named args.

On the ticket about requiring args to @deprecated, I asked them not to. That's a very slight mitigation of ugliness.

In Java, a deprecated parameter will never warn if used, so it seems like a safe convention to use the same marker for never warn if unused.

Someone recently tweeted that unused parameters are evil. I'll attach a link if I can find it on twitter, which I won't.

[som-snytt]

Not warning on meh is an easy win.

https://twitter.com/MorseCode8086/status/970879623083982850

[SethTisue]

@som-snytt but seriously, what do you think the right way forward here is?

[som-snytt]

@SethTisue it's like adding Regex.matches, it's a convenience, and every convenience requires approval of the scala center board. It would be easy to sneak in as an inconvenience.

Also, shouldn't it be called @used? It's like asInstanceOf, you're telling the compiler to assume that it's used even if it thinks otherwise. If you call it @unused, you're saying it's unused, so of course the compiler should warn about that. If we introduce both @used and @unused, the ergonomics would be inconvenient enough that we wouldn't have to wait for the next board meeting.

But seriously, I'm fine with this proposal.

[SethTisue]

okay so suppose we go with @unused, we don't literally want unused extends deprecated, right? you'd change the unused-code-a-lyzer to recognize @unused directly?

[hrhino]

Have we considered litotes? @notUnused isn't as strong as @used but also isn't the exact opposite of what I mean.

(serious part of the comment: I think this is a subset of "let's make silencer part of stdlib", though, if we want to take on that scope creep. Is there a reason it hasn't been done, other than no one wanting to?)

[som-snytt]

I gave a moment's thought to implementation while writing my previous comment, and hoped to try something out before the issue was marked good first issue. My momentary insight was that extends deprecation is not hokey, because if something is unused then you should not be using it, hence it is implicitly deprecated. I will check whether deprecation always silences unused warnings. This reasoning also settles the naming question.

Then this annotation also expresses deprecation-bc-unused more generally, so it is independent of message-suppression as such.