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
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: http://www.php.net/unsub.php