Style/ArgumentsForwarding` should allow or forbid specific argument names

[nevans]

Is your feature request related to a problem? Please describe.

As it is today, Style/ArgumentsForwarding is great for cutting down on the redundant noise of argument passing. Using anonymous argument names clearly signals that the arguments are either ignored or forwarded. It was the first autocorrection I ran after upgrading to ruby 3.2.

However, argument names can be used to document more than just "this is forwarded". E.g: these names can document what they are represent, and where they are forwarded. This is especially important for gem authors and public APIs. As ruby language servers mature and achieve greater adoption, this documentation becomes more useful even on internal or private methods.

If the names are simple *rest, *args, **kwargs, **opts, and similar, then the names are (generally) not really serving any purpose but noise. But if the names are **scope_options or *authenticator_args and so on, now they might be worth preserving.

Describe the solution you'd like

I would like (at least) two new configurable attributes: AllowedNames and ForbiddenNames. Both options should be an array of either regular expressions or strings. The defaults could be the same as today: forbid all and allow none.

We might add separate configuration options for each of the rest, kwrest, and block parameters, but I personally would prefer to keep it simpler with only these two options.

Describe alternatives you've considered

1. Just let rubocop autocorrect names that are unique and helpful... but only a little bit helpful.
2. Add # rubocop:disable Style/ArgumentForwarding every time I feel the names are important to the documentation.

Additional context

When I upgraded to ruby 3.2, I used rubocop to autocorrect almost every single Style/ArgumentsForwarding offense in my codebase. For at least 9 out of ten changes, I agreed completely. For almost all of the rest, it wasn't really worth the effort to deal with them on a case-by-case basis... but if I'd had these configuration attributes, it would have been worth my time to configure.

Thanks!

[koic]

I've opened #12397 to resolve this issue. It's a slightly different approach from the proposal, but it addresses the issue effectively.