Am 11.07.2018 um 18:20 schrieb Levi Morrison:

As an example, it was claimed:

If I use a function I expect it to give me a return value which I can
use without any further post processing $wantedValue =
But this isn't true even for the array_value_* functions. There must
be pre or post processing because of error conditions. This was
pointed out by myself and others, but it was still ignored.

This is what I mean by discarded, not discussed.

In my eyes being aware of what I put into a function and thus catching non array inputs and empty inputs before differs a lot from post processing return values as it increases the comprehensibility of the code. I also can think of cases where the input format is known and no further checks are required.

Additionally the tuple return pattern is not common among the PHP core functions and I don't know many occurences of this pattern in userland PHP code neither at the companies I've worked at nor at open source software/frameworks (correct me if I'm wrong) except the by far outdated old foreach construct with reset() and each(), thus I assume it's not a that common pattern for PHP developers to use it in core functions.

As I pointed out during the discussion we should also watch at existing functions with the same problem, differ between a valid return value and an error. Not all of them can be changed to use different return mechanisms like the tuple return pattern (eg. array_pop).

Maybe we can instead think about changing Z_PARAM_ARRAY_EX in a later stage to not return null in error cases but instead throw an InvalidArgumentException or something like that (at least for function calls with an empty array for functions which require a filled array, for invalid types maybe a fatal TypeError like it's thrown when a type hinted argument in a userland function is violated is the correct choice). Would be a pretty large BC breaking change but it would be consistent among the array functions.

In my opinion neither rejecting the RFC nor changing it to return tuples solves the underlying problem.

PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:

Reply via email to