[RFC] Make empty() a Variadic View as Markdown

Hello Internals!
The following RFC aims to make empty() have a variable arity: https://wiki.php.net/rfc/variadic_empty. This is a simple feature that enables for a short-hand notation of checking multiple expressions for emptiness (which is a pretty common thing to do).
I have avoided including the is_() functions into this RFC because my main priority is to get this particular feature into PHP 7.0 before feature freeze. Provided I have some free time over the next week, I'll write up another RFC + patch to cover the is_() functions.
Thanks,Tom

Hey Leigh,

Hey Tom,

Patch looks solid (basically the same as the isset logic with OR
instead of AND). I think it's fairly sane to have this feature because
it compliments isset functionality (although I dislike "empty"
personally - consistency is nice)

No RFC would be complete without a complaint about naming.
"empty_expressions" ... I'll give you an empty expression!

But overall +1 on functionality and patch.

Cheers!

Leigh.

Thanks for the feedback :)
-Tom

Hey Markus,

From the RFC:

This behaviour seems to be the most prevalent usage of multiple empty
checks in a condition, therefore benefitting the most end users.

Here I disagree.

I would have assumed from the start that empty() would only return true
if all of the entries are empty, i.e. AND things together.

If we enable variable arity then it will join the group of function
where no user sanely can remember if in_array/etc. take the
needle/haystack first or second argument. I.e. whether it will OR or AND
all arguments.

My rationale for this is that empty() performs an inverse check to isset(), so I feel it should have inversed behaviour too (i.e. logically OR'ing its arguments together instead of logically AND'ing them together). To quote what Andrea wrote in the pre-RFC discussion thread:

From: Andrea Faulds> Date: Fri Feb 13 06:31:38 2015>> So !empty($a, $b, $c) would work similarly to isset($a, $b, $c), and similarly, !isset($a, $b, $c) would work similarly to empty($a, $b, $c).
This means that we keep the (rough) equivalence of empty() == !isset() - which is true since a variable that is not set or is null is going to be a falsy value, so both the empty() and !isset() expressions will return TRUE. Likewise for !empty() == isset() - if an argument does not have a falsy value, then empty() will return FALSE. isset() will return TRUE on that same value since a variable cannot be truthy and either not set or null.
Now, if we changed the semantics to how you're seeing them, then we would have the following:<?php$a = true;$b = 'b';// $c;var_dump(empty($a, $b, $c) === isset($a, $b, $c)); // true
This behaviour seems incorrect to me, since both expressions will return FALSE. So how can two constructs that have inverse purposes be equal to each other on the same input?
With the currently proposed behaviour, the empty() expression will return TRUE, whilst the isset() expression will return FALSE, giving the inverse result.
From http://php.net/manual/en/function.isset.php :
"If multiple parameters are supplied then isset() will return TRUE
only if all of the parameters are set. Evaluation goes from left to
right and stops as soon as an unset variable is encountered."

But this is an AND: "... if all ... are set":

"isset($a,$b)" behaves like "isset($a) && isset($b)"

IMHO this absolutely violates your POLA because as I said this is also
how I would assume empty() with variable arguments would work: Only
return true if all are true.
If we had an empty-based function that did not perform a reverse check to isset(), such as not_empty(), then I'd say it should behave like isset():
var_dump(not_empty($a, $b, $c) === isset($a, $b, $c)); // true
But because this is not the case for empty(), I'd say it would be confusing for it to act the same way isset() does.
My personal opinion is that any attempt to change this is ill-fated
because people will no be able to memoize the exact usage of it because
it would mean different things to different people and would just add
more confusion.

My aim is to make empty()'s behaviour intuitive so that users don't have to memorise its semantics.

• Markus

Thanks for your input Markus and I hope you can better see where I am coming from with my current RFC :)

-Tom

// Sorry, having email formatting problems still. Hopefully this one will be more legible.
Hey Markus,

From the RFC:

This behaviour seems to be the most prevalent usage of multiple empty
checks in a condition, therefore benefitting the most end users.

Here I disagree.

I would have assumed from the start that empty() would only return true
if all of the entries are empty, i.e. AND things together.

If we enable variable arity then it will join the group of function
where no user sanely can remember if in_array/etc. take the
needle/haystack first or second argument. I.e. whether it will OR or AND
all arguments.
My rationale for this is that empty() performs an inverse check to isset(), so I feel it should have inversed behaviour too (i.e. logically OR'ing its arguments together instead of logically AND'ing them together). To quote what Andrea wrote in the pre-RFC discussion thread:
From: Andrea Faulds
Date: Fri Feb 13 06:31:38 2015

So !empty($a, $b, $c) would work similarly to isset($a, $b, $c), and similarly, !isset($a, $b, $c) would work similarly to empty($a, $b, $c).
This means that we keep the (rough) equivalence of empty() == !isset() - which is true since a variable that is not set or is null is going to be a falsy value, so both the empty() and !isset() expressions will return TRUE. Likewise for !empty() == isset() - if an argument does not have a falsy value, then empty() will return FALSE. isset() will return TRUE on that same value since a variable cannot be truthy and either not set or null.
Now, if we changed the semantics to how you're seeing them, then we would have the following:<?php$a = true;$b = 'b';// $c;var_dump(empty($a, $b, $c) === isset($a, $b, $c)); // true
This behaviour seems incorrect to me, since both expressions will return FALSE. So how can two constructs that have inverse purposes be equal to each other on the same input?
With the currently proposed behaviour, the empty() expression will return TRUE, whilst the isset() expression will return FALSE, giving the inverse result.
From http://php.net/manual/en/function.isset.php :
"If multiple parameters are supplied then isset() will return TRUE
only if all of the parameters are set. Evaluation goes from left to
right and stops as soon as an unset variable is encountered."

But this is an AND: "... if all ... are set":

"isset($a,$b)" behaves like "isset($a) && isset($b)"

IMHO this absolutely violates your POLA because as I said this is also
how I would assume empty() with variable arguments would work: Only
return true if all are true.
If we had an empty-based function that did not perform a reverse check to isset(), such as not_empty(), then I'd say it should behave like isset():
var_dump(not_empty($a, $b, $c) === isset($a, $b, $c)); // true
But because this is not the case for empty(), I'd say it would be confusing for it to act the same way isset() does.
My personal opinion is that any attempt to change this is ill-fated
because people will no be able to memoize the exact usage of it because
it would mean different things to different people and would just add
more confusion.
My aim is to make empty()'s behaviour intuitive so that users don't have to memorise its semantics.

• Markus
  Thanks for your input Markus and I hope you can better see where I am coming from with my current RFC :)
  -Tom

Hey Dan,

Making it easier to write bad (imo) code does
not seem a good reason for a change.

The point of this language feature isn't to promote or simplify the creation of bad code. Developers can (and will) misuse any feature to write poor code.

The aim of this RFC is to enable developers to write less verbose code for what seems like a common scenario in code bases. Whilst the examples I shows may not be demonstrating the highest quality of code out there, they do show that code does exist (and in popular projects too) that could benefit from having this feature included  into PHP.

cheers
Dan

Thanks,
Tom