# Can \`parse\` be computed at compile time?

**URL:** <https://discourse.julialang.org/t/can-parse-be-computed-at-compile-time/119507>\
**Category:** General Usage\
**Tags:** constant-propagation, compile-time\
**Created:** [September 17, 2024, 3:06pm UTC](https://discourse.julialang.org/t/can-parse-be-computed-at-compile-time/119507 "2024-09-17T15:06:16Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![greatpet](https://avatars.discourse-cdn.com/v4/letter/g/e495f1/32.png) [@greatpet](https://discourse.julialang.org/u/greatpet)\
**Post date:** [September 17, 2024, 3:06pm UTC](https://discourse.julialang.org/t/can-parse-be-computed-at-compile-time/119507/1 "2024-09-17T15:06:16Z")

</div>

The function  
`f() = parse(Int, "10")`  
produces native code, according to `@code_native`, which involves runtime parsing rather than directly returning the integer 10.

Why can’t Julia optimize this away at compile time? Is it possible for future versions of Julia to do this?

---

<div class="post-metadata">

**Author:** ![nsajko](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nsajko/32/221187_2.png) [@nsajko](https://discourse.julialang.org/u/nsajko)\
**Post date:** [September 17, 2024, 3:42pm UTC](https://discourse.julialang.org/t/can-parse-be-computed-at-compile-time/119507/2 "2024-09-17T15:42:24Z")

</div>

This is governed by Julia’s effect system, see [`@assume_effects`](https://docs.julialang.org/en/v1/base/base/#Base.@assume_effects).

Basically, a call may be constant folded when the compiler determines it has the `:foldable` effect. In this case I think the `String` (`"10"`) may be complicating things, because there’s some special casing for `String`. This wouldn’t apply to `AbstractString` in general.

---

<div class="post-metadata">

**Author:** ![ufechner7](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ufechner7/32/51363_2.png) [@ufechner7](https://discourse.julialang.org/u/ufechner7)\
**Post date:** [September 17, 2024, 3:42pm UTC](https://discourse.julialang.org/t/can-parse-be-computed-at-compile-time/119507/3 "2024-09-17T15:42:36Z")

</div>

Why are you using parse in the first place if all you need is a constant?

---

<div class="post-metadata">

**Author:** ![greatpet](https://avatars.discourse-cdn.com/v4/letter/g/e495f1/32.png) [@greatpet](https://discourse.julialang.org/u/greatpet)\
**Post date:** [September 17, 2024, 8:09pm UTC](https://discourse.julialang.org/t/can-parse-be-computed-at-compile-time/119507/4 "2024-09-17T20:09:47Z")

</div>

I’m just trying to understand the limits of the compiler’s constant-folding capabilities. I read somewhere that small arrays can be constant-folded, so I wonder to what extent the compiler can do it for strings.

---

<div class="post-metadata">

**Author:** ![nsajko](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nsajko/32/221187_2.png) [@nsajko](https://discourse.julialang.org/u/nsajko)\
**Post date:** [September 17, 2024, 9:21pm UTC](https://discourse.julialang.org/t/can-parse-be-computed-at-compile-time/119507/5 "2024-09-17T21:21:13Z")

</div>

> [@nsajko](#):
>
> there’s some special casing for `String`

See the comment by Keno here:

> <https://github.com/JuliaLang/julia/issues/54921>
>
> Consider this silly little function:
> 
> \`\`\`julia
> f() = "foo" \* "bar"
> \`\`\`
> 
> wh…ich concatenates two string constants, \`"foo"\` and \`"bar"\`, into one bigger constant \`"foobar"\`. The compiler agrees, and according to Cthulhu, infers that this is a constant:
> 
> \`\`\`julia-repl
> julia\> f() = "foo" \* "bar"
> f (generic function with 1 method)
> 
> julia\> @descend f()
> f() @ Main REPL\[4\]:1
> 1 f()::Core.Const("foobar") = "foo" \* "bar"::String
> \[...\]
> \`\`\`
> 
> However, even though it's inferred as a constant (and thus \`"foobar"\` is already allocated somewhere!), the compiler doesn't actually concretely evaluate this:
> 
> \`\`\`llvm
> julia\> @code\_llvm f()
> ; Function Signature: f()
> ; @ REPL\[4\]:1 within \`f\`
> define nonnull ptr @julia\_f\_4243() #0 {
> top:
> %0 = call nonnull ptr @"j\_\*\_4246"(ptr nonnull @"jl\_global#4247.jit", ptr nonnull @"jl\_global#4248.jit")
> ret ptr %0
> }
> 
> julia\> @code\_native dump\_module=false f()
> .text
> ; ┌ @ REPL\[4\]:1 within \`f\`
> push	rbp
> mov	rbp, rsp
> mov	rax, qword ptr \[r13 + 16\]
> movabs	rdi, 139273527936000
> lea	rsi, \[rdi + 56\]
> mov	rax, qword ptr \[rax + 16\]
> mov	rax, qword ptr \[rax\]
> movabs	rax, offset "\*"
> call	rax
> pop	rbp
> ret
> ; └
> ; ┌ @ REPL\[4\]:1 within \`\<invalid\>\`
> nop	dword ptr \[rax + rax\]
> ; └
> \`\`\`
> 
> Preferring to do this at runtime instead. 
> 
> Effects look wonderful too:
> 
> \`\`\`
> julia\> Base.infer\_effects(f)
> (+c,+e,+n,+t,+s,+m,+u)
> \`\`\`
> 
> So why doesn't the compiler fold this away, since the result was inferred as \`Core.Const\` & presumably allocated during that?
> 
> I was able to reproduce this on 1.11 & master.
> 
> \---
> 
> I've labelled this with \`compiler:optimizer\`, but I'm not sure this fits there exactly. Feel free to relabel as appropriate.