My point was that if the ternary conditional is an lvalue, then I don't see why not to make the '||' and '//' operators lvalues. It would result in better consistency. | [reply] |
... implementing the "Elvis operator" ... as $x ? $x : $y
Actually, I read the opposite from the Wiki article:
... the Elvis operator expression A ?: B is approximately equivalent to the ternary conditional expression A ? A : B
... something like ... x = f() ?: g()
... is equivalent to ... the conditional ternary operator x = f() ? f() : g()
except that it does not evaluate f() twice if it yields truthy.
Accentuations by me.
Greetings,
🐻
$gryYup$d0ylprbpriprrYpkJl2xyl~rzg??P~5lp2hyl0p$
| [reply]
[d/l]
[select] |
That makes PHP's Elvis operator a value-preserving logical-OR operator, like Perl's ||.
According to the article, || also has this function in Common Lisp, Clojure, Lua, Object Pascal, Python, Ruby, and JavaScript. It's rather disingenuous to call the article "Elvis operator".
In C, || is normalizes the value to 0 or 1.
| [reply]
[d/l]
[select] |
In retrospective, I shouldn't have brought up || as I don't see any use for an lvalue expression X || Y neither, which would be equivalent to the "Elvis operator".
A possible novelty could be a binary operator that:
- acts like defined(X) ? X : Y
- yields an lvalue, provided X and Y are lvalues
- evaluates X only once
If X // Y was an lvalue, it would satisfy these criteria.
As it currently isn't, it could hardly break anything as such usage doesn't compile.
No new operator, just an extension.
In a Perlish sense: One more way to do it.
Greetings,
🐻
$gryYup$d0ylprbpriprrYpkJl2xyl~rzg??P~5lp2hyl0p$
| [reply]
[d/l]
[select] |