<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">Le 21 juil. 2016 à 08:48:22, Robert Widmann <<a href="mailto:devteam.codafi@gmail.com" class="">devteam.codafi@gmail.com</a>> a écrit :</div><div class=""><div dir="auto" class=""><div class=""><br class="">~Robert Widmann</div><div class=""><br class="">2016/07/21 8:17、Félix Cloutier <<a href="mailto:felixcca@yahoo.ca" class="">felixcca@yahoo.ca</a>> のメッセージ:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div class="">I know that the compiler can't read my mind. I don't mean to be frustrating.</div><div class=""><br class=""></div><div class="">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.</div></div></blockquote><div class=""><br class=""></div><div class="">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.</div></div></div></blockquote><div><br class=""></div><div>Here's a tiny Swift framework project: <a href="http://felixcloutier.com/tmp/SwiftImports.zip" class="">http://felixcloutier.com/tmp/SwiftImports.zip</a></div><div><br class=""></div><div>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.</div><div><br class=""></div><div>I probably misused "bridging header" because I don't fully understand how symbols flow between Objective-C and Swift in frameworks.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><br class=""><blockquote type="cite" class=""><div class=""><br class=""></div><div class="">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.)</div></blockquote><div class=""><br class=""></div><div class="">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.</div></div></div></blockquote><br class=""></div><div>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.</div><div><br class=""></div><div>Félix</div><br class=""></body></html>