# Proposal: \`then\`, \`else\` syntax to replace \`&&\`, \`||\` short-circuiting
**URL:** https://discourse.julialang.org/t/proposal-then-else-syntax-to-replace-short-circuiting/1323
**Category:** Internals & Design
**Created:** [January 6, 2017, 1:33pm UTC](https://discourse.julialang.org/t/proposal-then-else-syntax-to-replace-short-circuiting/1323 "2017-01-06T13:33:30Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@pitao](https://discourse.julialang.org/u/pitao)
#### Post date: [January 6, 2017, 1:33pm UTC](https://discourse.julialang.org/t/proposal-then-else-syntax-to-replace-short-circuiting/1323/1 "2017-01-06T13:33:30Z")
I don’t like short-circuiting. Here’s why:
It is a hack. i.e. It is (ab)using an implementation detail of `&&` or `||`, namely using the fact that the second operand is only evaluated if necessary to provide one-liner `if pred` or `if !pred` statements.
While I do experience a moment of childlike glee whenever I do something ‘clever’, I don’t consider it responsible language design. I teach maths students to prefer elegance over cleverness.
Consider C++ template metaprogramming. An entire meta-language has arisen from [SFINAE](https://en.wikipedia.org/wiki/Substitution_failure_is_not_an_error) – exploiting the fact that Substitution Failure Is Not An Error. It’s incredibly clever. People have got carried away doing absurdly complex operations by exploiting this behaviour. But it is _insanely_ difficult to work with – leading to the poorest productivity I have ever witnessed. Nobody would design this syntax in retrospect.
Ok so I’m using a level 10 awfulness to illustrate a level 1 awfulness. But the point is the same.
My argument is this: short-circuiting creates an extra thing for the new user to have to figure out via RTFM. Also what is written on the page is conceptually far from what is going on so the user has to build brain machinery to handle this. Each time the encounter `pred && statement` they have to say to themselves ‘if pred, do statement’.
What if we provided the following syntax:
```julia
pred then statement
pred else statement
```
Anyone will be able to see that and instantly understand it and apply it elsewhere. No RTFM is necessary. No extra building of machinery is necessary. It is an effortless brain-scan/parse.
(EDIT: JB has shot a hole through using `else` [here](https://github.com/JuliaLang/julia/issues/6823#issuecomment-270955734))
Another syntax idea would be extending the ternary operator to make either branch optional:
```julia
pred ? stA : stB
pred ? stA
pred ? : stB
```
While this might require looking up the `?` operator, it is still a pleasant scan/parse.
It has been suggested to use `pred : stB` for the third option, but that currently parses as a `range`. One solution would be to change the syntax for a range to `a..b` a la Swift. I would be very much in favour of this as again it maps onto an existing concept: we all understand “a = 1…10” as pseudocode. Also it avoids clashing with Python’s `S[a:b]` slicing syntax which actually selects elements `a` through `b-1` not `b`.
I’m writing this in the aftermath of the oh-so-painful [RFC: Make `and` & `or` aliases for `&&` and `||`. #19788](https://github.com/JuliaLang/julia/pull/19788) thread. I think it would be a pity to launch a new language that has `&` bitwise and `&&` sometimes used as straightforward logical and other times in short-circuiting.
I really like the idea of a language that facilitates picking up the syntax just by looking at it.
---
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [January 6, 2017, 1:49pm UTC](https://discourse.julialang.org/t/proposal-then-else-syntax-to-replace-short-circuiting/1323/2 "2017-01-06T13:49:43Z")
AFAIK `&&` and `||` **always** short circuit, not just sometimes. Also, many languages have them, or equivalent forms. See [the table here](https://en.wikipedia.org/wiki/Short-circuit_evaluation).
Just out of curiosity, how would you deal with `a && b && c && d`?
---
### Author:  [@fengyang.wang](https://discourse.julialang.org/u/fengyang.wang)
#### Post date: [January 6, 2017, 1:58pm UTC](https://discourse.julialang.org/t/proposal-then-else-syntax-to-replace-short-circuiting/1323/3 "2017-01-06T13:58:58Z")
I really dislike the proposed `?:` syntax, not only because it is unavailable, but because it is not understandable unless you specifically learn it. By contrast, `&&` and `||` are present (and short circuiting) in many other languages. Making Julia easy to learn for newcomers is important, but we should not sacrifice making it easy to learn for those coming from a programming background already.
I also dislike the idea of removing the short-circuting logical operators. In my opinion, short circuiting logical operators is a very reasonable default; in most situations these operators are used with pure functions, in which case the fact that it is lazy is merely an optimization. Where laziness is semantically important, I think the short-circuiting operators at least have precedent (especially in languages like Perl or Shell).
But personally, I do not see what’s wrong with the slightly more verbose but very readable
```julia
if cond
dosomething()
end
```
instead of the syntax proposals here
```julia
cond then dosomething()
```
I realize that many seem to prefer the style
```julia
cond && dosomething()
```
in a lot of Julia code today, but I dislike this style personally. I feel that it is much clearer (and honestly not that much extra typing) just to write out the `if`.
---
### Author:  [@pfitzseb](https://discourse.julialang.org/u/pfitzseb)
#### Post date: [January 6, 2017, 2:03pm UTC](https://discourse.julialang.org/t/proposal-then-else-syntax-to-replace-short-circuiting/1323/4 "2017-01-06T14:03:07Z")
I agree – this is an issue with the current convention of using `foo && bar()` for control flow instead of the slightly longer `if foo; bar(); end`, not with short-circuiting in itself.
I’d not be averse to something like `if foo then bar()` (à la CoffeeScript), but then again I don’t feel like that really warrants special syntax.
---
### Author:  [@rsrock](https://discourse.julialang.org/u/rsrock)
#### Post date: [January 6, 2017, 2:03pm UTC](https://discourse.julialang.org/t/proposal-then-else-syntax-to-replace-short-circuiting/1323/5 "2017-01-06T14:03:48Z")
The one-liner form does have one nice side-effect. Your code coverage stats don’t take a hit when you check for an unusual error, because the error branch is on the same line.
---
### Author:  [@mkborregaard](https://discourse.julialang.org/u/mkborregaard)
#### Post date: [January 6, 2017, 2:06pm UTC](https://discourse.julialang.org/t/proposal-then-else-syntax-to-replace-short-circuiting/1323/6 "2017-01-06T14:06:07Z")
I really like the idea of using `then` to allow `if` statements to be one-liners and replacing the short-circuiting. It would also solve the issue that @Tamas_Papp points out, in a more readable way than short-circuiting: `if aa && b && c then d` .
Of course there are more complex uses of that latter type of statement using shortcircuiting (i.e. if `c` has side effects) but I don’t think that is very clear coding style.
---
### Author:  [@fengyang.wang](https://discourse.julialang.org/u/fengyang.wang)
#### Post date: [January 6, 2017, 2:06pm UTC](https://discourse.julialang.org/t/proposal-then-else-syntax-to-replace-short-circuiting/1323/7 "2017-01-06T14:06:38Z")
Then, as @pfitzseb mentioned, you could nevertheless use
```julia
if cond; dosomething(); end
```
which is natural. But optimizing the number of lines in an expression for code coverage statistics is in my opinion a weird way to do development.
---
### Author:  [@fengyang.wang](https://discourse.julialang.org/u/fengyang.wang)
#### Post date: [January 6, 2017, 2:07pm UTC](https://discourse.julialang.org/t/proposal-then-else-syntax-to-replace-short-circuiting/1323/8 "2017-01-06T14:07:51Z")
The syntax
```julia
if cond; dosomething(); end
```
is already a one-liner, and not actually longer than
```julia
if cond then dosomething()
```
Furthermore, `;` can be used to make other constructs like `while` and `for` one-liners, so it is a more general solution than `then`. Hence I am not in favour of adding this to the language.
---
### Author:  [@pitao](https://discourse.julialang.org/u/pitao)
#### Post date: [January 6, 2017, 2:08pm UTC](https://discourse.julialang.org/t/proposal-then-else-syntax-to-replace-short-circuiting/1323/9 "2017-01-06T14:08:57Z")
@fengyang.wang I agree with you regarding `?:` – it is an extra thing to be learned.
However, please note that my primary proposal is:
```julia
cond then dosthg()
cond else dosthg()
```
The `then` and `else` tokens could be swapped out for `&&` and `||` internally.
I just threw the `?:` into the mix for completeness.
Given that branching upon conditions is something we do all the time, I would really like these as one-liners. Having to write out an `if ... end` block really goes against Julia’s drive towards concision. I will end up using short-circuits rather than this, even though I dislike them!
@Tamas_Papp my meaning was that `&&` is sometimes _used_ as a 1-line `if`, and other times as a straightforward logical AND. I wasn’t suggesting it behaves differently in different situations, which it doesn’t of course!
---
### Author:  [@Evizero](https://discourse.julialang.org/u/Evizero)
#### Post date: [January 6, 2017, 2:18pm UTC](https://discourse.julialang.org/t/proposal-then-else-syntax-to-replace-short-circuiting/1323/10 "2017-01-06T14:18:51Z")
Speaking on behalf of the lazy typers: please don’t make me type more for little reason 🙂
I find the `&&` and `||` exception-throw-trick quite cute and practical. I’ll also be the first to admit that if these little error checks would take three lines instead of this neat and compact one line, I could see myself considering not doing the check just to keep my function pretty. I am only half joking. Testing for edge conditions is not the fun part of coding and should thus probably not be made more tedious to do than it needs to be.
---
### Author:  [@bramtayl](https://discourse.julialang.org/u/bramtayl)
#### Post date: [January 6, 2017, 2:26pm UTC](https://discourse.julialang.org/t/proposal-then-else-syntax-to-replace-short-circuiting/1323/11 "2017-01-06T14:26:33Z")
Wait, isn’t the point of code coverage to make sure every part of your code is, well, covered?
I’m not too opposed to short circuiting in general. I like the current PR to replace them with and and or for the purpose of literate programing. However, I’m always puzzled by code which uses && and || as control flow operators when if then (the existing multi-line version) works just as well and is a lot more intuitive in that particular use case.
---
### Author:  [@ScottPJones](https://discourse.julialang.org/u/ScottPJones)
#### Post date: [January 6, 2017, 3:12pm UTC](https://discourse.julialang.org/t/proposal-then-else-syntax-to-replace-short-circuiting/1323/12 "2017-01-06T15:12:33Z")
Actually, that’s more of a bug rather than a feature, and it was discussed back in 2015 to get that fixed,
so that when you have flow control (of any sort) that has different paths on one line, or you have things like `&&` and `||` that spread to multiple lines, each part would get marked as covered separately. I’d hoped that that had been fixed already, since it leads to misleading coverage results.
---
### Author:  [@rsrock](https://discourse.julialang.org/u/rsrock)
#### Post date: [January 6, 2017, 3:15pm UTC](https://discourse.julialang.org/t/proposal-then-else-syntax-to-replace-short-circuiting/1323/13 "2017-01-06T15:15:51Z")
Ideally, yes, but there’s a point of diminishing returns. Should I write a test case to generate a corrupt image for my image loading code, just to verify that my assertion works? I’d rather be encouraged to write the assertion in the first place, because that matters more.
The perfect being the enemy of the good, etc.
---
### Author:  [@pint](https://discourse.julialang.org/u/pint)
#### Post date: [January 6, 2017, 3:20pm UTC](https://discourse.julialang.org/t/proposal-then-else-syntax-to-replace-short-circuiting/1323/14 "2017-01-06T15:20:53Z")
in my eyes, && is strictly better than these proposed _then_ syntaxes, because it is better syntax highlighted. _then_ blends in too much. i also don’t like _if end_ for single call or return for it takes too many rows. and writing it in one line is just awkward.
---
### Author:  [@ScottPJones](https://discourse.julialang.org/u/ScottPJones)
#### Post date: [January 6, 2017, 3:45pm UTC](https://discourse.julialang.org/t/proposal-then-else-syntax-to-replace-short-circuiting/1323/15 "2017-01-06T15:45:04Z")
What about (and this can be done right now) using `@ifthen cond expr` and `@ifelse cond expr` macros, if you want to make it clearer what is happening than `&&` and `||` when they are used for control flow (i.e. with things like `error`, `throw`, `return`, `break`, `continue`) instead of boolean logic where you want to short-circuit for performance (or to avoid something not valid if previous conditions are false/true).
---
### Author:  [@e3c6](https://discourse.julialang.org/u/e3c6)
#### Post date: [January 6, 2017, 3:59pm UTC](https://discourse.julialang.org/t/proposal-then-else-syntax-to-replace-short-circuiting/1323/16 "2017-01-06T15:59:47Z")
If you remove the short-circuit behavior of `&&`, then `if a && b && c then c` may evaluate `b` or `c` unnecessarily.
---
### Author:  [@e3c6](https://discourse.julialang.org/u/e3c6)
#### Post date: [January 6, 2017, 4:01pm UTC](https://discourse.julialang.org/t/proposal-then-else-syntax-to-replace-short-circuiting/1323/17 "2017-01-06T16:01:05Z")
what about: `a then b then c then d` as a replacement for `a && b && c && d`?
This example proves the value of `a then b` vs `if a; b; end`. In the later case, you would need a lot of traling `end`s:
`if a; if b; if c; if d; d; end; end; end; end`
---
### Author:  [@tbreloff](https://discourse.julialang.org/u/tbreloff)
#### Post date: [January 6, 2017, 4:11pm UTC](https://discourse.julialang.org/t/proposal-then-else-syntax-to-replace-short-circuiting/1323/18 "2017-01-06T16:11:55Z")
Am I the only one that reads short-circuits as “and” and “or”?
```julia
x<0 && error()
x>=0 || error()
```
I naturally read those as “x negative and error” and “x nonnegative or error”. So if we’re discussing changes, I think you should be allowed to interchange `&&` with `and` and `||` with `or`.
---
### Author:  [@ScottPJones](https://discourse.julialang.org/u/ScottPJones)
#### Post date: [January 6, 2017, 4:23pm UTC](https://discourse.julialang.org/t/proposal-then-else-syntax-to-replace-short-circuiting/1323/19 "2017-01-06T16:23:46Z")
😉 Well, that _was_ the whole point of @Ismael-VC’s PR.
Given a choice of only `&&` and `||` , or `and` and `or`, I’d stick with the current ones (probably due to too many years with C and C-like languages, I even added the `&&` `||` syntax to CachéObjectScript!) but I also don’t see having **and** and **or** _in addition_ as being a bad thing either.
---
### Author:  [@mkborregaard](https://discourse.julialang.org/u/mkborregaard)
#### Post date: [January 6, 2017, 4:24pm UTC](https://discourse.julialang.org/t/proposal-then-else-syntax-to-replace-short-circuiting/1323/20 "2017-01-06T16:24:59Z")
In this PR [RFC: Make `and` & `or` aliases for `&&` and `||`. by Ismael-VC · Pull Request #19788 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/pull/19788) (linked in the OP) they propose specifically that the `and` as replacement for `&&` should NOT be shortcircuiting - I guess there are lots of ways to think about this.
EDIT: this comment was simultaneous with the above stating the same thing.
[Next page](https://discourse.julialang.org/t/proposal-then-else-syntax-to-replace-short-circuiting/1323.md?page=2)