-
-
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
Deprecate module_name in favor of nameof(::Module) #25622
Conversation
I do find the proposed behavior of the |
We could have a more general |
I really like |
There is a |
9c94ab7
to
6e8135c
Compare
Okay, I've introduced the |
6e8135c
to
bb76caa
Compare
The doc build is failing because of this in DocStringExtensions: https://github.com/JuliaDocs/DocStringExtensions.jl/blob/22fe6a3ea2d8a194dc781ae8263a81c815e49926/src/abbreviations.jl#L137-L139 I'll submit a PR to change the loop variable name there. Edit: JuliaDocs/DocStringExtensions.jl#50 |
bb76caa
to
b7a9134
Compare
Not sure yet what's going on with the Documenter/DocStringExtensions failure... |
Need Line 2 in 625923f
|
Weird, I could have sworn I pushed that... |
6964570
to
285dfa0
Compare
Still getting the failure even with that change. |
285dfa0
to
67e9dc7
Compare
I'm not getting any errors while running locally so let's see what happens now... |
stdlib/REPL/src/REPLCompletions.jl
Outdated
@@ -72,7 +72,7 @@ function complete_symbol(sym, ffunc) | |||
# We will exclude the results that the user does not want, as well | |||
# as excluding Main.Main.Main, etc., because that's most likely not what | |||
# the user wants | |||
p = s->(!Base.isdeprecated(mod, s) && s != module_name(mod) && ffunc(mod, s)) | |||
p = s->(!Base.isdeprecated(mod, s) && s != name(mod) && ffunc(mod, s)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, the downside of very generic function names --- conflicts with a local variable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about we call this nameof
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd be fine with that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 Yeah, it's a good idea to avoid "stealing" simple words like name
when possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nameof
it is.
00c9369
to
a35c2d4
Compare
a35c2d4
to
b262a61
Compare
As suggested by @Sacha0 and @martinholters in #25436.
This deprecates
module_name(::Module)
in favor ofSymbol(::Module)
nameof(::Module)
.This is technically breaking, since currently theSymbol
constructor on modules falls back toSymbol(string(::Module))
, which uses the entire module hierarchy (e.g.LinAlg
->Symbol("Base.LinAlg")
), and with this PR it would be the top name only (e.g.LinAlg
->:LinAlg
). The current behavior will still be available asSymbol(join(fullname(m), '.'))
.If this is accepted, I think we should also fold
function_name
anddatatype_name
intoSymbol
constructors.(I'm actually not super convinced that I like this, but I figured it's worth exploring.)