World age delay doesn't occur with `@eval` in `begin` or `let` blocks, but does with `eval`

[Benny]

@Keno

1.11 did not have world-age partitioning for bindings, the code in your original post is UB in these versions. However, it’s not entirely related since 1.11 raised world ages after most statements anyway (but was inconsistent about when).

True, I suppose I’d have to do the zero-argument function call as a pseudo-constant:

julia> pip() = 3 # 1.11
pip (generic function with 1 method)

julia> begin
       println(pip())
       @eval pip() = 3.1
       println(pip()) # updated
       end;
3
3.1

julia> begin
       println(pip())
       eval(:(pip() = 3.14))
       println(pip()) # updated
       end;
3.1
3.14

which I really hope is just long-unclarified undefined behavior if that can’t happen in 1.12.

@Keno

I was just trying to be nice to the ecosystem. It was less breaking this way…Also, hey - I’m proud of myself for actually having documented this :).

I’m pretty grateful that it’s finally moving because the Manual has been ambiguous about MANY fundamentals like this to make room for future core features (at least, I think most people have been surprised that constants weren’t part of world age until now, especially given the zero-argument function workaround). While these don’t seem to cause widespread issues, people have noticed odd implementation inconsistencies, like the difference between importing a function versus a struct, that end up being specified. I think Julia is just going to have to be a little weird until the core features and specification are solid enough to even begin considering a more straightforward v2. I personally would love if explicit-only variable declarations (and thus much simpler conditions for assignment) in v2 could finally let us freely paste code between the global and local scopes and do away with soft scope contexts, and world age bindings would probably be important there.