<p>So things like the null coalescing operator make it easier to chain things, so if you have a number things to fall back on, it's much neater to write:</p>

<pre><code>{% set woof = bark ?? howl ?? growl ?? null %}
</code></pre>

<p>...then it is to try to chain that all together with <code>| default</code> filters.</p>

<p>Something that may also make your life easier is the <a href="https://github.com/nystudio107/craft-emptycoalesce" rel="nofollow noreferrer">Empty Coalesce plugin</a>, so you can write:</p>

<pre><code>{% set woof = bark ??? howl ??? growl ??? null %}
</code></pre>

<p>What's the difference? The null coalescing operator only checks for <code>null</code>, so if <code>bark = ""</code> then it'll choose that, which often isn't what you want for strings.</p>

<p>There's a writeup of all of this in <a href="https://nystudio107.com/blog/handling-errors-gracefully-in-craft-cms#coalescing-the-night-away" rel="nofollow noreferrer">Handling Errors Gracefully in Craft CMS</a> article.</p>

<p>Now, what is going to be more performant? Unless you're in a massive inner loop (which we should avoid in a templating language anyway), I doubt it'll matter. PHP code is transpiled to a bytecode that often gets cached, it should be fine.</p>

<p>But in theory, <code>??</code> and <code>???</code> are probably marginally faster.</p>

CC BY-SA 4.0
2018-09-22T08:22:27.483Z
So am I right in thinking that if I don't want any fallback options the default filter is the best choice to test for existence of anything usable? I'd rather not be reliant on a third party plugin if I didn't need to, but if I did need to I'd be happy if it was one of yours. I had read your excellent Handling Errors article but wasn't 100% sure it was all valid for Craft 3, as there are so many small subtle changes that are easy to miss when moving from Craft 2.
Paul Frost
CC BY-SA 4.0
2018-09-24T14:35:57.217Z
Use whatever is the most readable to you, imo. That "Handling Errors" article was written for Craft 3, but it applies for Craft 2 as well. I think it's totally fine and understandable to just use the `default` filter if your case is simple.
andrew.welch
CC BY-SA 4.0
2018-09-21T13:52:59.553Z
2018-09-21T13:52:59.553Z
andrew.welch
<p>When testing for a variable in a template these two appear to do the same thing. I've read CruftlessCraft's article on <a href="https://cruftlesscraft.com/how-to-check-for-undefined-variables" rel="nofollow noreferrer">How to check for undefined variables</a> but can't see an explanation of why I should use one over the other. In his examples (below) I note that only the default filter includes "" in the list of results, is that correct or significant?
Is one faster or more efficient?</p>

<pre><code>{% if twigVariable|default %}
    Value is set and not empty
{% else %}
    Value is either undefined, false, 0, null, "", [] or {}
{% endif %}
</code></pre>

<p>or</p>

<pre><code>{% if twigVariable ?? false %}
    The value is set and not empty
{% else %}
    Value is either undefined, false, 0, null, [] or {}
{% endif %}
</code></pre>

<p>Does it make any difference if I don't need a fallback or the else and am just wrapping it around a div that shouldn't be shown if the variable doesn't have any usable content?</p>

<conditional><variable>
Twig default filter or Null coalescing operator?
# Twig default filter or Null coalescing operator?

(Asked by: username_0 on 2018-09-21)

When testing for a variable in a template these two appear to do the same thing. I've read CruftlessCraft's article on How to check for undefined variables but can't see an explanation of why I should use one over the other. In his examples (below) I note that only the default filter includes "" in the list of results, is that correct or significant?
Is one faster or more efficient?
{% if twigVariable|default %}
    Value is set and not empty
{% else %}
    Value is either undefined, false, 0, null, "", [] or {}
{% endif %}

or
{% if twigVariable ?? false %}
    The value is set and not empty
{% else %}
    Value is either undefined, false, 0, null, [] or {}
{% endif %}

Does it make any difference if I don't need a fallback or the else and am just wrapping it around a div that shouldn't be shown if the variable doesn't have any usable content?

**Tags:** conditional, variable


---

## 1 answers

### Answer by username_1 on 2018-09-21. Score: 3

So things like the null coalescing operator make it easier to chain things, so if you have a number things to fall back on, it's much neater to write:
{% set woof = bark ?? howl ?? growl ?? null %}

...then it is to try to chain that all together with | default filters.
Something that may also make your life easier is the Empty Coalesce plugin, so you can write:
{% set woof = bark ??? howl ??? growl ??? null %}

What's the difference? The null coalescing operator only checks for null, so if bark = "" then it'll choose that, which often isn't what you want for strings.
There's a writeup of all of this in Handling Errors Gracefully in Craft CMS article.
Now, what is going to be more performant? Unless you're in a massive inner loop (which we should avoid in a templating language anyway), I doubt it'll matter. PHP code is transpiled to a bytecode that often gets cached, it should be fine.
But in theory, ?? and ??? are probably marginally faster.

> **Comments:**
> **username_0**: So am I right in thinking that if I don't want any fallback options the default filter is the best choice to test for existence of anything usable? I'd rather not be reliant on a third party plugin if I didn't need to, but if I did need to I'd be happy if it was one of yours. I had read your excellent Handling Errors article but wasn't 100% sure it was all valid for Craft 3, as there are so many small subtle changes that are easy to miss when moving from Craft 2.  
> **username_1**: Use whatever is the most readable to you, imo. That "Handling Errors" article was written for Craft 3, but it applies for Craft 2 as well. I think it's totally fine and understandable to just use the `default` filter if your case is simple.  

---

