Description
Description
To increase uptake and compatibility strict_types=1
currently already will only apply to function calls from within a file that declares it.
Most PHP applications provide filterables (e.g. WordPress' apply_filters
for example), which calls callbacks using call_user_func(
. Unfortunately, this means, that any 3rd party code can alter the filterable value/type, which then results in a fatal type error in our code.
Essentially, this resulted in lots of support tickets for us, caused by buggy 3rd party code - which wasn't our fault and we couldn't do anything about - except removing strict_types again from our own code.
<?phpdeclare(strict_types=1); functionbad_3rd_partycode( $p ) { returnnull; } functionmy_code( string$path ): string { if ( is_file( $path ) ) { unlink( $path ); } return''; } $value = 'foo.log'; $value = call_user_func( 'bad_3rd_partycode', $value ); echocall_user_func( 'my_code', $value );
Fatal error: Uncaught TypeError: my_code(): Argument #1 ($path) must be of type string, null given
This, I assume, is one of the reasons, for the relatively low use of strict_types in non-standalone applications - essentially, you're being punished for someone else's mistakes.
I think it would make sense if either:
- there was a strict_types=2, that would be essentially like strict_types=0 if a function is called from
call_user_func
Pro: explicit and no change for existing code
Con: not backwards compatible with older PHP versions, which means nobody will use it
- or strict_types=1 would by default ignore strict_types if a function is called from
call_user_func
(and there is a strict_types=2 added, to keep/enforce the current functionality of strict_types=1)
Pro: fully backwards compatible
Con: makes type checking weaker and requires change of strict_types=1 to strict_types=2 for those who do not want to allow weaker checks - which however, is something that takes 1 min to achieve (just search/replace all files in your code with a simple sed
)
I assume this would require an RFC?