[RFC] Implicit isset() in Shorthand Ternary Operator

I've played around with this branch for a bit and seems reasonable, passes the tests, and doesn't seem to have any serious issues/memories leaks AFAICT. I can't stress enough, however, how important it is for us to avoid inconsistencies in behavior between various forms of syntax. This is often something users complain of as often they complain about not getting such features. So let's make ternary consistent before we implement yet another oddity in PHP (half-assed and ill designed). I don't actually agree with the premise that ternary should wrap the first operand in empty() to begin with, but if this is what people want, fine. Let's just do it right. And as Rasmus mentioned in the PR, make the documentation very _cleary_ if it gets accepted. On Sun, Sep 7, 2014 at 6:30 AM, Pierre Joye <pierre.php@gmail.com> wrote:

Matthew Fonda wrote (on 17/09/2014):

Funnily enough, the standard library at my workplace has long included a coalesce() function as below, which is indeed very handy; there is also a coalesce_empty(), which calls empty($arg) instead of is_null($arg). Both pre-date the shorthand ?: operator, which could replace coalesce_empty(); the proposed ?? could replace coalesce() As mentioned in the PHPDoc, the downside of a function is that it can't short-cut evaluation if the first argument passes, whereas an operator can. It would be possible to work around this by defining a special "language construct" rather than a real function, but that's probably more confusing than it's worth. The special case for $first is a performance optimisation because func_get_args() has rather a lot of overhead; I'm guessing 5.6's variadic signatures ($args...) are less painful (can anyone confirm?) /** * coalesce * PHP analogue of the SQL Coalesce() function * @param an arbitrary number of arguments * @return the first argument which is not NULL; If all arguments are NULL, will return NULL * * coalesce( $a, $b ) is equivalent to ($a === NULL ? $a : $b) * but coalesce( hard_work(), 'default' ) only has to do hard_work() once * [OTOH, coalesce( $a, hard_work() ) has to do hard_work() even if the result gets thrown away] */ function coalesce($first) { if (!is_null($first)) { return $first; } foreach ( func_get_args() as $arg ) { if ( ! is_null($arg) ) { return $arg; } } }

On Sep 17, 2014, at 11:40, Matthew Fonda <mfonda@php.net> wrote:

I’m STRONGLY +1 in favor of this operator, ASAP; I’ve had to write more than a few hacks to keep a large codebase I’m responsible from being a complete mess of isset() checks - 5.6 has saved me a lot of what used to be ugly workarounds (variadic functions anyone?), but this one still haunts me. I would argue for both coalesce() (as a language token) and ?? and ??=, as shorthand forms, giving the user a choice as to which they find more readable. ?? is standard in both .NET and Apple’s Swift language - Apple added it to Swift (including the chaining behavior) early during the beta cycle due to user demand for exactly this kind of logic, and it’s been part of C# for a long time. -- Gwynne Raskind