~Robert Widmann

2016/07/21 0:13、Pyry Jahkola via swift-evolution <[email protected]> 
のメッセージ:

> 
>>> On 21 Jul 2016, at 09:51, Robert Widmann via swift-evolution 
>>> <[email protected]> wrote:
>>> 
>>> On Jul 20, 2016, at 9:37 PM, Félix Cloutier via swift-evolution 
>>> <[email protected]> wrote:
>>> 
>>> The problem is that by specifying "import Foo using (Baz)", I get nothing 
>>> else from Foo. If I only want to exclude one conflicting name, I would have:
>>> 
>>>> import Foo
>>>> import Bar hiding (Baz)
>>> 
>>> In case of a conflict, my "internal monologue" is more like "take Baz from 
>>> Foo" than "don't take Baz from Bar".
>> 
>> How else would you resolve an ambiguity than by selecting the appropriate 
>> declaration and hiding the others?  Swift’s semantic analysis cannot read 
>> your mind, and neither can your (or mine) proposal for renaming syntax - in 
>> that you still have to import both modules either way.  You may as well be 
>> explicit about which name you’re actually using and which ones you’re 
>> actually hiding, eh?
> 
> Simple! You don't need to hide the others if we enforce a rule that 
> explicitly mentioning one in the current file imports that name as a 
> fileprivate identifier which shadows the ones not explicitly mentioned:

What you're describing is making a distinction between an open module and an 
imported module and is both additive and out of scope for this particular 
proposal.  We didn't want to touch module re-exports until that proposal came 
up later.  This is a fantastic idea that we have plans to incorporate in there 
nonetheless.  This distinction is far more powerful than our current approach 
of just opening every module that gets imported into the top level namespace.

> 
>     import A using (X)
>     import B // also exports X which gets shadowed by A.X
>     import C // also exports X which gets shadowed by A.X
> 
>     assert(X.self == A.X.self)
>     assert(X.self != B.X.self)
>     assert(X.self != C.X.self)
>     
>     import D using (X)
>     // error: invalid redeclaration of 'X'
>     // note: previously declared here: 'import A using (X)'
>     
>     typealias X = Int
>     // error: invalid redeclaration of 'X'
>     // note: previously declared here: 'import A using (X)'
> 
> That would go nicely hand-in-hand with the idea that explicitly importing a 
> module with a qualified name brings in the name of that module to the current 
> file's scope:
> 
>     import A      // ok, unqualified import keeps A as a second-class 
> identifier
>     import B as B // ok, qualified import makes B a first-class identifier in 
> file scope
>     
>     typealias A = Int // ok, shadows the module name A
>     
>     typealias B = Int
>     // error: invalid redeclaration of 'Bar'
>     // note: previously declared here: 'import Bar as Bar'
> 
> Couldn't we find a synthesis with both the explicit qualification of modules 
> and the explicit selection of imported names? I would strongly support that.
> 
> — Pyry
> 
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to