<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 21, 2016, at 9:41 AM, Joe Groff <<a href="mailto:jgroff@apple.com" class="">jgroff@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><blockquote type="cite" class="">On Jul 20, 2016, at 1:59 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">Why is hiding in-scope but renaming out-of-scope? Both are additive to Swift, and as has been argued by others, the former is a special case of the latter.<br class=""></blockquote><br class="">Hiding also doesn't seem useful to me at all. The main use case I can see is to resolve a name conflict introduced between two import-everything declarations, or between an imported and local name, and both of these use cases seem better served to me by a name lookup rule that locals are favored over qualified imports, which in turn are favored over everything imports. 'hiding' puts the import declaration in the wrong place. Consider that:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>import Foo hiding foo<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>import Bar<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>foo()<br class=""><br class="">declares the un-import of 'foo' next to 'Foo'. The user (or IDE) has to do the mental gymnastics to figure out that 'foo()' refers to Bar.foo() by omission. This is much clearer expressed with 'using', which puts the disambiguation next to the chosen module:<br class=""><br class=""></div></div></blockquote><div><br class=""></div><div>We were already doing those gymnastics before (in fact, one of the diagnostics for the old style would remind you of the correct decl kind if you thought a struct was a class etc. Clearly, we already know). If you want to be explicit, </div><div><br class=""></div><div>import Bar using (foo)</div><div>import Foo hiding (foo)</div><div><br class=""></div><div>import Bar</div><div><br class=""></div><div>Works just fine. </div><div><br class=""></div><div>The lookup rule seems to be justifying introducing the “confusing” example above. It would definitely work, but why not just be explicit about what you’re using and what you’re hiding?</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>import Foo<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>import Bar<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>import Bar using foo // favor Bar.foo over Foo.foo<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>foo()<br class=""><br class="">'using' is also more resilient against module evolution; as modules gain new members, their clients would potentially be forced to play whack-a-mole with 'hiding' as new conflicts are introduced. A user who diligently uses qualified imports doesn't need to worry about that. I would suggest removing 'hiding' in favor of a rule like this.<br class=""></div></div></blockquote><div><br class=""></div><div>Is this not the same case with using declarations as the <i class="">client</i> module evolves? It is more likely that a using import will grow in size as a module evolves than a hiding one - after all a hiding import says you explicitly intend to use everything else. And if you start hiding enough identifiers that it becomes unwieldy you can always flip the script and use a using directive. The same applies the other way around for big using clauses.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">-Joe<br class=""><br class=""><blockquote type="cite" class="">On Wed, Jul 20, 2016 at 15:55 Brandon Knope <<a href="mailto:bknope@me.com" class="">bknope@me.com</a>> wrote:<br class="">I meant is there any reason for requiring parentheses <br class=""><br class="">On Jul 20, 2016, at 4:53 PM, Robert Widmann <<a href="mailto:rwidmann@apple.com" class="">rwidmann@apple.com</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">Renaming is out of scope for this proposal, that’s why.<br class=""><br class=""><blockquote type="cite" class="">On Jul 20, 2016, at 1:26 PM, Brandon Knope <<a href="mailto:bknope@me.com" class="">bknope@me.com</a>> wrote:<br class=""><br class="">I prefer this 100x more<br class=""><br class="">Is there any reason why this wouldn't work?<br class=""><br class="">Brandon <br class=""><br class="">On Jul 20, 2016, at 4:13 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">Yeah, I'd be happy to lose the parentheses as well.<br class=""><br class="">In the last thread, my take on simplifying the proposed syntax was:<br class=""><br class="">```<br class="">import Swift using String, Int<br class=""><br class="">// or, for hiding:<br class="">import Swift using Int as _<br class="">```<br class=""><br class="">The key simplification here is that hiding doesn't need its own contextual keyboard, especially if we support renaming (a huge plus in my book), as renaming to anything unused (or explicitly to `_`) is what hiding is all about.<br class="">On Wed, Jul 20, 2016 at 15:01 Brandon Knope <<a href="mailto:bknope@me.com" class="">bknope@me.com</a>> wrote:<br class=""><br class=""><br class="">On Jul 20, 2016, at 3:08 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">As Joe and others mentioned in the previous thread, this syntax could be greatly simplified in ways that resemble analogous facilities in other languages. In particular I think it's alarmingly asymmetrical that, in your proposal, `import Swift using (String)` imports *only* String while `import Swift hiding (String)` imports *everything but* String. This becomes evident when chained together:<br class=""><br class="">```<br class="">import Swift using (String, Int)<br class="">// imports only String and Int<br class="">import Swift using (String, Int) hiding (String)<br class="">// imports only Int<br class="">import Swift hiding (String, Int)<br class="">// imports everything except String and Int<br class="">import Swift hiding (String, Int) using (String)<br class="">// imports *nothing*? nothing except String? everything except Int? confusing.<br class="">```<br class=""><br class="">By contrast, Joe's proposed syntax (with some riffs) produces something much more terse *and* much more clear:<br class=""><br class="">```<br class="">import Swift.*<br class="">import Swift.(Int as MyInt, *)<br class="">import Swift.(Int as _, *)<br class="">```<br class=""></blockquote><br class="">I really don't find this much clearer than the proposed one. The proposal reads much clearer. <br class=""><br class="">Joe's syntax has a lot going on in my opinion.<br class=""><br class="">For the proposal, do we really need the parentheses? It makes the syntax look heavier<br class=""><br class="">Brandon <br class=""><br class=""><br class=""><br class=""><blockquote type="cite" class=""><br class=""><br class="">On Wed, Jul 20, 2016 at 1:52 PM, Robert Widmann via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class="">Hello all,<br class=""><br class="">I’d like to thank the members of the community that have guided the revisions of this proposal. We have decided to heed the advice of the community and break down our original proposal on modules and qualified imports into source-breaking (qualified imports) and additive (modules) proposals. As qualified imports is the change most suited to Swift 3, we are pushing that proposal now as our final draft.<br class=""><br class="">It can be had inline with this email, on Github, or as a gist.<br class=""><br class="">Thanks,<br class=""><br class="">~Robert Widmann<br class=""><br class="">Qualified Imports Revisited<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• Proposal: SE-NNNN<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• Authors: Robert Widmann, TJ Usiyan<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• Status: Awaiting review<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• Review manager: TBD<br class=""><br class="">Introduction<br class=""><br class="">We propose a complete overhaul of the qualified imports syntax and semantics.<br class=""><br class=""><br class="">Motivation<br class=""><br class="">The existing syntax for qualified imports from modules is needlessly explicit, does not compose, and has a default semantics that dilutes the intended meaning of the very operation itself. Today, a qualified import looks something like this<br class=""><br class="">import class Foundation.Date<br class="">This means that clients of Foundation that wish to see only Date must know the exact kind of declaration that identifier is. In addition, though this import specifies exactly one class be imported from Foundation, the actual semantics mean Swift will recursively open all of Foundation's submodules so you can see, and use, every other identifier anyway - and they are not filtered from code completion. Qualified imports deserve to be first-class in Swift, and that is what we intend to make them with this proposal.<br class=""><br class=""><br class="">Proposed solution<br class=""><br class="">The grammar and semantics of qualified imports will change completely with the addition of import qualifiers and import directives. We also introduce two new contextual keywords: using and hiding, to facilitate fine-grained usage of module contents.<br class=""><br class=""><br class="">Detailed design<br class=""><br class="">Qualified import syntax will be revised to the following<br class=""><br class="">import-decl -> import <import-path> <(opt) import-directive-list><br class="">import-path -> <identifier><br class=""> -> <identifier>.<identifier><br class="">import-directive-list -> <import-directive><br class=""> -> <import-directive> <import-directive-list><br class="">import-directive -> using (<identifier>, ...)<br class=""> -> hiding (<identifier>, ...)<br class=""><br class="">This introduces the concept of an import directive. An import directive is a file-local modification of an imported identifier. A directive can be one of 2 operations:<br class=""><br class="">1) using: The using directive is followed by a list of identifiers for non-member nominal declarations within the imported module that should be exposed to this file. <br class=""><br class="">// The only visible parts of Foundation in this file are <br class="">// Foundation.Date, Foundation.DateFormatter, and Foundation.DateComponents<br class="">//<br class="">// Previously, this was<br class="">// import class Foundation.Date<br class="">// import class Foundation.DateFormatter<br class="">// import class Foundation.DateComponents<br class="">import Foundation using (Date, DateFormatter, DateComponents)<br class="">2) hiding: The hiding directive is followed by a list of identifiers for non-member nominal declarations within the imported module that should be hidden from this file.<br class=""><br class="">// Imports all of Foundation except `Date`<br class="">import Foundation hiding (Date)<br class="">As today, all hidden identifiers do not hide the type, they merely hide that type’s members and its declaration. For example, this means values of hidden types are still allowed. Unlike the existing implementation, using their members is forbidden.<br class=""><br class="">// Imports `DateFormatter` but the declaration of `Date` is hidden.<br class="">import Foundation<br class=""> using (DateFormatter)<br class=""><br class=""><br class="">var d = DateFormatter().date(from: "...") // Valid<br class="">var dt : Date = DateFormatter().date(from: "...") // Invalid: Cannot use name of hidden type.<br class=""><br class="">d<br class="">.addTimeInterval(5.0) // Invalid: Cannot use members of hidden type.<br class="">Import directives chain to one another and can be used to create a fine-grained module import:<br class=""><br class="">// This imports Swift.Int, Swift.Double, and Swift.String but hides Swift.String.UTF8View<br class="">import Swift using (String, Int, Double<br class="">) <br class=""> hiding (<br class="">String.UTF8View)<br class="">Directive chaining occurs left-to-right:<br class=""><br class="">// This says to 1) Use Int 2) Hide String 3) rename Double to Triple. It is invalid<br class="">// because 1) Int is available 2) String is not, error.<br class="">import Swift using (Int) hiding (String<br class="">)<br class=""><br class="">// Valid. This will be merged as `using (Int)`<br class="">import Swift using () using (Int<br class="">)<br class=""><br class="">// Valid. This will be merged as `hiding (String, Double)`<br class="">import Swift hiding (String) hiding (Double<br class="">) hiding ()<br class=""><br class="">// Valid (if redundant). This will be merged as `using ()`<br class="">import Swift using (String) hiding (String)<br class="">Because import directives are file-local, they will never be exported along with the module that declares them.<br class=""><br class=""><br class="">Impact on existing code<br class=""><br class="">Existing code that is using qualified module import syntax (import {func|class|typealias|class|struct|enum|protocol} <qualified-name>) will be deprecated and should be removed or migrated. <br class=""><br class=""><br class="">Alternatives considered<br class=""><br class="">A previous iteration of this proposal introduced an operation to allow the renaming of identifiers, especially members. The original intent was to allow file-local modifications of APIs consumers felt needed to conform to their specific coding style. On review, we felt the feature was not as significant as to warrant inclusion and was ripe for abuse in large projects.<br class=""><br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""><br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class="">swift-evolution@swift.org<br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></blockquote></blockquote></blockquote><br class=""></blockquote>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></blockquote><br class=""></div></div></blockquote></div><br class=""></body></html>