[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.

Hi Andrea,

Good evening,

I’ve written an RFC and working patch which attempt to add this feature
which has been often requested: https://wiki.php.net/rfc/isset_ternary

I did not look at the patch yet but I like it from a feature point of view.
We should have had this since long :)

Cheers,
Pierre

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

Hi Andrea,

This is great -- thanks to you and Nikita for the work here.

Syntax wise, I would prefer a function-like syntax, e.g. coalesce($a, $b,
'c') or ifsetor() instead of $a ?? $b ?? 'c'. I find this more readable,
and it avoids any possible confusion about precedence within the
expressions. Either way, still +1 for this feature.

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;
  }
  }
  }

--
Rowan Collins
[IMSoP]

Hi Andrea,

This is great -- thanks to you and Nikita for the work here.

Syntax wise, I would prefer a function-like syntax, e.g. coalesce($a, $b,
'c') or ifsetor() instead of $a ?? $b ?? 'c'. I find this more readable,
and it avoids any possible confusion about precedence within the
expressions. Either way, still +1 for this feature.

Best regards,
--Matthew

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

+1 on ?? — there's precedent for it, and it means we don't have to
explain why the shorthand form of an operator behaves differently to
the long form, which is just going to confuse users.

FWIW, it already behaves differently:

oa-res-27-90:~ ajf$ php -r 'function foo() { echo "foo\n"; return true; } $x = foo() ?: false;'
foo
oa-res-27-90:~ ajf$ php -r 'function foo() { echo "foo\n"; return true; } $x = foo() ? foo() : false;'
foo
foo

You could argue whether that's unexpected behaviour or not — there is
only one foo() call in the shorthand version, after all, so it makes
intuitive sense that foo() would only be called once.

Regardless of how you feel about that, though, I don't think
increasing the amount of inconsistency between two versions of the
same operator (forget the implementation; that's how it's documented
and how it's perceived) is a good idea.

Adam

+1 on ?? — there's precedent for it, and it means we don't have to
explain why the shorthand form of an operator behaves differently to
the long form, which is just going to confuse users.

FWIW, it already behaves differently:

oa-res-27-90:~ ajf$ php -r 'function foo() { echo "foo\n"; return true; } $x = foo() ?: false;'
foo
oa-res-27-90:~ ajf$ php -r 'function foo() { echo "foo\n"; return true; } $x = foo() ? foo() : false;'
foo
foo

That's arguable ... I'd say that ($x = foo()) ? $x : false; is the
logical equivalent of your first example.

Cheers,
Andrey.

+1 on ?? — there's precedent for it, and it means we don't have to
explain why the shorthand form of an operator behaves differently to
the long form, which is just going to confuse users.

After a 2nd look I have to agree here too. Changing behavior in
something so widely used as the current operator will likely create
more pains. A new operator, clearly documented, sounds much cleaner,
even more as it does something different anyway.

By popular demand, I’ve changed the RFC to instead propose a ?? operator, after Nikita Popov generously donated a working ?? patch. In doing so, the RFC is renamed “Null Coalesce Operator”.

Please read it: https://wiki.php.net/rfc/isset_ternary

Thanks!

Andrea Faulds
http://ajf.me/

2014-09-17 10:58 GMT+02:00 Sara Golemon php@golemon.com:

As a userland point of view on this: will this have a shorthand? i.e.
what will happen if i leave out the second part?

ie.
$var = $_GET['test'] ?? ;

would that be the same as
$var = @$_GET['test'];

The RFC isnt clear in this regard (or that the righthand side of the
operator is required... maybe it's me ?

The equivalent of your error suppressed example would be:
$var = $_GET['test'] ?? null;

I don't think it gains anyone much to have another form just to save four characters (for the default null).

Someone mentioned an assignment version which isn't covered in niki's patch but would be a fairly trivial addition.

$var ??= expr;

Which essentially means:
if (!isset($var)) {
$var = expr;
}

I'd kinda like that for completeness, but will vote for this with or without the assignment version.

-Sara

Sara,

Indeed that's what i meant. I'm afraid that i just wasn't clear the first time.
But would indeed also like to see the ??= in one go. This would make
the operator a direct first-class citizen of the language instead of
halfway there ;)

Thanks again, i'll butt out now ;)

Robin