# One-line \`if ... then ...\` syntax

**URL:** <https://discourse.julialang.org/t/one-line-if-then-syntax/79573>\
**Category:** Internals & Design\
**Tags:** syntax\
**Created:** [April 16, 2022, 2:27pm UTC](https://discourse.julialang.org/t/one-line-if-then-syntax/79573 "2022-04-16T14:27:12Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![CameronBieganek](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cameronbieganek/32/6915_2.png) [@CameronBieganek](https://discourse.julialang.org/u/CameronBieganek)\
**Post date:** [April 16, 2022, 2:27pm UTC](https://discourse.julialang.org/t/one-line-if-then-syntax/79573/1 "2022-04-16T14:27:12Z")

</div>

Which of the following two options do you prefer for a one-line if-then syntax?

_Poll ([view on site](https://discourse.julialang.org/t/one-line-if-then-syntax/79573/1))_

Related Github issue:

[https://github.com/JuliaLang/julia/issues/16389](https://github.com/JuliaLang/julia/issues/16389)

---

<div class="post-metadata">

**Author:** ![cscherrer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cscherrer/32/7631_2.png) [@cscherrer](https://discourse.julialang.org/u/cscherrer)\
**Post date:** [April 16, 2022, 2:39pm UTC](https://discourse.julialang.org/t/one-line-if-then-syntax/79573/2 "2022-04-16T14:39:48Z")

</div>

~~Typo FYI: `if bool then expr end` (you missed `end`)~~

Oh I guess you didn’t mean that, and I totally missed the `then`. IMO it would be too weird to allow `if` without `end`, though an optional `then` could be nice

---

<div class="post-metadata">

**Author:** ![lawless-m](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lawless-m/32/30869_2.png) [@lawless-m](https://discourse.julialang.org/u/lawless-m)\
**Post date:** [April 16, 2022, 5:14pm UTC](https://discourse.julialang.org/t/one-line-if-then-syntax/79573/3 "2022-04-16T17:14:26Z")

</div>

To remove the need for `end` how about Perl’s

`expr unless bool`

or Python’s

`expr if bool`

---

<div class="post-metadata">

**Author:** ![DNF](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dnf/32/10191_2.png) [@DNF](https://discourse.julialang.org/u/DNF)\
**Post date:** [April 16, 2022, 6:08pm UTC](https://discourse.julialang.org/t/one-line-if-then-syntax/79573/4 "2022-04-16T18:08:07Z")

</div>

> [@lawless-m](#):
>
> expr if bool

Not a fan, since this seems to imply that `expr` is evaluated first.

---

<div class="post-metadata">

**Author:** ![jar1](https://avatars.discourse-cdn.com/v4/letter/j/c0e974/32.png) [@jar1](https://discourse.julialang.org/u/jar1)\
**Post date:** [April 16, 2022, 7:00pm UTC](https://discourse.julialang.org/t/one-line-if-then-syntax/79573/5 "2022-04-16T19:00:03Z")

</div>

I think a “familiar vs unfamiliar” poll is usually going to give the “familiar” answer.

The problem with `a && b` is that inconsistent with Julia’s normal rules: it looks like an operator expression but it isn’t: it’s control-flow syntax. That `b` might not be evaluated is the point of this syntax (vs just using `&`). IMO special syntax should look like special syntax to avoid misleading readers.

---

<div class="post-metadata">

**Author:** ![rpmuller](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/rpmuller/32/2262_2.png) [@rpmuller](https://discourse.julialang.org/u/rpmuller)\
**Post date:** [April 16, 2022, 7:37pm UTC](https://discourse.julialang.org/t/one-line-if-then-syntax/79573/6 "2022-04-16T19:37:57Z")

</div>

How about scheme/racket’s

```
(when bool expr)

```

or

```
(unless bool expr)

```

without the parens, of course.

---

<div class="post-metadata">

**Author:** ![Henrique\_Becker](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/henrique_becker/32/15443_2.png) [@Henrique\_Becker](https://discourse.julialang.org/u/Henrique_Becker)\
**Post date:** [April 16, 2022, 7:42pm UTC](https://discourse.julialang.org/t/one-line-if-then-syntax/79573/7 "2022-04-16T19:42:48Z")

</div>

> [@jar1](#):
>
> The problem with `a && b` is that inconsistent with Julia’s normal rules: it looks like an operator expression but it isn’t: it’s control-flow syntax.

…

What looks like special syntax? Words? The same we use as variable names? `&&` and `||` are adopted by many languages working this exact way and are far better to identify and write into text than `and` and `or`.

---

<div class="post-metadata">

**Author:** ![jar1](https://avatars.discourse-cdn.com/v4/letter/j/c0e974/32.png) [@jar1](https://discourse.julialang.org/u/jar1)\
**Post date:** [April 16, 2022, 7:57pm UTC](https://discourse.julialang.org/t/one-line-if-then-syntax/79573/8 "2022-04-16T19:57:10Z")

</div>

[Reserved keywords](https://docs.julialang.org/en/v1/base/base/#Keywords) are special syntax for meta-level programming (except for `true` and `false`, which are special cased).

> This is the list of reserved keywords in Julia: `baremodule, begin, break, catch, const, continue, do, else, elseif, end, export, false, finally, for, function, global, if, import, let, local, macro, module, quote, return, struct, true, try, using, while`. Those keywords are not allowed to be used as variable names.

To be more evidently syntax, these could have been prefixed with `@` such as in `@for` but this may have been considered too noisy.

---

<div class="post-metadata">

**Author:** ![Henrique\_Becker](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/henrique_becker/32/15443_2.png) [@Henrique\_Becker](https://discourse.julialang.org/u/Henrique_Becker)\
**Post date:** [April 16, 2022, 8:22pm UTC](https://discourse.julialang.org/t/one-line-if-then-syntax/79573/9 "2022-04-16T20:22:00Z")

</div>

Exactly my point. The syntax for meta-level programming is just a list of exceptions for the open list of identifiers. I believe it is much more misleading for a novice that an word that could be a variable/function/type/etc name is actually special, and that the only way to know this is knowing the whole list of exceptions. So I do not entirely buy the point that a solution using keywords is better. Finally, `in` is already an exception to complementary idea that operators are restricted to non-letter symbols.

---

<div class="post-metadata">

**Author:** ![jar1](https://avatars.discourse-cdn.com/v4/letter/j/c0e974/32.png) [@jar1](https://discourse.julialang.org/u/jar1)\
**Post date:** [April 16, 2022, 8:25pm UTC](https://discourse.julialang.org/t/one-line-if-then-syntax/79573/10 "2022-04-16T20:25:22Z")

</div>

For simplicity I’d remove the `in`/`isa` exceptions to the infix operator policy rather than using the existence of some exceptions to justify others.

---

<div class="post-metadata">

**Author:** ![DNF](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dnf/32/10191_2.png) [@DNF](https://discourse.julialang.org/u/DNF)\
**Post date:** [April 16, 2022, 9:38pm UTC](https://discourse.julialang.org/t/one-line-if-then-syntax/79573/11 "2022-04-16T21:38:26Z")

</div>

> [@jar1](#):
>
> The problem with `a && b` is that inconsistent with Julia’s normal rules

There’s already `if a b end` and `a && b`. Unless you are suggesting disallowing the latter (how?) the only possibility is to add a third version to the others, that may or may not supplant them (probably not.)

---

<div class="post-metadata">

**Author:** ![Ahmed\_Salih](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ahmed_salih/32/206579_2.png) [@Ahmed\_Salih](https://discourse.julialang.org/u/Ahmed_Salih)\
**Post date:** [April 16, 2022, 9:48pm UTC](https://discourse.julialang.org/t/one-line-if-then-syntax/79573/12 "2022-04-16T21:48:18Z")

</div>

Just to chime in with an opinion.

I don’t always understand the obsession of writing “shorter code”, when most of the work is often having to read it multiple times.

To me, if bool then expr is much clearer than bool && expr.

Code readability is often times a good reason to not improve a package by 5% speed, so I would argue the same is the case here, that increasing the length of the statement to make the code easier to re-read is preferred.

Kind regards

---

<div class="post-metadata">

**Author:** ![jar1](https://avatars.discourse-cdn.com/v4/letter/j/c0e974/32.png) [@jar1](https://discourse.julialang.org/u/jar1)\
**Post date:** [April 16, 2022, 9:51pm UTC](https://discourse.julialang.org/t/one-line-if-then-syntax/79573/13 "2022-04-16T21:51:09Z")

</div>

> [@DNF](#):
>
> There’s already `if a b end` and `a && b` . Unless you are suggesting disallowing the latter (how?) the only possibility is to add a third version to the others, that may or may not supplant them (probably not.)

Yes I am in favor of removing `a && b`, `a || b` in Julia 2.0. Julia has `if` expressions (rather than statements), which removes the need for such special cases.

The same applies to `a ? b : c`.

It would be nice to have block delimiters shorter than ` end`, but that’s a broader issue.

---

<div class="post-metadata">

**Author:** ![CameronBieganek](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cameronbieganek/32/6915_2.png) [@CameronBieganek](https://discourse.julialang.org/u/CameronBieganek)\
**Post date:** [April 16, 2022, 10:33pm UTC](https://discourse.julialang.org/t/one-line-if-then-syntax/79573/14 "2022-04-16T22:33:15Z")

</div>

`if bool expr end` is seldom used, because it’s even harder to read than `bool && expr`. I view `if bool expr end` as more of an artifact of how Julia parsing works than as an actual feature of the language.

`a && b` is certainly not going anywhere, because we still need it for regular old boolean comparison. The fact that `&&` short-circuits is merely a performance optimization. One of the things I don’t like about `bool && expr` is that it is taking a performance optimization and turning it into semantics.

The other thing I don’t like about `bool && expr` is that it is hard to read. It’s not a matter of getting used to it—I’ve seen it plenty of times and I still think it’s harder to read than  
`if bool then expr`.

I’ll note that `if bool then expr` is not quite as easy to read without syntax highlighting as it would be with syntax highlighting. Maybe it’s easier to read with real code, like this:

```julia
if isempty(x) then error("oops.")

```

Here’s an example with syntax highlighting (from a different language, [Elm](https://elm-lang.org/))

![image](https://global.discourse-cdn.com/julialang/original/3X/c/8/c8de24c5c79849509495ec8cb937df352e5d1333.png)

(Elm is a pure functional language, so `if ... then` statements must include an `else`.)

---

<div class="post-metadata">

**Author:** ![jar1](https://avatars.discourse-cdn.com/v4/letter/j/c0e974/32.png) [@jar1](https://discourse.julialang.org/u/jar1)\
**Post date:** [April 16, 2022, 10:56pm UTC](https://discourse.julialang.org/t/one-line-if-then-syntax/79573/15 "2022-04-16T22:56:40Z")

</div>

> [@CameronBieganek](#):
>
> The fact that `&&` short-circuits is merely a performance optimization. One of the things I don’t like about `bool && expr` is that it is taking a performance optimization and turning it into semantics.

I should have specified I favor getting rid of the symbols for short-circuiting control rather than getting rid of boolean operators. Though `∨ ∧` express boolean operations more clearly IMO.

As a side note, AFAIU this _work-reducing_ optimization can sometimes reduce throughput by putting more pressure on the branch predictor. If compute units are available then both branches can be computed simultaneously without extra cost which is helpful if the branch isn’t well predicted.

---

<div class="post-metadata">

**Author:** ![Henrique\_Becker](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/henrique_becker/32/15443_2.png) [@Henrique\_Becker](https://discourse.julialang.org/u/Henrique_Becker)\
**Post date:** [April 17, 2022, 3:20am UTC](https://discourse.julialang.org/t/one-line-if-then-syntax/79573/16 "2022-04-17T03:20:48Z")

</div>

> [@CameronBieganek](#):
>
> The fact that `&&` short-circuits is merely a performance optimization. One of the things I don’t like about bool && expr is that it is taking a performance optimization and turning it into semantics.

I strongly dispute this claim. The introduction of `||` and `&&` in _The C programming language_ of K&R just says:

> The || operator groups left-to-right. It returns 1 if either of its operands compare unequal to zero, and 0 otherwise. Unlike |, || guarantees left-to-right evaluation: the first operand is evaluated, including all side effects; if it is unequal to 0, the value of the expression is 1.

The [wikipedia page on short-circuit evaluation](https://en.wikipedia.org/wiki/Short-circuit_evaluation) says nothing on this. I have a hard time believing that for combining simple relational operators (`<`, `>`, `==`, and `!=`) over primitive data, `&&` and `||` (which may incur in a jump) are more lightweight than `|` and `&` (the simplest possible operations to project in a circuit).

On the contrary, `&&` and `||` short-circuiting behavior are absolutely about semantics. You can see in the K&R quote, they gave a guarantee. If the whole point of `&&` and `||` was not to be short-circuiting they would not even have a reason to exist, because in C any integer greater than zero counts as true, together with `> 0` you could have used `|` and `&` as replacements without loss of anything besides the short circuiting behavior.

`&&` and `||` make much easier write code like `i <= n && a[i] != x`, or `s.tag == X && s.union_value`, or basically any other condition in which the second expression would lead to an access memory violation or undefined behavior if the first expression did not guarantee that it would not. Lots of code rely on this behavior, and I do not believe this is an accident but the original intent of the short-circuiting `&&` and `||`.

> [@CameronBieganek](#):
>
> The other thing I don’t like about `bool && expr` is that it is hard to read. It’s not a matter of getting used to it—I’ve seen it plenty of times and I still think it’s harder to read than  
> `if bool then expr` .

I had the same experience with the `unless` and `when` of Ruby, I always though they were harder to understand than `&&` and `||`. This is anecdotal evidence. Your experience is not universal. But I would argue that `&&` and `||` have the advantage that you just need to think about the truth table and you remember what they are supposed to be doing. Also anecdotal but not having English as my first language I do have much more love for symbols than words in English, which will are often already sufficiently overloaded just for someone trying to learn English.

> [@jar1](#):
>
> As a side note, AFAIU this _work-reducing_ optimization can sometimes reduce throughput by putting more pressure on the branch predictor.

Because it is **not** an work-reducing optimization.

---

<div class="post-metadata">

**Author:** ![DNF](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dnf/32/10191_2.png) [@DNF](https://discourse.julialang.org/u/DNF)\
**Post date:** [April 17, 2022, 6:03am UTC](https://discourse.julialang.org/t/one-line-if-then-syntax/79573/17 "2022-04-17T06:03:27Z")

</div>

> [@jar1](#):
>
> Yes I am in favor of removing `a && b` , `a || b` in Julia 2.0. Julia has `if` expressions (rather than statements), which removes the need for such special cases.
> 
> The same applies to `a ? b : c` .

Wow. There will certainly be some strong opposition to that. This would be terrible. I use these _all the time_.

How will you write

```julia
if a && b || c
    expr
end

```

?  
I also _love_ `a ? b : c`.

> [@Ahmed\_Salih](#):
>
> I don’t always understand the obsession of writing “shorter code”, when most of the work is often having to read it multiple times.

Shorter code can be easier to read than longer code in many cases. This is an idiom you get quickly used to.

> [@CameronBieganek](#):
>
> `if bool expr end` is seldom used, because it’s even harder to read than `bool && expr` .

I just wrote this in one line for convenience. I actually meant

```julia
if bool
    expr 
end

```

---

<div class="post-metadata">

**Author:** ![DNF](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dnf/32/10191_2.png) [@DNF](https://discourse.julialang.org/u/DNF)\
**Post date:** [April 17, 2022, 6:13am UTC](https://discourse.julialang.org/t/one-line-if-then-syntax/79573/18 "2022-04-17T06:13:19Z")

</div>

> [@jar1](#):
>
> Yes I am in favor of removing `a && b` , `a || b` in Julia 2.0. Julia has `if` expressions (rather than statements), which removes the need for such special cases.
> 
> The same applies to `a ? b : c` .

While a good discussion is always fun, I think good to point out that this will never actually happen: [PSA: Julia is not at that stage of development anymore](https://discourse.julialang.org/t/psa-julia-is-not-at-that-stage-of-development-anymore/44872)

> There will be a time when we start working on Julia 2.0, which will include some breaking changes, or we wouldn’t call it 2.0, we would just call it Julia 1.x for some value of x. At that point in time, we can consider breaking changes. But despite what it sounds like, this is not the time to make all the random changes that anyone might want to. Frankly, that time has passed for Julia and will never come again. There will probably be a few renamings of unfortunately named things. But that’s not what the 2.0 release is really about.

Your proposed changes would create such _massive_ havoc throughout the ecosystem that probably more than 90% of code will stop working. There might not be any major packages left standing, and the reputation of the language would be devastated.

Removing `&&` and `||` is basically impossible. The best you could do is introduce a more attractive alternative, and hope that it wins out over time. But so far I haven’t seen any alternatives I would use.

---

<div class="post-metadata">

**Author:** ![Ahmed\_Salih](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ahmed_salih/32/206579_2.png) [@Ahmed\_Salih](https://discourse.julialang.org/u/Ahmed_Salih)\
**Post date:** [April 18, 2022, 11:46pm UTC](https://discourse.julialang.org/t/one-line-if-then-syntax/79573/19 "2022-04-18T23:46:08Z")

</div>

I agree with your point that shorter code can be easier to work with, but for me that has only been the case when:

1. I am deepy engrossed in the code at the moment
2. I understand the “physics” or the math/main idea behind the code

The moment one has to handle a handover or look at the code a few months down the line, then I find that often I would have to write a lot of comments to remind me about the purpose of variables/functions.

Kind regards

---

<div class="post-metadata">

**Author:** ![maxkapur](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/maxkapur/32/21208_2.png) [@maxkapur](https://discourse.julialang.org/u/maxkapur)\
**Post date:** [April 19, 2022, 12:08am UTC](https://discourse.julialang.org/t/one-line-if-then-syntax/79573/20 "2022-04-19T00:08:41Z")

</div>

I won’t take a side here, but one limitation of the `&&` syntax that I have encountered is when trying to assign default values in a function definition:

```julia
function foo(x::AbstractVector, m::Union{Nothing,Int}=nothing)
    if m === nothing
	     m = length(x)
    end
	
    return sum(x[1:m])
end

```

works fine.

```julia
function bar(x::AbstractVector, m::Union{Nothing,Int}=nothing)
    m === nothing && m = length(x)
	
    return sum(x[1:m])
end

```

is an

```julia
ERROR: syntax: invalid assignment location "(m === nothing) && m" around REPL[1]:10

```

and rightly so! `m = length(x)` returns `length(x)` (an `Int`), not a `Bool`.

I guess if you really want a one-liner and don’t like `if a b end` you can use the following:

```julia
function bar(x::AbstractVector, m::Union{Nothing,Int}=nothing)
    m === nothing ? m = length(x) : nothing
	
    return sum(x[1:m])
end

```

(Purists may prefer `isnothing(m)`.)

[Next page](https://discourse.julialang.org/t/one-line-if-then-syntax/79573.md?page=2)