Looking at the code, it looks more intended than a bug.

I'd like to close this one. null is a "special" value that is not cast by casting env var processors. WDYT @nicolas-grekas?

You should use an explicit default fallback param instead of trying to rely on casting null:

parameters:
    bool_flag_default_value: false

services:
    \EnvironmentService:
        arguments:
            $boolFlag: '%env(bool:default:bool_flag_default_value:OPTIONAL_ENV_VAR)%'

Plz close the issue if it works (I didn't test it 😅) and if you think it's good enough 😄

alternatively, dont use 'optional envs' :)

You should use an explicit default fallback param instead of trying to rely on casting null

I know that is a possibility, but it's pretty verbose to be honest. And that was the reason why I wanted to try if it could be made simpler and shorter. Something like this would be ideal and explicit.

services:
    \EnvironmentService:
        arguments:
            $boolFlag: '%env(bool:default:bool(false):OPTIONAL_ENV_VAR)%'

Having to define a separate parameter only to pass it to a single place is not great ux imo.

But to reiterate from the beginning, when I initially came across this, my reaction was "okay, this is how it works, but it's not really clear from the documentation", hence symfony/symfony-docs#18283 which I made first before being suggested to create a bug report. So in my view it's now one of:

• merge the documentation PR to make it explicit that null can be a result of the typecast-processor when used with default, or
• change the behavior so that typecast processors always return non-nullable values.

alternatively, dont use 'optional envs' :)

Is this tongue-in-cheek or serious? Having optional options for the app behavior is often necessary, and especially when the app is packaged in a Docker image, environment variables are the way to pass the configuration options in. Of course, another way would be generating a file in the image entrypoint but that seems to me to just add a layer of complexity for not really a good reason.

i'm serious :) default hides undefined envs

If the env var gets somehow unset, you wouldn't know ... which IMHO is a footgun.

Having optional options for the app behavior is often necessary

why?

Please let's keep this discussion focused, it's not the place to push anyone's personal preferences.
Using optional env vars is supported and perfectly fine.