> On Jul 21, 2016, at 9:25 AM, Félix Cloutier <[email protected]> wrote: > >> >> Le 21 juil. 2016 à 08:48:22, Robert Widmann <[email protected] >> <mailto:[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 > <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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
