Add support for requiring the usage of named arguments

[stof]

Feature request

Providing BC for both positional and named arguments at once basically forbids removing any argument other than the last one.
phpstan (and psalm) already supports @no-named-arguments to support the case where a package wants to provide BC only for the positional signature to keep flexibility for maintenance. However, for some cases, using named arguments is more convenient for DX, and projects might want to cover named arguments with BC without covering positional usage. It would be great to have a @only-named-arguments tag to support such cases.

Applying both tags on a method should of course be considered an error. However, I suggest that a method level tag should be able to reverse a rule defined at class level (treating the class-level rule as a default)

Did PHPStan help you today? Did it make you happy in any way?

No response

[ondrejmirtes]

I don’t understand this. Why would a project care about how a function is called? It’s up to the user if they’re going to use named arguments or not.

and projects might want to cover named arguments with BC without covering positional usage

Heh, definitely not in PHP. Positional arguments are used in 99 % of cases and always have to be supported in BC policy.

[stof]

We care about it because of the BC impact of changing a signature. Supporting both named arguments and positional arguments basically forbids removing any argument in the future.

Currently, in Symfony, we exclude named arguments from the BC policy for that reason. But we have some cases (constructors of immutable objects with lots of optional fields for instance) where using named arguments would be more convenient. We are precisely discussing the possibility of dropping BC for positional arguments in such cases to allow us to have such APIs without forbidding us to change things in the future.
That feature request comes from this discussion, as it would be great if SA tools could help downstream users to respect the usage covered by BC.

[ondrejmirtes]

Alright, once you have that, we could hardcode these cases in phpstan-symfony, before doing a general solution here.

[stof]

The Symfony core team would definitely prefer a way to declare that on our side in the codebase than having to create tons of stubs that have to be maintained through external contribution and kept in sync with signature changes done in different version of Symfony.
This is already how @no-named-arguments works.

Thus, as a personal opinion (not discussed with other core team members yet, so not expressed on their behalf), cases like phpstan/phpstan-symfony#430 worry me about such solution as this is a case where phpstan-symfony goes explicitly against the behavior wanted by the Symfony core team.

[stof]

To be clear, Symfony does not intent using this tag everywhere (most of our classes will keep using the rule of no named arguments) but we would use them on specific methods (the use cases I have in mind would be constructors for now).

[ondrejmirtes]

That's why I think this could be hardcoded in phpstan-symfony. Not via stubs obviously, but with a constant array in a custom rule.