Apply strict_types to internal functions

On Tue, Aug 29, 2023 at 2:46 AM Saki Takamachi <saki@sakiot.com> wrote:

Heya! I was not aware that strict types didn't work here. While I'm 100% behind the idea, I am afraid that changing this will break code in currently strict files where the assumption was made that it already worked like that. It would probably have to give deprecation notices first, and then possibly a warning or removal in the next major to be feasible.

Hi, The larger issue is that higher-order functions do not inherit the `strict_types` mode from its calling code, and this is not specific to internal functions. If you intend to change that for internal functions (with proper deprecation period, of course), you might consider making such a behaviour also possible for userland functions (probably using some opt-in); so that future higher-order internal functions do not become impossible to polyfill. —Claude

On 29/08/2023 01:46, Saki Takamachi wrote:

Just to be really clear, it is not true that internal functions "ignore" the setting; they behave exactly the same as any userland function which was *declared* in strict_types=0 mode. The warning in the manual is actually a consequence of the following Note (perhaps the order should be reversed?): 1. Strict typing applies to function calls made from within the file with strict typing enabled 2. Function calls from within internal functions will not be affected by the |strict_types| declaration To clarify the scenario, imagine three files: /* a.php */ declare(strict_types=0); function call_me_back(callable $f, mixed $input) {     $f($input); } /* b.php */ declare(strict_types=1); function output_me(string $output) {     echo "$output\n"; } /* c.php */ declare(strict_types=1); call_me_back( output_me(...), 42 ); The only calls that happen are: 1. A call from c.php to call_me_back; c.php is in strict_types=1 mode, so the parameters $f and $input will not be coerced 2. A call from a.php to output_me; a.php is in strict_types=0 mode, so the parameter $output *will* be coerced to a string The behaviour of internal functions like array_filter is exactly the same - array_filter is  the caller, and it is defined in strict_types=0 mode, just like call_me_back above; the mode set in any other code is irrelevant, because it is not the caller. As Claude Pache, it's actually very difficult to design a version of the feature that would be fully intuitive in this case - if I write the below, does the caller of wrapped_array_filter still get to control the mode that call_me_back is run under? function call_me_back(int $value) {     return $value <= 42; } function backwards_array_filter(array $array, ?callable $callback = null, int $mode = 0): array {     return array_reverse(   array_filter($array, $callback, $mode)   ); } // In another file: var_dump( backwards_array_filter($some_array, call_me_back(...)) ); Regards,