# PHP7 Coalesce operator - Thread: https://externals.io/message/89292 - Original archive: https://news-web.php.net/php.internals/89292 - Started by shadda on 2015-11-22T09:15:41+00:00 - Messages: 11 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #89292 — shadda — 2015-11-22T09:15:41+00:00 URL: https://externals.io/message/89292#89292 Hey all. Been a while since I popped into this list. You may remember me from such emails as “Why god can’t we have namespaces”, or “so we’re still not fixing strpos, eh?” I had a question-suggestion based around the cool new operator we’re getting in PHP7, the ?? operator, which as I understand it is the functional equivalent to perl’s // operator; in that they both test for whether or not a variable is defined, rather than it’s truthiness. That’s all well and good, but one of the things that makes the || operator in javascript so handy is that definedness and truthiness go hand in hand, and an undefined value will simply evaluate to null/false, making things like (foo || false || true) possible, which is quite handy in a lot of situations. It seems like if we already have a construct in place that’ll bypass raising an E_NOTICE, it should possible to implement a secondary operator that tests for truthiness with similar semantics. Something like, $config->auto_play = $config->auto_play ?! $defaults->auto_play ?! false; Do you feel me? Guys? -M --- ## #89295 — Andrea Faulds — 2015-11-22T20:41:59+00:00 URL: https://externals.io/message/89292#89295 · In reply to: #89292 Hi, shadda wrote: > I had a question-suggestion based around the cool new operator we’re getting in PHP7, the ?? operator, which as I understand it is the functional equivalent to perl’s // operator; in that they both test for whether or not a variable is defined, rather than it’s truthiness. This is not strictly correct. Though something of a misnomer, the 'null coalesce operator' checks if a variable doesn't exist, but also that it is not null, i.e. it functions like isset(). Thanks. -- Andrea Faulds http://ajf.me/ --- ## #89344 — shadda — 2015-11-23T19:51:12+00:00 URL: https://externals.io/message/89292#89344 · In reply to: #89295 Hey, thanks for responding. However, I still think that misses the point, or at least the true utility of what I’m proposing. In practice, you can ignore `E_NOTICE` and php will happily treat null and !isset() as the same thing in *most* cases, so that’s not a good indicator of truthiness. Basically in ECMA, anything non-null, false, or undefined is true. PHP is very similar in that regard, but our reliance on `E_NOTICE` to (ahem) enforce isset() checks is why, I assume, we’re introducing the ?? operator to begin with. I just think it’d be nice to have a small variation on this feature that was less concerned with a (defined|null) semantic and more in keeping with PHP’s overall handling of implicit type conversion in expressions. Does that make more sense? > > > Hi, > > shadda wrote: > > […] > > This is not strictly correct. Though something of a misnomer, the 'null coalesce operator' checks if a variable doesn't exist, but also that it is not null, i.e. it functions like isset(). > > Thanks. > > -- > Andrea Faulds > http://ajf.me/ --- ## #89345 — shadda — 2015-11-23T19:52:29+00:00 URL: https://externals.io/message/89292#89345 · In reply to: #89344 Er, that should read, “anything non (null, false, undefined) is true” > > > Hey, thanks for responding. > > However, I still think that misses the point, or at least the true utility of what I’m proposing. > > In practice, you can ignore `E_NOTICE` and php will happily treat null and !isset() as the same thing in *most* cases, so that’s not a good indicator of truthiness. > > Basically in ECMA, anything non-null, false, or undefined is true. PHP is very similar in that regard, but our reliance on `E_NOTICE` to (ahem) enforce isset() checks is why, I assume, we’re introducing the ?? operator to begin with. > > I just think it’d be nice to have a small variation on this feature that was less concerned with a (defined|null) semantic and more in keeping with PHP’s overall handling of implicit type conversion in expressions. > > Does that make more sense? > > > […] --- ## #89346 — Levi Morrison — 2015-11-23T20:03:46+00:00 URL: https://externals.io/message/89292#89346 · In reply to: #89344 > In practice, you can ignore `E_NOTICE` and php will happily treat null and !isset() as the same thing in *most* cases, so that’s not a good indicator of truthiness. If you really believe that then this is all you need already: $database = $config['database'] ?: 'db'; Correct? --- ## #89347 — Phil Sturgeon — 2015-11-23T20:08:10+00:00 URL: https://externals.io/message/89292#89347 · In reply to: #89345 > Er, that should read, “anything non (null, false, undefined) is true” > > > […] > > > -- > > > Ignoring `E_NOTICE` is generally considered bad practice by many, and turning them off just to use ternaries instead of null coalesce (a feature we already have) doesn't seem like a benefit. The ?? is used the same as "a = b || c" in Ruby or JS. Doing that in PHP wouldn't work well as || works a bit differently, so ?? is used instead, just like C and Swift. Basically... it's all good. And even if you hate it you're months too late to raise a concern. :) --- ## #89348 — shadda — 2015-11-23T20:12:22+00:00 URL: https://externals.io/message/89292#89348 · In reply to: #89346 Oh, please, by no means take that as an endorsement for dropping error reporting levels. It was just an observation of how PHP actually derives a conditional in those situations. It’s not as if there’s a fatality in script execution when you make that kind of comparison, it’s just a really shitty way to code. In fact, it’s also why i typically avoid empty(). Nevertheless, PHP lacks a concise solution for dealing with multiple possibly-false-evaluating values. Hacks like my coalesce() function that rely on the side effect of reference-passing can only go so far, as there’s also no way to pass &N references (at least that I’m aware of, correct me if I’m wrong) I mean really I just want to be able to easily and lazily handle situations where I’ve got several vars as possible values in an assignment or expression, without chaining lots of function calls. Perhaps if empty() took N params like isset() does, but that’s only a nudge in the, er, “right” direction. > > > > […] > > > If you really believe that then this is all you need already: > > $database = $config['database'] ?: 'db'; > > Correct? --- ## #89349 — shadda — 2015-11-23T20:16:19+00:00 URL: https://externals.io/message/89292#89349 · In reply to: #89347 It’s not hate, I happen to like that ?? was added. I’m not raising a concern nor asking for a change in its behavior. Rather, I’m asking for another, similar operator that’s based on truth-evaluation (with PHP’s tender, loving conversion rules baked in), in *addition* to ?? which tests for null/undefined exclusively. > > > > > […] > > Ignoring `E_NOTICE` is generally considered bad practice by many, and > turning them off just to use ternaries instead of null coalesce (a > feature we already have) doesn't seem like a benefit. > > The ?? is used the same as "a = b || c" in Ruby or JS. Doing that in > PHP wouldn't work well as || works a bit differently, so ?? is used > instead, just like C and Swift. > > Basically... it's all good. And even if you hate it you're months too > late to raise a concern. :) --- ## #89350 — Ryan Pallas — 2015-11-23T20:52:28+00:00 URL: https://externals.io/message/89292#89350 · In reply to: #89349 Well use null coalesce + elvis together then? // Coalesce possible null values, and use truthy comparison in elvis to "coalesce" to a default $var = ($_GET['possible_value'] ?? $_COOKIE['secondary'] ?? false) ?: DEFAULTS['var']; > It’s not hate, I happen to like that ?? was added. I’m not raising a > concern nor asking for a change in its behavior. Rather, I’m asking for > another, similar operator that’s based on truth-evaluation (with PHP’s > tender, loving conversion rules baked in), in *addition* to ?? which tests > for null/undefined exclusively. > > > > […] > wrote: > > […] > utility of what I’m proposing. > > […] > and !isset() as the same thing in *most* cases, so that’s not a good > indicator of truthiness. > > […] > is very similar in that regard, but our reliance on `E_NOTICE` to (ahem) > enforce isset() checks is why, I assume, we’re introducing the ?? operator > to begin with. > > […] > that was less concerned with a (defined|null) semantic and more in keeping > with PHP’s overall handling of implicit type conversion in expressions. > > […] > getting in PHP7, the ?? operator, which as I understand it is the > functional equivalent to perl’s // operator; in that they both test for > whether or not a variable is defined, rather than it’s truthiness. > > […] > 'null coalesce operator' checks if a variable doesn't exist, but also that > it is not null, i.e. it functions like isset(). > > […] --- ## #89351 — shadda — 2015-11-23T21:02:16+00:00 URL: https://externals.io/message/89292#89351 · In reply to: #89350 That’s not a bad idea, but it’s still limited in certain cases, where your list of possibles is, lets say, complex. At this point, I think you guys get what I’m after, and I’m wondering if anyone else finds the idea as useful I as do. In fact, if it didn’t break the One Law of PHP (thou shalt not break BC), I might even suggest just giving ?: the same super power as ??, in not throwing a notice. > > > Well use null coalesce + elvis together then? > > // Coalesce possible null values, and use truthy comparison in elvis to "coalesce" to a default > $var = ($_GET['possible_value'] ?? $_COOKIE['secondary'] ?? false) ?: DEFAULTS['var']; > > > It’s not hate, I happen to like that ?? was added. I’m not raising a concern nor asking for a change in its behavior. Rather, I’m asking for another, similar operator that’s based on truth-evaluation (with PHP’s tender, loving conversion rules baked in), in *addition* to ?? which tests for null/undefined exclusively. > > > > […] > > > -- > > That’s not a bad idea, but it’s still limited in certain cases, where your list of possibles is, lets say, complex. > At this point, I think you guys get what I’m after, and I’m wondering if anyone else finds the idea as useful I as do. > > In fact, if it didn’t break the One Law of PHP (thou shalt not break BC), I might even suggest just giving ?: the same super power as ??, in not throwing a notice. This is what my RFC for the null coalesce operator was originally going to do: make ?: use empty(). However, it was deemed a better idea to add a new operator, ??, which uses isset(), since a falsy value != a missing value. Thanks. -- Andrea Faulds http://ajf.me/