### Author:  [@rcomm](https://discourse.julialang.org/u/rcomm)
#### Post date: [September 7, 2025, 9:52am UTC](https://discourse.julialang.org/t/what-does-the-parser-think-this-invalid-construction-means/132155/1 "2025-09-07T09:52:52Z")
I discovered today that this line:
```julia-auto
if : return true; else return false; end
```
always returns `true`, whatever the value of x.
The behaviour is the same in the REPL and in functions.
I admit I thought that the parser would pick up syntax errors,
so I wasted time focussing on the logic of the expression, instead
of checking the punctuation ☹
However the parser apparently thinks it’s valid, because there is no
error message. What does the parser think it means?
It has a colon but it’s not an iterator.
---
### Author:  [@giordano](https://discourse.julialang.org/u/giordano)
#### Post date: [September 7, 2025, 11:19am UTC](https://discourse.julialang.org/t/what-does-the-parser-think-this-invalid-construction-means/132155/2 "2025-09-07T11:19:11Z")
I may be wrong, but my reading of
```julia-repl
julia> Meta.@lower (if false: return true; else return false; end)
:($(Expr(:thunk, CodeInfo(
1 ─ %1 = Main.:(:)
└── return true
2 ─ %3 = dynamic (%1)(false, nothing)
└── goto #4 if not %3
3 ─ return nothing
@ none within `unknown scope`
┌ @ REPL[5]:1 within `macro expansion`
4 ─│ return false
└
))))
```
is that `return true` is executed immediately after the evaluation of the colon, because that’s still part of the condition (nothing stopped the condition expression). For example
```julia-auto
julia> if return 42; end
42
```
is also valid because the “condition” of the `if` contains `return` and that returns immediately no matter what, the `if` doesn’t even have a chance to do anything.
---
### Author:  [@stevengj](https://discourse.julialang.org/u/stevengj)
#### Post date: [September 7, 2025, 11:46am UTC](https://discourse.julialang.org/t/what-does-the-parser-think-this-invalid-construction-means/132155/3 "2025-09-07T11:46:23Z")
The key points are that:
1. `return X` is a valid expression in any context that would allow arbitrary Julia values, and simply returns immediately once it is executed (so that it need not have a “value”). This is what allows idioms like `condition && return foo` to work.
2. The colon operator `:` has higher precedence than `if` for the parser, and `return` has higher precedence than `:`, so if you do `if foo:bar; else ...; end`, the `foo:bar` is parsed as a call to the [`Colon()` operator](https://docs.julialang.org/en/v1/base/arrays/#Base.Colon) even if `foo` and/or `bar` are a `return` statement
---
### Author:  [@rcomm](https://discourse.julialang.org/u/rcomm)
#### Post date: [September 7, 2025, 12:01pm UTC](https://discourse.julialang.org/t/what-does-the-parser-think-this-invalid-construction-means/132155/4 "2025-09-07T12:01:19Z")
OK, thanks.
I never enjoyed learning precedence rules. I’m just going to put parentheses everywhere they’re relevant. As I understand it so far, there’s no penalty for doing that.
---
### Author:  [@adienes](https://discourse.julialang.org/u/adienes)
#### Post date: [September 7, 2025, 12:19pm UTC](https://discourse.julialang.org/t/what-does-the-parser-think-this-invalid-construction-means/132155/5 "2025-09-07T12:19:49Z")
FWIW I don’t think `return` should be allowed here. I consider this a bug
---
### Author:  [@Benny](https://discourse.julialang.org/u/Benny)
#### Post date: [September 7, 2025, 1:33pm UTC](https://discourse.julialang.org/t/what-does-the-parser-think-this-invalid-construction-means/132155/6 "2025-09-07T13:33:08Z")
> [@adienes](#):
>
> I consider this a bug
Bugs aren’t documented:
```julia-auto
When used in a top-level expression (i.e. outside any function), return causes the entire current top-level
expression to terminate early.
```
> [@giordano](#):
>
> `return true` is executed immediately after the evaluation of the colon
The lowered code suggests it returns before the colon could be called, and indeed it does:
```julia-auto
julia> struct LoudFalse; LoudFalse() = (println("False!"); new()) end
julia> Base.:(:)(::LoudFalse, y::Bool) = (println("colon!"); false:y)
julia> if LoudFalse(): return true; else return false; end
False!
true
```
If we don’t return early, the colon call would error:
```julia-auto
julia> if LoudFalse(): true; else return false; end
False!
colon!
ERROR: TypeError: non-boolean (UnitRange{Bool}) used in boolean context
```
---
### Author:  [@giordano](https://discourse.julialang.org/u/giordano)
#### Post date: [September 7, 2025, 1:41pm UTC](https://discourse.julialang.org/t/what-does-the-parser-think-this-invalid-construction-means/132155/7 "2025-09-07T13:41:38Z")
> [@Benny](#):
>
> The lowered code suggests it returns before the colon could be called
I didn’t say the range was constructed, the colon is referenced.
---
### Author:  [@adienes](https://discourse.julialang.org/u/adienes)
#### Post date: [September 7, 2025, 1:44pm UTC](https://discourse.julialang.org/t/what-does-the-parser-think-this-invalid-construction-means/132155/8 "2025-09-07T13:44:11Z")
> [@Benny](#):
>
> Bugs aren’t documented:
this docstring seems super unrelated. that’s about top-level expressions, not `if` conditional blocks?
---
### Author:  [@Benny](https://discourse.julialang.org/u/Benny)
#### Post date: [September 7, 2025, 1:47pm UTC](https://discourse.julialang.org/t/what-does-the-parser-think-this-invalid-construction-means/132155/9 "2025-09-07T13:47:47Z")
> [@giordano](#):
>
> I didn’t say the range was constructed, the colon is referenced.
I figured, but “evaluation of the colon” made it a bit ambiguous whether it meant referencing the callable `:` or calling it. People usually mean evaluating a function to be a call. In a specific Julia context,`eval`-uating `Expr`-essions is a whole different deal.
> [@adienes](#):
>
> that’s about top-level expressions, not `if` conditional blocks?
We’re talking about an `if` block at top-level. Granted, that’s a trivial statement because all code is nested inside a top-level expression.
---
### Author:  [@adienes](https://discourse.julialang.org/u/adienes)
#### Post date: [September 7, 2025, 1:52pm UTC](https://discourse.julialang.org/t/what-does-the-parser-think-this-invalid-construction-means/132155/10 "2025-09-07T13:52:47Z")
I understand that’s the current example being used, but it has the same behavior inside functions. I read that docstring as describing the behavior of `return` when used _in statement position_ at top level, not as declaring that `return` can be inserted anywhere into any expression.
---
### Author:  [@Benny](https://discourse.julialang.org/u/Benny)
#### Post date: [September 7, 2025, 2:00pm UTC](https://discourse.julialang.org/t/what-does-the-parser-think-this-invalid-construction-means/132155/11 "2025-09-07T14:00:46Z")
The docstring said “in a top-level expression” and “entire current top-level expression” exactly to distinguish it from the `return` subexpression. You’d be right if it said “as a top-level expression”, though it’d be unusual to let a top-level `return` statement exist to basically do nothing if it were otherwise disallowed as a subexpression except for `function` expressions.
I’d only use it in blocks that mimick one-off function calls, it can get downright bizarre:
```julia-auto
julia> struct Y
return 0
Y() = println("hello") # removes the default definition, but isn't evaluated
end
0
julia> Y()
ERROR: MethodError: no method matching Y()
```