Cast env vars to null or bool when referencing them using #[Autowire(env: '...')] depending on the signature of the corresponding parameter

[ruudk]

Q	A
Branch?	7.1
Bug fix?	no
New feature?	yes
Deprecations?	no
Issues	Fix #53918
License	MIT

See #53918

This PR automatically adds bool Environment Variable Processors on #[Autowire(env: 'KEY')] bool $key arguments.

The idea behind this, is to prevent mistakes being made. If you omit the bool env var processor, passing KEY=false will become true-ish and thus mark $key as true.

With the bool env processor, KEY=false becomes false.

It also automatically adds the default:: prefix if the default value of an argument is null.

[smnandre]

I know this is not a "good" practice, but i have use multiple times the following method to "feature-flag" some services.

SERVICE_SUPER_KEY=my_super_key

[Autowire(env: 'SERVICE_SUPER_KEY')] bool $superServiceEnabled

With your PR that would create the opposite problem of your example :|

🤷

[nicolas-grekas]

@smnandre your use case could be covered if the code for the bool processor were doing this in EnvVarProcessor:

filter_var($env, \FILTER_VALIDATE_BOOL, \FILTER_NULL_ON_FAILURE) ?? filter_var($env, \FILTER_VALIDATE_INT, \FILTER_NULL_ON_FAILURE) ?? filter_var($env, \FILTER_VALIDATE_FLOAT, \FILTER_NULL_ON_FAILURE) ?? true

Worth considering?

[nicolas-grekas]

Similarly, we could also add default:: to nullable parameters, WDYT?

[smnandre]

Worth considering?

As i said, this usage was a bit hacky, so we can "ignore it", but that will deserve some warning / upgrade mentions, no ?

[fabpot]

It makes sense to me but the changelog should explain a bit more the change and the new behavior.

[nicolas-grekas]

I finished the PR, improving the logic a bit and adding support for default:: when a parameter defaults to null.

[fabpot]

Thank you @ruudk.