Typescript: with --noUnusedParameters how can i skip uneeded parameters

[zpdDG4gta8XKpMCd]

sorry for being persistent, same question as in

https://github.com/Microsoft/TypeScript/issues/9403#issuecomment-229222818

how is this going to work with unused parameters?

fiction third(x:any, y: any, z: T) : T { return z; } // need only last one

[mhegazy]

i was thinking of _ as a special case. but that does not seem nice. the other option is to use arguments.

[zpdDG4gta8XKpMCd]

_ works well in f#, and i like it a lot, but might be a breaking change for stuff like underscore.js

[RyanCavanaugh]

I would propose that any local starting with _ is not subject to unused checks. For multiple parameters you could then write (_0, _1, x) => x

[zpdDG4gta8XKpMCd]

consider third<T>(,, z: T): T { return z; }

[RyanCavanaugh]

Discussed quite a bit here https://esdiscuss.org/topic/uninteresting-parameters and I would defer to their judgement

[mhegazy]

I have a fix out in https://github.com/Microsoft/TypeScript/pull/9464. any parameter name starting with _ is exempt from the check.

[mhegazy]

if @RyanCavanaugh gives me a :+: i can get it in

[zpdDG4gta8XKpMCd]

@RyanCavanaugh the discussion you mentioned ended nowhere, but I like the point that was raised there: destructuring has been _already_ accepting commas for unused array elements:

const values = [1,2,3];
const [,,z] = values;

[KnisterPeter]

The referenced discussion is about destructuring.
I think it may introduce flaws and false positives to prefix a parameter name with _.

For example if in a current function the first parameter is not used but the second is I need to prefix the first one. If the code is refactored then and afterwards the function only has one parameter left (the first one because of api changes), then the check is disabled, because it is still prefixed.

It is very easy to forget to remove the underscore prefix.

As well we have a compiler meaning in the parameter name which I think is no good practice. If I like to skip a parameter at all, then a single underscore may be okay, but again I would think this does not lead to good readable code.

May I suggest that the compiler reduces the parameters from right to left and only the last x ones not used lead to an error?
If there are parameters on the left side of a used one, the unused error is silently ignored.

[JoshuaKGoldberg]

I would add the linting argument for the variable names. It's against some coding styles to have _s in front of names. As @KnisterPeter mentioned, we're binding compiler logic and the variable name. That feels weird.

Even worse, some coding styles _prefer_ the _ names, and so won't benefit from the compiler flag.

[EnverOsmanov]

_ is "reserved" by underscore.js so double underscore or asterisk could be used instead

 (__, __, x) => x
 (*, *, x) => x

[kitsonk]

_ is "reserved" by underscore.js so double underscore or asterisk could be used instead

The fix, which is merged, and therefore this issue is closed states that _any_ variable that starts with an underscore will be considered _uninteresting_, so a double underscore is already valid.

[Melmoth-the-Wanderer]

I agree with @KnisterPeter , compiler should not force developer to use particular naming convention, which might be not possible in certain cases (or may at least put other devs in confusion). I would love to see a fix for compiler, if possible.

[EnverOsmanov]

@Melmoth-the-Wanderer what is a problem to call unused parameters as double underscore (for example)? Can you provide an example when it is not possible?

[Melmoth-the-Wanderer]

@EnverOsmanov , it's been already briefly explained above. When you change the name by appending underscore, its easy to loose the context of the change in future. Especially if __name_ is reserved for some kind of special cases in your team. It also might require developers to change coding styles and guidelines.

Imagine working on a long-lasting project with multiple devs involved. Years ago your team used to name private properties with _ at the beginning. And couple of month ago team decided to change coding guidelines so its not acceptable anymore in the team. So you added lint rules to warn users no to do so - and now you have a problem, because your compiler requires special naming rules! And if someone is already using double underscore for some kind of semantic information, you go and tell them what you meant by adding the third one.

In principle, it is possible to name variable starting with _ sign because JS allows that, no doubt. But I've got mixed feeling when it comes to language (compiler in this case) telling programmers how to name their variables.

For now it's just one prefix and maybe I'm overreacting, but if we start allowing such prefixes Its going to be a really messy 'language' pretty soon.

[RyanCavanaugh]

No one's being forced to do anything. You can turn off noUnusedParameters if this is bothersome. You can @ts-ignore if you want to silence a particular line of code. You can write your own lint rule that says ignored parameters must be named exactly _0, _1, etc..

People wanted a convenient "out" for an unused parameter in the rare cases where it was provided, and we added one that doesn't really change anything else about the language for the sake of simplicity.

[Melmoth-the-Wanderer]

Sure, I just share my thoughts on how to improve. I just thought it would be nice to make noUnusedParameters work out of the box without doing extra steps on dev side.

Thanks for the hint on how to deal with the problem internally, though