[swift-evolution] [Proposal][Discussion] Qualified Imports

[L. Mihalkovic]

Regards
(From mobile)

> On Jul 21, 2016, at 9:20 AM, Robert Widmann via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> 
> ~Robert Widmann
> 
> 2016/07/21 0:13、Pyry Jahkola via swift-evolution <swift-evolution at swift.org> のメッセージ:
> 
>> 
>>>> On 21 Jul 2016, at 09:51, Robert Widmann via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>> On Jul 20, 2016, at 9:37 PM, Félix Cloutier via swift-evolution <swift-evolution at swift.org> 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.
> 

But it is a very limiting approach as has been seen in other languages and described here... designing a good system is as much about what it does today as what it will allow tomorrow and at what cost. Addressing the needs of today in a carpe diem fashion is an approach that works well when u are unsure if there will ever be a tomorrow, not for building the foundations of a legacy. To quote someone smarter "today's solutions are tomorrow's problems".

>> 
>>     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
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160721/d1f85d98/attachment.html>