proposal: spec: make imported symbols predictable
Currently when a package is imported, it's not possible to tell what package name it uses without going to the package itself to see what name it uses. This can make it slow to analyse code (for example to jump to a symbol definition). For example, say we want to find the definition of the symbol `X` in the expression `m.X`. If m isn't defined in the local package, it's necessary to obtain a copy of every imported package's code to see if it's defined by any of them. For large packages, that can take a long time (many seconds). Even with caching proxies, it can still take a long time if the set of dependencies has recently changed. There's also the issue of cognitive overhead: just seeing an import statement is not sufficient to know what symbols that import statement brings into scope. For large programs, that overhead can be significant, and is worse when one or more of the dependencies are no longer available - the reader of the code is forced to guess what symbols are imported. This issue is even worse when "." imports are used to bring all a package's exported symbols into local scope. Even though dot-imports are [frowned upon](https://github.com/golang/go/wiki/CodeReviewComments#import-dot), there is still [no universal consensus](https://groups.google.com/d/msg/golang-nuts/PcMZGicbAFg/llxRhxsbDAAJ) that they should be avoided. The goimports tool already implicitly acknowledges this issue by adding an explicit package name when the symbol isn't clear from the import
Posted by rogpeppe on Nov 30, 2018, 12:54 PM
Tags
Related issues
- [Meta] Feedback on granular control over Copilot changes
- unexpected status 401 Unauthorized issue
- [MODEL] Measurable quality regression in Claude generation 5 (Fable 5 / Opus 5 / Sonnet 5): worse nonsense detection, ~2x verbosity, under-disclosed model fallb
- [CRITICAL] Subagent spawning and subagent pattern bugs trigger infinite recursion, infinite token usage, grossly inefficient token usage, and lost accumulated s
- Video stops playing after some minutes
- [MODEL] Claude verbose code comments by default — ignores instructions to stop.
Raise real-world problems, find people facing the same issue, and discuss solutions.4,000 issues0 comments
github (Software)
[Meta] Feedback on granular control over Copilot changes
unexpected status 401 Unauthorized issue
[MODEL] Measurable quality regression in Claude generation 5 (Fable 5 / Opus 5 / Sonnet 5): worse nonsense detection, ~2x verbosity, under-disclosed model fallb
[CRITICAL] Subagent spawning and subagent pattern bugs trigger infinite recursion, infinite token usage, grossly inefficient token usage, and lost accumulated s
Video stops playing after some minutes
[MODEL] Claude verbose code comments by default — ignores instructions to stop.
Scope Codex VS Code chats to the current workspace/project
Update on "Co-authored-by: Copilot" in commit messages
proposal: spec: make imported symbols predictable
Currently when a package is imported, it's not possible to tell what package name it uses without going to the package itself to see what name it uses. This can make it slow to analyse code (for example to jump to a symbol definition). For example, say we want to find the definition of the symbol `X` in the expression `m.X`. If m isn't defined in the local package, it's necessary to obtain a copy of every imported package's code to see if it's defined by any of them. For large packages, that can take a long time (many seconds). Even with caching proxies, it can still take a long time if the set of dependencies has recently changed. There's also the issue of cognitive overhead: just seeing an import statement is not sufficient to know what symbols that import statement brings into scope. For large programs, that overhead can be significant, and is worse when one or more of the dependencies are no longer available - the reader of the code is forced to guess what symbols are imported. This issue is even worse when "." imports are used to bring all a package's exported symbols into local scope. Even though dot-imports are [frowned upon](https://github.com/golang/go/wiki/CodeReviewComments#import-dot), there is still [no universal consensus](https://groups.google.com/d/msg/golang-nuts/PcMZGicbAFg/llxRhxsbDAAJ) that they should be avoided. The goimports tool already implicitly acknowledges this issue by adding an explicit package name when the symbol isn't clear from the import
Comments (0)
No comments yet. Start the discussion.