func-names: Allow unnamed generators (option)

[joegoldbeck]

What rule do you want to change?
func-names

Does this change cause the rule to produce more or fewer warnings?
Fewer

How will the change be implemented? (New option, new default behavior, etc.)?
New option

Please provide some example code that this change will affect:

const parse = coroutinify(function* (input) { ... })

What does the rule currently do for this code?
"Unexpected unnamed generator function" unless the option is set to "never"

What will the rule do after it's changed?
Allow unnamed generator functions if a second option is set to { generators: false } or similar

[not-an-aardvark]

Thanks for the proposal. Could you clarify what the motivation for this option is? Why do you want to allow unnamed generators while disallowing other unnamed functions?

[joegoldbeck]

Sure, happy to clarify!

The reason comes down to language-level limitations, and in particular, that arrow notation can be used to create functions but not generators.

When we create lightweight functions, we use arrow notation, which are inherently unnamed. As one reference point, the AirBnb styleguide recommends this approach.

However, for generators, we can only use the standard function*, and so an exception for generators would allow us to create lightweight unnamed generators while leaving our stricter linting rules for functions intact.

[not-an-aardvark]

I see, thanks. That makes sense to me -- let's see if the rest of the team would be in favor of adding an option like this.

[ekimlinger]

Not sure if this would have to be a new rule request, however generators also spark a similar break with the 'func-style' rule.

Say for example we have the following code:

const anExampleGenFunc= function* () {
    yield () => console.log('Do Something more than a console.log here');
};

I feel as though that this is perfectly valid JS (please correct me if I am wrong), but it raises a warning in eslint.
[eslint] Expected a function declaration. (func-style)

[ilyavolodin]

It looks like there's more then enough support from the team to accept this. We just need somebody to champion this change to mark it as accepted. @eslint/eslint-team anyone willing to champion?

[not-an-aardvark]

@eslint/eslint-team Anyone willing to champion this change? If not, it's probably time to close it.

[platinumazure]

I'll champion this.

[platinumazure]

@joegoldbeck After quite some time, this issue is now accepted. Would you be interested in submitting a pull request? (If not, no worries-- maybe someone else will, or maybe I can find some time myself in the next few weeks.)

[OscarBarrett]

I'll submit a PR for this in the next couple of days.