Strict types hide and mask a lot of errors if not used correctly (((int) null) === 0 && ((string) null === '') for example, where a null would -- and probably should -- be an error). At the same time, PHP coercion is exceptionally well-documented and predictable. This is our reason for not using strict types, but I understand many people live by it.

Env variables are strings (at least in Linux) by default and will be passed as such. However, there's no way to cast these strings to ints, and due to strict types, they will not be coerced as expected:

ConnectionOptions::class => \DI\autowire( ConnectionOptions::class )
->constructorParameter( 'host', \DI\env( 'DATABASE_HOST' ) )
->constructorParameter( 'port', \DI\env( 'DATABASE_PORT' ) )
->constructorParameter( 'db', \DI\env( 'DATABASE') )
->constructorParameter( 'user', \DI\env( 'DATABASE_USER' ) )
->constructorParameter( 'password', \DI\env( 'DATABASE_PASSWORD' ) ),

This will fail to be constructed unless the programmer accepts a string for port, which would be pretty silly. Strict types apply on the caller, not the receiver, and only applies to scalar values as object values are always strict by default.

Since strict types only applies to scalar values and only when calling a function from that file, there are only several function calls where this applies in the entire file ObjectCreator.php, one of those being the constructor itself. It doesn't do any reflection actually to validate/cast the type either, so this will naturally fail:

Argument #2 ($port) must be of type int, string given, called in /app/vendor/php-di/php-di/src/Definition/Resolver/ObjectCreator.php on line 129

This library would be far more flexible and valuable to avoid strict types in this file, as it doesn't have much-realized value.