# Did Julia community do something to improve its correctness?

**URL:** <https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515>\
**Category:** General Usage\
**Created:** [August 5, 2023, 7:16am UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515 "2023-08-05T07:16:42Z")\
**Posts on this page:** 1\
**Showing post:** 217

<div class="post-metadata">

**Author:** ![adienes](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/adienes/32/37459_2.png) [@adienes](https://discourse.julialang.org/u/adienes)\
**Post date:** [October 27, 2023, 2:21pm UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/217 "2023-10-27T14:21:41Z")

</div>

> <https://github.com/JuliaLang/julia/issues/47410>
>
> See some MWE here https://discourse.julialang.org/t/weird-syntax-error/89591/6, …seems to occur on all recent versions.

> <https://github.com/JuliaLang/julia/pull/51785>
>
> \[Docs\](https://docs.julialang.org/en/v1/manual/control-flow/#else-Clauses) state…:
> 
> \> The try, catch, else, and finally clauses each introduce their own
> \> scope blocks.
> 
> But it is currently not the case for \`else\` blocks
> 
> \`\`\`julia
> julia\> try
> catch
> else
> z = 1
> end
> 1
> 
> julia\> z
> 1
> \`\`\`
> 
> This change actually makes \`else\` blocks have their own scope block:
> 
> \`\`\`julia
> julia\> try
> catch
> else
> z = 1
> end
> 1
> 
> julia\> z
> ERROR: UndefVarError: \`z\` not defined
> \`\`\`

> <https://github.com/JuliaLang/julia/issues/48889>
>
> Notice that \`foo()\` returns \`3\`.
> \`\`\`julia
> julia\> VERSION
> v"1.9.0-beta4"
> 
> ju…lia\> foo=let j=0, f, i
> while j \< 3
> i = j + 1
> println("i == ", i)
> if j==0; f = ()-\>i end
> j += 1
> end
> i
> f
> end;
> i == 1
> i == 2
> i == 3
> 
> julia\> foo()
> 3
> \`\`\`
> Comment out the line that says \`i\`, and \`foo()\` instead returns \`1\` (and its capture is not in a \`Core.Box\` anymore).
> 
> (ref: \[Discourse thread\](https://discourse.julialang.org/t/rfc-some-ideas-to-tackle-15276-performance-of-captured-variables-in-closures/95260/42?u=uniment))

> <https://github.com/JuliaLang/julia/issues/47168>
>
> The const keyword seems to have no effect when used with the destructuring synta…x in Julia 1.7+.
> 
> \`\`\`
> julia\> t = (;a = 1, b = 2);
> 
> julia\> const (;a, b) = t
> (a = 1, b = 2)
> 
> julia\> a = 3 # re-definition produces no error or warning, so a is not const
> 3
> \`\`\`
> My Julia version is 1.8.2, 64-bit Linux (glibc), installed from the binary tarball.
> (First posted on Discourse: \[https://discourse.julialang.org/t/destructuring-syntax-does-not-respect-const-annotation/88751\](https://discourse.julialang.org/t/destructuring-syntax-does-not-respect-const-annotation/88751))

> <https://github.com/JuliaLang/julia/issues/45162>
>
> I raised this issue \[on discourse\](https://discourse.julialang.org/t/using-a-key…word-argument-leads-to-enormous-allocations/80354), where the consensus seems to be that this is at least very confusing, and possibly a bug.
> 
> If I \*use\* a kwarg for a function that was passed as an argument to another function, Julia does not specialize the latter function. If I don't use the kwarg for that very same function, it does specialize. Below, I'll include a less trivial example that's closer to my actual use case. But schematically, the idea is this:
> \`\`\`julia
> f1(a; b=10) = a+b
> f2(c, f) = c + f(20)
> f3(d, f) = d + f(30; b=40)
> \`\`\`
> Calling, for example, \`f2(5, f1)\` will result in a specialized \`f2\`; calling \`f3(5, f1)\` will not result in specialization. I imagine Julia is clever enough to optimize the problem away in this schematic. But in my code, I was seeing slowdowns of ~100x and allocations of multiple GiBs on each call to my core computation function.
> 
> As pointed out in discourse, it's possible to manually trigger specialization by adding a type parameter. But the failure to \*automatically\* specialize is a problem for a few reasons:
> 
> 1. It's surprising. The \[performance tip on specialization\](https://docs.julialang.org/en/v1/manual/performance-tips/#Be-aware-of-when-Julia-avoids-specializing) says "Julia will always specialize when the argument is used within the method, but not if the argument is just passed through to another function." In this case, I \*did\* use the argument (the function with the kwarg). From the discussion on discourse, it looks like the problem is that Julia immediately lowers that to just pass the function through to \`Core.kwfunc\`. So technically the argument "is just passed through to another function" — but not by the programmer. (Gotta love passive voice!)
> 2. It's very hard to diagnose. None of the usual tools — profiling, allocation tracking, \`@code\_warntype\`, JET, Traceur — pointed out any problem with the use of kwargs. In fact, profiling and allocation actively focused my attention on other parts of the code that were not at all the source of the problem. Even the \`(@which f(...)).specializations\` trick from that section of the performance tips seemed to say the function \*was\* being specialized for my arguments. (See below.)
> 3. It seems to contradict the docs. If the goal when designing this heuristic is to detect when a function is "just passed through" so that it will "usually \[have\] no performance impact at runtime", surely the decision of how to arrange parameters in a function definition should not affect the result.
> 
> So, at the very least, I would think this is a documentation bug, because the kwarg wrinkle should be noted in that performance tip — rather than requiring the user to mentally combine disparate arcana from the most cryptic parts of the docs. It would also be nice if some standard tools could point toward the source of the problem. But maybe this is truly a bug in Julia, which should actually specialize even when a kwarg is used?
> 
> \---
> 
> For reference, here's a working example that's complicated enough that Julia doesn't just optimize the problem away, while still being a greatly simplified version of my actual use case:
> \`\`\`julia
> using Profile
> 
> function index(n, mp, m; n\_max=n)
> n + mp + m + n\_max
> end
> 
> function inplace!(a, n\_max, index\_func)
> i1 = index\_func(1, 2, 3; n\_max=n\_max) # Using this version leads to allocations below
> # i1 = index\_func(1, 2, 3) # Using this version leads to 0 allocations
> i2 = size(a, 1) - 2i1
> for i in 1:i2 # Allocates 3182688 B if using kwarg above
> a\[i + i1\] = a\[i + i1 - 1\] # Allocates 9573120 B if using kwarg above
> end
> for i in 3:i2-4 # Allocates 3182576 B if using kwarg above
> a\[i + i1\] -= a\[i + i1 - 2\] # Allocates 12771408 B if using kwarg above
> end
> end
> 
> function compute\_a(n\_max::Int64)
> a = randn(Float64, 100\_000)
> inplace!(a, n\_max, index)
> Profile.clear\_malloc\_data()
> inplace!(a, n\_max, index)
> end
> 
> 
> compute\_a(10)
> \`\`\`
> And yes, there are plenty of ways to improve the performance of this simplified code with function barriers and such. But my actual code is too complicated for that, with the kwarg func being used multiple times inside some loops.
> 
> If I look at the specializations of \`inplace!(a, n\_max, index)\`, I get
> \`\`\`julia
> svec(MethodInstance for inplace!(::Vector{Float64}, ::Int64, ::Function), MethodInstance for inplace!(::Vector{Float64}, ::Int64, ::typeof(index)), nothing, nothing, nothing, nothing, nothing, nothing)
> \`\`\`
> That second element really looks to me like it specialized for my particular \`index\` function.
> 
> 
> \<details\>
> \<summary\>Here's all my versioninfo\</summary\>
> 
> \`\`\`
> julia\> versioninfo()
> Julia Version 1.7.2
> Commit bf53498635 (2022-02-06 15:21 UTC)
> Platform Info:
> OS: macOS (x86\_64-apple-darwin19.5.0)
> CPU: Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz
> WORD\_SIZE: 64
> LIBM: libopenlibm
> LLVM: libLLVM-12.0.1 (ORCJIT, haswell)
> \`\`\`
> 
> \</details\>

---

_[View the full topic](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515)._