Improve strict_types uptake by (optionally) ignoring if called from call_user_func,...

[kkmuffme]

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.

https://3v4l.org/PMSFB#v8.4.6

<?php
declare(strict_types=1);

function bad_3rd_partycode( $p ) {
    return null;
}

function my_code( string $path ): string {
    if ( is_file( $path ) ) {
        unlink( $path );
    }
    
    return '';
}

$value = 'foo.log';
$value = call_user_func( 'bad_3rd_partycode', $value );
echo call_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:

1. 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

2. 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?

[SakiTakamachi]

The actual issue is not with call_user_func(), but whether strict_types=1 is declared in the file where the function is defined.

I had a similar discussion over a year ago, and if we were to introduce strict_types=2, it would risk breaking third-party code, because third-party code cannot predict the strict_types setting of the calling code.

In your case, it seems that you could solve the problem by simply adding a null check for the value returned from the third-party code. Would there be any issues with doing so?

[kkmuffme]

The actual issue is not with call_user_func(), but whether strict_types=1 is declared in the file where the function is defined.

No, it's not, however the actual use case is impossible to show with 3v4l since it needs multiple files, which isn't possible there.
However I see that this is easy to misunderstand what I mean: I meant that if a function is called via call_user_func strict types should be disabled for that function (and all function this function will call) - essentially like if that function were in a separate file, where strict_types is not declared (or declared with 0)

Here's a real world example (this doesn't run standalone but needs wordpress)
my-code.php

<?php
declare(strict_types=1);

function my_code( string $path ): string {
    if ( is_file( $path ) ) {
        unlink( $path );
    }
    
    return '';
}
add_filter( 'wp_delete_file', 'my_code', 20 );

function demo_file() {
    touch( ABSPATH . 'demo.log' );
    wp_delete_file( ABSPATH . 'demo.log' );
}
do_action( 'init', 'demo_file', 10, 0 );

third-party-code.php

<?php
function third_party_code( $path ) {
    return null;
}
add_filter( 'wp_delete_file', 'third_party_code' );

In your case, it seems that you could solve the problem by simply adding a null check for the value returned from the third-party code. Would there be any issues with doing so?

Yes, bc it means I have to add tons of additional code to 1000s of places. In this 1 example it's null, but in other places I would have to check for string/float (since that is commonly incorrectly used where int is expected), plus check for null too.

This also sets a bad precedence: people trying to make code better/stricter are punished for other people's issues.

[SakiTakamachi]

@kkmuffme

Ah, I understand now.

In this case, it’s true that call_user_func() does not enforce strict_types=1 behavior, because it inherits the state from the caller.

However, regardless of strict_types, you still cannot pass a null value here, so fundamentally it doesn’t solve anything.

https://3v4l.org/MIvG4

[kkmuffme]

you still cannot pass a null value here, so fundamentally it doesn’t solve anything.

I do not pass a null value. Someone else's code passes a null value on a filter that is documented as being a string.

The current way to work-around it (only works for non-OOP obviously) is to just put all the add_filter callbacks in a separate file, which does not declare strict_types.

[SakiTakamachi]

What I meant was that if pass null to a callback that specifies a string argument, an error will occur regardless of the strict_types declaration in the file where the callback is defined :)