### Author:  [@Mirsad\_Cosovic](https://discourse.julialang.org/u/Mirsad_Cosovic)
#### Post date: [February 9, 2026, 2:23pm UTC](https://discourse.julialang.org/t/unexpected-boolean-flag-behavior-in-julia-1-12-vs-1-10/135539/1 "2026-02-09T14:23:37Z")
I have encountered a strange issue while migrating code from Julia 1.10 to **Julia 1.12.3**. It seems like a variable assignment within a function is not being reflected correctly in the caller’s scope, or I am fundamentally misunderstanding a change in the recent version.
Here is a minimal working example:
```julia-auto
str = "[1 232.4;\n 2 40;\n 2 40];"
write("my_file.txt", str)
function readFile(str::String)
flag = false
for line in eachline("my_file.txt")
if !flag && occursin("[", line)
flag = true
println("Flag value after first change: ", flag)
end
if flag
flag = parseLine(line, flag, "[", "]")
println("Flag returned from parseLine: ", flag)
end
end
end
function parseLine(line::String, flag::Bool, start::String, last::String)
if occursin(start, line)
line = split(line, start)[end]
end
if occursin(last, line)
flag = false
println("Flag updated inside parseLine: ", flag)
end
return flag
end
readFile(str)
```
The problematic output:
```julia-auto
Flag value after first change: true
Flag returned from parseLine: true
Flag returned from parseLine: true
Flag updated inside parseLine: false
Flag returned from parseLine: true <-- Why is this true?
```
The last line indicates that even though `parseLine` explicitly returned `false`, the `flag` variable in the `readFile` function remains `true`.
Two strange observations:
1. Adding an `else` block fixes it: If I modify `parseLine` to explicitly set `flag = true` in an `else` branch, the output is correct (the flag becomes `false` in the caller scope).
```julia-auto
function parseLine(line::String, flag::Bool, start::String, last::String)
if occursin(start, line)
line = split(line, start)[end]
end
if occursin(last, line)
flag = false
println("Flag updated inside parseLine: ", flag)
else
flag = true
end
return flag
end
```
1. Commenting out the `split` logic:
```julia-auto
if occursin(start, line)
line = split(line, start)[end]
end
```
also fixes it.
I am certain this logic worked in Julia 1.10. Has there been a change in how local bindings or string manipulations (like `split`) interact with function returns in Julia 1.12?
Any help or explanation would be greatly appreciated!
---
### Author:  [@Sukera](https://discourse.julialang.org/u/Sukera)
#### Post date: [February 9, 2026, 3:02pm UTC](https://discourse.julialang.org/t/unexpected-boolean-flag-behavior-in-julia-1-12-vs-1-10/135539/2 "2026-02-09T15:02:57Z")
This is possibly a manifestation of a compiler bug
>
>
> Minimal example
> \`\`\`julia
> mutable struct A
> a::Int
> end
>
> g(a, b; kw = true) = isz…ero(a.a) && !b
>
> function repro()
> a = A(0)
> b = iszero(a.a)
> println((; b))
> if g(a, b) else end
> println((; b))
> end
>
> repro()
> \`\`\`
> output is
> \`\`\`julia
> (b = true,)
> (b = false,)
> \`\`\`
> while on Julia 1.10 we get the expected
> \`\`\`julia
> (b = true,)
> (b = true,)
> \`\`\`
>
> The buggy behaviour seems to have quite a few prerequisites (any change makes the bug disappear):
> 1. \`A\` needs to be mutable (even though it is not mutated explicitly anywhere)
> 2. \`g\` needs to take a kwarg (even though it is unused)
> 3. \`g\` needs to take both parameters with non-trivial conditions on it
> 4. the \`&&\` conditional needs to be in that order (even though it should not matter since the first will be true)
> 5. the call to \`g(a, b)\` needs to be within the \`if\` conditional (even though trivial)
>
> version info:
> \`\`\`julia-repl
> julia\> versioninfo()
> Julia Version 1.14.0-DEV.1651
> Commit 7eb1edb73e (2026-01-30 02:33 UTC)
> Platform Info:
> OS: Linux (x86\_64-pc-linux-gnu)
> CPU: 16 × AMD Ryzen 7 5825U with Radeon Graphics
> WORD\_SIZE: 64
> LLVM: libLLVM-20.1.8 (ORCJIT, znver3)
> GC: Built with stock GC
> Threads: 1 default, 1 interactive, 1 GC (on 16 virtual cores)
> Environment:
> JULIA\_PKG\_USE\_CLI\_GIT = 1
> \`\`\`
> Additionally I've checked that version 1.12.4 seems to be affected as well.
>
> I suspect it to be due to wrong lowering since \`@code\_typed\` already shows \`(b = false,)\`:
> \`\`\`julia-repl
> julia\> @code\_typed repro()
> CodeInfo(
> 1 ─ %1 = builtin (0 === 0)::Bool
> │ %2 = %new(@NamedTuple{b::Bool}, %1)::@NamedTuple{b::Bool}
> │ invoke Main.println(%2::@NamedTuple{b::Bool})::Any
> │ %4 = builtin (0 === 0)::Bool
> └── goto #3 if not %4
> 2 ─ %6 = intrinsic Base.not\_int(%1)::Bool
> └── goto #4
> 3 ─ goto #4
> 4 ┄ %9 = φ (#2 =\> %6, #3 =\> false)::Bool
> └── goto #5
> 5 ─ goto #7 if not %9
> 6 ─ nothing::Nothing
> 7 ┄ invoke Main.println((b = false,)::@NamedTuple{b::Bool})::Nothing
> └── return nothing
> ) =\> Nothing
> \`\`\`
---
### Author:  [@adienes](https://discourse.julialang.org/u/adienes)
#### Post date: [February 9, 2026, 3:08pm UTC](https://discourse.julialang.org/t/unexpected-boolean-flag-behavior-in-julia-1-12-vs-1-10/135539/3 "2026-02-09T15:08:12Z")
yes, this is a bug that is fixed on master and will be backported to the next 1.12 patch release
---
### Author:  [@Benny](https://discourse.julialang.org/u/Benny)
#### Post date: [February 9, 2026, 3:14pm UTC](https://discourse.julialang.org/t/unexpected-boolean-flag-behavior-in-julia-1-12-vs-1-10/135539/4 "2026-02-09T15:14:36Z")
Can confirm 1.12 starts the anomaly…:
```julia-auto
julia> readFile(str) # 1.12.4, 1.13.0-beta2
Flag value after first change: true
Flag returned from parseLine: true
Flag returned from parseLine: true
Flag updated inside parseLine: false
Flag returned from parseLine: true
```
…because 1.11 also does the correct thing. Can confirm nightly fixes this particular example at least:
```julia-auto
julia> readFile(str) # 1.11.9, nightly 1.14.0-DEV.1694
Flag value after first change: true
Flag returned from parseLine: true
Flag returned from parseLine: true
Flag updated inside parseLine: false
Flag returned from parseLine: false
```
Wonder where in the compilation process goes wrong, interestingly the `@code_lowered` doesn’t show a misscoped variable as it appeared to be.
---
### Author:  [@Mirsad\_Cosovic](https://discourse.julialang.org/u/Mirsad_Cosovic)
#### Post date: [February 11, 2026, 9:51am UTC](https://discourse.julialang.org/t/unexpected-boolean-flag-behavior-in-julia-1-12-vs-1-10/135539/5 "2026-02-11T09:51:28Z")
The issue is still present in the latest Julia v1.12.5 release.
---
### Author:  [@jakobnissen](https://discourse.julialang.org/u/jakobnissen)
#### Post date: [February 11, 2026, 10:31am UTC](https://discourse.julialang.org/t/unexpected-boolean-flag-behavior-in-julia-1-12-vs-1-10/135539/6 "2026-02-11T10:31:40Z")
The fix barely didn’t get in the 1.12.5 release. It’s marked for backport, so it’ll be in 1.12.6.
---
### Author:  [@Mirsad\_Cosovic](https://discourse.julialang.org/u/Mirsad_Cosovic)
#### Post date: [April 20, 2026, 3:35pm UTC](https://discourse.julialang.org/t/unexpected-boolean-flag-behavior-in-julia-1-12-vs-1-10/135539/7 "2026-04-20T15:35:21Z")
The bug remains in 1.12.6. Even though the logic checks out, the results are still inconsistent with what we expect.
---
### Author:  [@mbauman](https://discourse.julialang.org/u/mbauman)
#### Post date: [April 20, 2026, 3:58pm UTC](https://discourse.julialang.org/t/unexpected-boolean-flag-behavior-in-julia-1-12-vs-1-10/135539/8 "2026-04-20T15:58:35Z")
Yeah, looks like julia#60902 doesn’t merge into 1.12 cleanly, so it requires some extra manual effort that’s not been done: [Backports for 1.12.6 by KristofferC · Pull Request #61154 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/pull/61154)