Allow code to shadow definitions in the Foundation module #61642
Conversation
|
@swift-ci please test |
1 similar comment
|
@swift-ci please test |
There was a problem hiding this comment.
What is the motivation for this change? If there was a clearer picture of the need behind this, perhaps a different solution would be better.
At first brush, I do not think elevating Foundation to have this special status makes sense, because it has to be explicitly imported, so you already have to opt-in to having its declarations in scope. The standard library is always implicitly imported, so we need the shadowing behavior to not disrupt declarations from explicit imports, etc.
|
@swift-ci Please Build Toolchain macOS Platform |
iCharlesHu
force-pushed
the
shadow-foundation
branch
from
0778b02 to
4fa8296
Compare
|
@swift-ci please test |
|
|
||
| // REQUIRES: objc_interop | ||
|
|
||
| import Foundation |
There was a problem hiding this comment.
I'm not quite sure what the changes in this Constraints test does for us, especially now that the shadowing change is behind a feature flag.
I think any test changes other than for the new foundation-module-shadowing.swift should be reverted so they cover what they did previously.
|
@swift-ci Please Build Toolchain macOS Platform |
1 similar comment
|
@swift-ci Please Build Toolchain macOS Platform |
This PR implements the same type of shadowing rule to the
Foundationmodule that applies to the Swift standard library: unqualified references to declarations imported from both theFoundationmodule and some other moduleAwill always prefer moduleA's declaration.See #58625 and #34642