<p>From Wikipedia:</p>
<blockquote>
<p>In certain computer programming languages, the <a href="https://en.wikipedia.org/wiki/Elvis_operator#" rel="nofollow noreferrer">Elvis operator</a>, often written <code>?:</code>, is a
binary operator that returns its first operand if that operand
evaluates to a true value, and otherwise evaluates and returns its
second operand.</p>
</blockquote>
<p>For example in Kotlin, <code>foo ?: bar</code> will yield <code>foo</code> if <code>foo</code> is not <code>null</code>, and <code>bar</code> if otherwise.</p>
<p>Seeing <a href="https://en.wikipedia.org/wiki/Elvis_operator#Languages_supporting_the_Elvis_operator" rel="nofollow noreferrer">how few languages</a> support this, made me wonder: why don't more languages adopt this operator? AFAIK, short-circuit or <code>||</code> yields the same for <a href="https://en.wikipedia.org/wiki/Elvis_operator#Alternative_syntaxes" rel="nofollow noreferrer">some languages</a>, but in C for example, the result of <code>||</code> will always be a boolean, so it won't work. Also, the Elvis operator looks more concise than short-circuit or <code>||</code> and the ternary counterpart: <code>A ? A : B</code>.</p>
<p>So why is it not more common?</p>

<operators>
Why is the Elvis operator not more common?
CC BY-SA 4.0
2023-05-17T15:12:22.407Z
A null-coalescing operator is rather common ime, it just tends to look different — Swift, JS, and C# all use `??` for that.
Bbrk24
CC BY-SA 4.0
2023-05-17T15:18:34.637Z
@Bbrk24 null-coalescing is a little bit different AFAIK? The Boolean check is now check for non-null.
justANewbie
CC BY-SA 4.0
2023-05-17T15:20:08.577Z
Your Kotlin example is a null-coalescing operator, it just happens to look the same as gcc’s Elvis.
Bbrk24
CC BY-SA 4.0
2023-05-17T15:21:57.663Z
@Bbrk24 all right, it’s my sleep time now so tomorrow I’ll find a better example
justANewbie
CC BY-SA 4.0
2023-05-17T17:26:56.280Z
Many C compilers (GCC and Clang at least) actually add this as an extension. Basically, they let you skip the middle expression in a ternary if, returning the left one if it evaluates to true
abel1502
<p>Some languages simply don't have (a relevant type of) nulls, or don't have the concept of non-Boolean thruthiness, making it a not applicable feature.</p>

CC BY-SA 4.0
2023-05-17T15:27:49.423Z
2023-05-18T05:42:27.573Z
2023-05-18T05:42:27.573Z
Adám
<p>In at least Python, the logical or works in much the same way:</p>
<pre><code>&gt;&gt;&gt; a = None
&gt;&gt;&gt; a or 1
1
&gt;&gt;&gt; a = False
&gt;&gt;&gt; a or 1
1
&gt;&gt;&gt; a = True
&gt;&gt;&gt; a or 1
True
&gt;&gt;&gt; a = &quot;Hello&quot;
&gt;&gt;&gt; a or 1
'Hello'
</code></pre>
<p>I suspect more strongly-typed languages would not be okay with all falsey values being coalesced.</p>

