-
-
Notifications
You must be signed in to change notification settings - Fork 5.7k
Deprecate module_name in favor of nameof(::Module) #25622
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
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
| # 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 theSymbolconstructor 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_nameanddatatype_nameintoSymbolconstructors.(I'm actually not super convinced that I like this, but I figured it's worth exploring.)