make const a toplevel expr or error

[vtjnash]

const can cause serious, subtle bugs when combined with precompilation. it is valid to use from the :toplevel scope, but it can cause problems if used at runtime (and it's already ignored when specified at the local scope. this could be fixed by warning for and ignoring the const declaration outside of the toplevel scope. or this could be fixed by internally distinguishing between const (as it is currently defined) and a new assigned once attribute (that provides none of the inference speed benefits of const, but just doesn't allow reassignment).

the following is fine:

module Fine
const binding = value
end

the following can confuse precompilation (and isn't great for type inference either):

module Bad
__init__() = (global const binding = value)
end

the following currently is ignored by parsing, so is neither bad nor good:

module Either
f() = (const localb = localv)
end

[yuyichao]

the following can confuse precompilation (and isn't great for type inference either):

module Bad
__init__() = (global const binding = value)
end

I think this is still really useful for some packages that load shared libraries.

[yuyichao]

IIRC, the plan in #11456 (or a related one) is that the compiler should look inside the function and see if there's a global const defined inside and reserve a slot for it. (Looking for the specific comment now)

Edit: Comment about this is here #11456 (comment)

[vtjnash]

#11456 is about making global variable bindings resolved early, this thread is about disallowing the addition of new global const bindings. #11456 (comment) is exactly the subtle but serious issue that can happen if global const is allowed (since ccall will precompile a call to a static pointer, rather than a runtime lookup)

[timholy]

Interesting. What if we define an __init_pre__() and __init_post__(), and require that any global const assignments happen in post? Would that solve the problem?

EDIT: init_post runs after loading the cache. init_pre runs before caching.

[yuyichao]

(since ccall will precompile a call to a static pointer, rather than a runtime lookup)

Is this an issue if the pointer is used in the same module and __init__ (or __init_post__) is not run when the module is pre-compiled?

[vtjnash]

@timholy that's just:

module MyModule
__init_pre__() = "here1"
__init_post__() = "there2"

__init__() = __init_post__()
__init_pre__()
end

@yuyichao less so, but only because we don't run __init__ before precompiling the module, so it becomes actually just becomes undefined behavior at runtime due to invalidating type inference.

[yuyichao]

so it becomes actually just becomes undefined behavior at runtime due to invalidating type inference.

Sorry I forgot to mention that this should also be combined with letting typeinf/precompile look into functions (especially __init__) to see that the const global will be assigned at runtime.

[timholy]

I think I get it now. Presumably "only" affects functions that get JITted before the cache is written?

[timholy]

From an inference perspective, I'm guessing that much of the benefit of what we now use global const ... for would be obtained if we had an of_const_type declaration.

[vtjnash]

Sorry I forgot to mention that this should also be combined with letting typeinf/precompile look into functions (especially init) to see that the const global will be assigned at runtime.

@carnaval is that something typeinference could handle?

I think I get it now. Presumably "only" affects functions that get JITted before the cache is written?

JIT isn't really the right term, since this is AOT compiling. But since this is AOT, it's generally beneficial to do as much work as possible to build a good / complete cache.

[vtjnash]

for would be obtained if we had an of_const_type declaration...

module OfConstType
const binding = Ref{T}()

binding[] = 1
Base.Test.@test binding[] === 1
end

[timholy]

Sorry, I don't understand your example.

[yuyichao]

module OfConstType
const binding = Ref{T}()

binding[] = 1
Base.Test.@test binding[] === 1
end

I guess I wouldn't mind only allowing real const in global scope if we can making var::Type (edit: as global variable) a syntax sugar for this.

[vtjnash]

that seems to be Jeff's plan #11456 (comment)

[yuyichao]

@timholy

Sorry, I don't understand your example.

binding is a global const so it will always bind to the same object (type) and therefore binding[] always has the same type (edit: or whatever subset of types constraint by the type parameter T).

[yuyichao]

that seems to be Jeff's plan #11456 (comment)

Would still be nice if accessing them doesn't require adding [] though :).

[timholy]

Got it. Yes, that's a workable strategy.

[toivoh]

I'm still hoping that const will some day be respected in local scope, please don't make that an error (though I understand it might be considered a different feature than const at the top level).

[yuyichao]

Hmm, even for typed global, it still won't cover this

__init__() = global const lib_path = find_library(...)

ccall((:sym, lib_path), ...)

[StefanKarpinski]

This doesn't seem like a high priority given the lack of comment since July 2015.

[JeffBezanson]

Might also be helped by #18933 ?

[StefanKarpinski]

Resolved: we should do this.