CC BY-SA 4.0
2023-05-17T16:54:15.437Z
2023-05-17T16:54:15.437Z
kouta-kun
CC BY-SA 4.0
2023-05-18T04:07:47.323Z
Strongly-typed languages typically don't have a concept of "falsy" values in the first place ─ "truthiness" means the result of a coercion to a Boolean, and strong typing generally means few or no coercions.
kaya3
CC BY-SA 4.0
2023-05-18T07:57:21.127Z
@kaya3 yet, interestingly a lot of strongly typed languages do actually allow miixing `null` with a different type. Let's say in Java the method `String foo(String s) { return s.toUpperCase(); }` can produce an NPE. Similarly if we go by the signature `String bar();` can also lead to an NPE with `bar().toUpperCase();`. So, even though Java is strongly typed, it does have values that aren't the type you might expect. Which is very close to having concept for "falsy" as most code that consumes `String` should also account for `null`.
VLAZ
CC BY-SA 4.0
2023-05-18T08:06:03.923Z
@VLAZ It's related, but "truthiness" particularly is whether a value satisfies a conditional test in e.g. an `if` statement, `while` loop, or logical operators. In most strongly-typed languages, there is no such concept because the condition must be an actual Boolean value, not just any other type that can be coerced.
kaya3
CC BY-SA 4.0
2023-07-08T18:28:09.673Z
@kaya3-supportthestrike: IMHO, C could have been both more useful and more efficient to process if `x && y` and `x || y` were specified as requiring that `x` and `y` be of compatible types, and be equivalent to `x ? y : x`, and `x ? x : y` , respectively, but with `x` only being evaluated once.  Having the operator coerce the inputs to 0 and 1 creates more work for the compiler while making it necessary for programmers to write code that explicitly uses temporary variables a compiler wouldn't need to bother with (since code would place `x` wherever the code for the containing expression...
supercat
CC BY-SA 4.0
2023-07-08T18:28:47.337Z
...would expect to find it, test its "truthiness", and then either load `y` in the same place or leave that place holding `x`).
supercat
<p>Many popular mainstream languages that focus at least somewhat on conciseness have a similar operator, so I'd say that it <em>is</em> fairly common.</p>
<p>First, some notes:</p>
<ol>
<li>For the purposes of this answer, it doesn't matter whether the syntax is <code>?:</code>, <code>??</code>, <code>||</code> or <code>or</code>, especially since all are equally concise.</li>
<li>What is a &quot;true value&quot; for this operator differs from language to language, and may not be the same as what is considered a &quot;true value&quot; in other contexts (like in an <code>if</code> condition).</li>
</ol>
<p>Now, let's go though some languages and see what we find:</p>
<ul>
<li>C and C++: no Elvis in the standards, since concise syntax sugar does not seem to be focus for these languages</li>
<li>Java: <a href="https://softwareengineering.stackexchange.com/a/359420/213">Elvis was explicitly rejected</a>, seemingly also because syntax sugar is not a focus for Java.</li>
<li>C#: <code>??</code> is a <code>null</code>-checking Elvis</li>
<li>Python: <code>or</code> works as truthy-checking Elvis</li>
<li>JavaScript: <code>||</code> works as an Elvis operator that checks for truthiness, <code>??</code> is an Elvis operator that only checks for <code>null</code> and <code>undefined</code></li>
<li>PHP: <code>?:</code> is a truthy-checking Elvis, <code>??</code> is a <code>null</code>-checking Elvis</li>
<li>Ruby: <code>||</code> works as a truthy-checking Elvis</li>
<li>Go: no Elvis, since Go prefers simplicity of language to conciseness of code</li>
<li>Swift: <code>??</code> is a <code>nil</code>-checking Elvis</li>
<li>Rust: no Elvis, presumably because Rust does not have concepts similar to truthiness or <code>null</code></li>
</ul>

CC BY-SA 4.0
2023-05-17T19:06:55.680Z
2023-05-17T19:06:55.680Z
svick
CC BY-SA 4.0
2023-07-13T19:26:07.810Z
It's worth noting Rust has `.or(...)` for `Option`s, which acts a bit like Elvis for two `Option`-wrapped values: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=b315040c9e8010eba67c001428217f23
rydwolf
# Why is the Elvis operator not more common?
Posted by: username_0 on 2023-05-17
From Wikipedia:

