> Iâm not sure if this is exactly the same topic, but one problem I have
> with how internal functions are handling arguments is how the absence of an
> optional argument is treated.
> I have stumbled across functions documented as functionname($arg1, $arg2 =
> NULL) which behaves differently when called as functionname('something')
> and functionname('something', NULL).
> A lot of places in the documentation state "if omitted" about an argument..
> This is a big problem when several arguments are optional and you just
> want to provide a value for the last one. You cannot know if giving the
> default value for the ones in between will affect the behavior.
> Shouldnât the argument parsing system treat absence the same as the
> default value?
> This is what happens for userland functions.
This is a somewhat different but closely related problem. The important
thing to understand is that internal functions do not have a native concept
of a default value. If you see a default value in the documentation, that's
On the implementation side, there is basically three ways in which defaults
are typically handled:
* Assigning a default to a zpp variable: Omitting the argument and passing
that default value (but not null!) will behave the same.
* Using a ! specifier: Omitting the argument and passing null will behave
* Checking the number of arguments: Omitting the argument and specifying
it may result in differing behavior.
If you see something that is documented as =null, but does not behave the
same when null is passed, please do report a bug.
The harder question is what to do about cases where the default is
documented as "", and that "" value has abnormal behavior (i.e. is
specially treated in implementation, the behavior does not fall out
"naturally" from the empty string). In that case, I think we should also be
accepting null as a value (independent of strict_types). There are probably
a lot of functions that do this.