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

[Robert Widmann]

> On Jul 21, 2016, at 9:25 AM, Félix Cloutier <felixcca at yahoo.ca> wrote:
> 
>> 
>> Le 21 juil. 2016 à 08:48:22, Robert Widmann <devteam.codafi at gmail.com <mailto:devteam.codafi at gmail.com>> a écrit :
>> 
>> ~Robert Widmann
>> 
>> 2016/07/21 8:17、Félix Cloutier <felixcca at yahoo.ca <mailto:felixcca at yahoo.ca>> のメッセージ:
>> 
>>> I know that the compiler can't read my mind. I don't mean to be frustrating.
>>> 
>>> If Foundation is imported in the bridging header of a project (as it is today, by default, in Swift framework projects), you get all of Foundation in all of your Swift code without a chance to write "import Foundation hiding (...)" anywhere. This reinforces my position that types should be selected affirmatively.
>> 
>> I don't understand this at all.  The point of using and hiding is we create a file-local subset of identifiers you want to see.  Bridging headers do not change that.  I don't see how this is an example that affirmative is the *only* way to pick identifiers out of modules.
> 
> Here's a tiny Swift framework project: http://felixcloutier.com/tmp/SwiftImports.zip <http://felixcloutier.com/tmp/SwiftImports.zip>
> 
> The important part is that it has a Foo.h framework header, which #imports Cocoa. Through that, every Swift file in the project has access to everything that you get from <Cocoa/Cocoa.h>, as demonstrated by Foo.swift that creates a NSWindow without importing anything. Under the suggested model, I can't hide any of these symbols because the import does not happen on the Swift side, and there doesn't seem to be a way to break an ambiguity by hiding symbols in that case.
> 


import Cocoa hiding (NSWindow)

Done.  This specific case is one of the reasons why imports are file-local.

> I probably misused "bridging header" because I don't fully understand how symbols flow between Objective-C and Swift in frameworks.
> 
>> 
>>> 
>>> I'm not proposing a better solution because I don't have one right now. But if it would help appease you that I suggest something: keep "import using", let go of "hiding", and reuse the "using" keyword to select symbols from specific modules to break ambiguities. (Names must always be module-qualified to break ambiguities with classes that have the same name as a module.)
>> 
>> Halfway there.  Why is hiding such an issue?  Explain to me how with only using imports you can recreate the "import String without String.UTF8View" example in the proposal.
> 
> I'm pretty sure that I said that the example wasn't perfect. I wouldn't know how to do that. However, I don't know what else than breaking ambiguities you would want to use hiding for, and that example fully demonstrates how you would do that.

So it does.  Thank you for mocking this up.

> 
> Félix

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160721/5081eedb/attachment.html>