> Le 21 juil. 2016 à 08:48:22, Robert Widmann <[email protected]> a 
> écrit :
> 
> ~Robert Widmann
> 
> 2016/07/21 8:17、Félix Cloutier <[email protected] <mailto:[email protected]>> 
> のメッセージ:
> 
>> 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

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.

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.

Félix

_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to