-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
uninitialized typed global can only be imported qualified and not directly #54954
Labels
bug
Indicates an unexpected problem or unintended behavior
Comments
Can you give an example reproducer for your error message, and a minimal example of desired behavior? |
here a short sketch module MyPackage
using Configurations: @option
@option struct MyConfigType
specialconfig::Bool = false
end
global CONFIG::MyConfigType
module SubModule
using MyPackage: CONFIG
function do_something_configurable()
if CONFIG.specialconfig
print("yeah")
end
end
end
function main()
CONFIG = MyConfigType(specialconfig=true)
SubModule.do_something_configurable()
end
end and then call |
I think this is just a bug that happened when this syntax got added. Will put up a PR. |
Keno
added
bug
Indicates an unexpected problem or unintended behavior
and removed
feature
Indicates new feature / enhancement requests
labels
Jun 27, 2024
Keno
added a commit
that referenced
this issue
Jun 27, 2024
In `using A.B`, we need to evaluate `A.B` to add the module to the using list. However, in `using A: B`, we do not care about the value of `A.B`, we only operate at the binding level. These two operations share a code path and the evaluation of `A.B` happens early and is unused on the `using A: B` path. I believe this was an unintentional oversight when the latter syntax was added. Fixes #54954.
KristofferC
pushed a commit
that referenced
this issue
Jul 23, 2024
In `using A.B`, we need to evaluate `A.B` to add the module to the using list. However, in `using A: B`, we do not care about the value of `A.B`, we only operate at the binding level. These two operations share a code path and the evaluation of `A.B` happens early and is unused on the `using A: B` path. I believe this was an unintentional oversight when the latter syntax was added. Fixes #54954. (cherry picked from commit 89e391b)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Following up on this discourse thread I want to raise awareness to uninitialized typed global variables.
It is an awesome concept which I'd like to use for initializing secret config values at initial runtime (at the start of my main-method).
However unfortunately they can only be imported via qualified access. My case is that I want to import it from a submodule which fails.
import TopLevelProject
and accessing it withTopLevelProject.variable
works.using TopLevelProject: variable
gives the errorERROR: LoadError: UndefVarError: variable not defined
, even if the variable is not actually used within top-level statements, but just inside functions.It would be awesome if the variable an already be referenced, even though it is not yet initialized.
The text was updated successfully, but these errors were encountered: