Re: [RFC] Allow non-variable arguments to empty() and isset()

>> I just can't help feeling that it is the wrong use of both. If the function >> is returning a value, then it's returning a value that needs to be used >> somewhere so the work flow handles that. If the function returns nothing >> instead that just seems wrong and needs to be handled better. I'm used to >> getting back 'false' if the function failed and just check for that so why >> would there be any logical reason for using isset or empty to check a >> function return? > > Use case: > > // Function definition: > function getFriends() > { >    // SQL SELECT or Fetching from XML or Fetching from LDAP or .... >    return $resultsAsArray; > } > > // Looping on results: > foreach ( getFriends() as $friend ) > { >    echo $friend["name"], "\n"; > } > > // Case where the results are actually not iterated: > $amIAssocial = empty( getFriends() ); This is the exact same thing: $amIAssocial = !getFriends(); Earlier, I sent this to Lester only: Most people don't realize that an empty array is already falsy so they feel the need to use empty. That is the only use-case the RFC gives for making this change. From the RFC: "For example if func() is expected to return an array, it feels more natural to verify it's emptiness using empty() instead of !." -- Herman Radtke hermanradtke@gmail.com | http://hermanradtke.com