> In certain computer programming languages, the [Elvis operator](https://en.wikipedia.org/wiki/Elvis_operator#), often written `?:`, is a
> binary operator that returns its first operand if that operand
> evaluates to a true value, and otherwise evaluates and returns its
> second operand.

For example in Kotlin, `foo ?: bar` will yield `foo` if `foo` is not `null`, and `bar` if otherwise.

Seeing [how few languages](https://en.wikipedia.org/wiki/Elvis_operator#Languages_supporting_the_Elvis_operator) support this, made me wonder: why don't more languages adopt this operator? AFAIK, short-circuit or `||` yields the same for [some languages](https://en.wikipedia.org/wiki/Elvis_operator#Alternative_syntaxes), but in C for example, the result of `||` will always be a boolean, so it won't work. Also, the Elvis operator looks more concise than short-circuit or `||` and the ternary counterpart: `A ? A : B`.

So why is it not more common?
**Tags:** operators
> **Comments:**
> **username_1**: A null-coalescing operator is rather common ime, it just tends to look different — Swift, JS, and C# all use `??` for that.  
> **username_0**: @Bbrk24 null-coalescing is a little bit different AFAIK? The Boolean check is now check for non-null.  
> **username_1**: Your Kotlin example is a null-coalescing operator, it just happens to look the same as gcc’s Elvis.  
> **username_0**: @Bbrk24 all right, it’s my sleep time now so tomorrow I’ll find a better example  
> **username_2**: Many C compilers (GCC and Clang at least) actually add this as an extension. Basically, they let you skip the middle expression in a ternary if, returning the left one if it evaluates to true  
---
## 3 answers
### Answer by username_8 on 2023-05-17. Score: 10 | Accepted answer
Many popular mainstream languages that focus at least somewhat on conciseness have a similar operator, so I'd say that it *is* fairly common.

First, some notes:

1. For the purposes of this answer, it doesn't matter whether the syntax is `?:`, `??`, `||` or `or`, especially since all are equally concise.
2. What is a "true value" for this operator differs from language to language, and may not be the same as what is considered a "true value" in other contexts (like in an `if` condition).

Now, let's go though some languages and see what we find:

* C and C++: no Elvis in the standards, since concise syntax sugar does not seem to be focus for these languages
* Java: [Elvis was explicitly rejected](https://softwareengineering.stackexchange.com/a/359420/213), seemingly also because syntax sugar is not a focus for Java.
* C#: `??` is a `null`-checking Elvis
* Python: `or` works as truthy-checking Elvis
* JavaScript: `||` works as an Elvis operator that checks for truthiness, `??` is an Elvis operator that only checks for `null` and `undefined`
* PHP: `?:` is a truthy-checking Elvis, `??` is a `null`-checking Elvis
* Ruby: `||` works as a truthy-checking Elvis
* Go: no Elvis, since Go prefers simplicity of language to conciseness of code
* Swift: `??` is a `nil`-checking Elvis
* Rust: no Elvis, presumably because Rust does not have concepts similar to truthiness or `null`
> **Comments:**
> **username_9** (2023-07-13): It's worth noting Rust has `.or(...)` for `Option`s, which acts a bit like Elvis for two `Option`-wrapped values: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=b315040c9e8010eba67c001428217f23  
---
### Answer by username_3 on 2023-05-17. Score: 7
Some languages simply don't have (a relevant type of) nulls, or don't have the concept of non-Boolean thruthiness, making it a not applicable feature.
---
### Answer by username_4 on 2023-05-17. Score: 2
In at least Python, the logical or works in much the same way:
>>> a = None
>>> a or 1
1
>>> a = False
>>> a or 1
1
>>> a = True
>>> a or 1
True
>>> a = "Hello"
>>> a or 1
'Hello'

I suspect more strongly-typed languages would not be okay with all falsey values being coalesced.
> **Comments:**
> **username_5** (2023-05-18): Strongly-typed languages typically don't have a concept of "falsy" values in the first place ─ "truthiness" means the result of a coercion to a Boolean, and strong typing generally means few or no coercions.  
> **username_6** (2023-05-18): @kaya3 yet, interestingly a lot of strongly typed languages do actually allow miixing `null` with a different type. Let's say in Java the method `String foo(String s) { return s.toUpperCase(); }` can produce an NPE. Similarly if we go by the signature `String bar();` can also lead to an NPE with `bar().toUpperCase();`. So, even though Java is strongly typed, it does have values that aren't the type you might expect. Which is very close to having concept for "falsy" as most code that consumes `String` should also account for `null`.  
> **username_5** (2023-05-18): @VLAZ It's related, but "truthiness" particularly is whether a value satisfies a conditional test in e.g. an `if` statement, `while` loop, or logical operators. In most strongly-typed languages, there is no such concept because the condition must be an actual Boolean value, not just any other type that can be coerced.  
> **username_7** (2023-07-08): @kaya3-supportthestrike: IMHO, C could have been both more useful and more efficient to process if `x && y` and `x || y` were specified as requiring that `x` and `y` be of compatible types, and be equivalent to `x ? y : x`, and `x ? x : y` , respectively, but with `x` only being evaluated once.  Having the operator coerce the inputs to 0 and 1 creates more work for the compiler while making it necessary for programmers to write code that explicitly uses temporary variables a compiler wouldn't need to bother with (since code would place `x` wherever the code for the containing expression...  
> **username_7** (2023-07-08): ...would expect to find it, test its "truthiness", and then either load `y` in the same place or leave that place holding `x`).  
---
