> On Jul 20, 2016, at 2:04 PM, Robert Widmann via swift-evolution > <[email protected]> wrote: > >> >> On Jul 20, 2016, at 1:59 PM, Xiaodi Wu <[email protected] >> <mailto:[email protected]>> wrote: >> >> Why is hiding in-scope but renaming out-of-scope? > > > Because hiding and renaming can be used in combination to subset out APIs, > not alter them. >
I mistyped. Should be "Because hiding and using can be used in combination to subset out APIs, not alter them." >> Both are additive to Swift, > > As part of this proposal, both are source-breaking. > >> and as has been argued by others, the former is a special case of the latter. > > A special case that cannot cause large-scale file-relative changes to APIs. > Renaming is primarily used in other languages that treat free functions as > more canonical than we do, or allow operator definitions that can be used as > notation. In those cases, you often have your own notation you’d like to > use. In Swift, such changes should be rare enough that if you can’t solve > them with a disambiguating qualified import then you can just redeclare the > identifier some other way (typealias, top-level let, wrapper class, whatever). > >> >> On Wed, Jul 20, 2016 at 15:55 Brandon Knope <[email protected] >> <mailto:[email protected]>> wrote: >> I meant is there any reason for requiring parentheses >> >> On Jul 20, 2016, at 4:53 PM, Robert Widmann <[email protected] >> <mailto:[email protected]>> wrote: >> >>> Renaming is out of scope for this proposal, that’s why. >>> >>>> On Jul 20, 2016, at 1:26 PM, Brandon Knope <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> I prefer this 100x more >>>> >>>> Is there any reason why this wouldn't work? >>>> >>>> Brandon >>>> >>>> On Jul 20, 2016, at 4:13 PM, Xiaodi Wu <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>>> Yeah, I'd be happy to lose the parentheses as well. >>>>> >>>>> In the last thread, my take on simplifying the proposed syntax was: >>>>> >>>>> ``` >>>>> import Swift using String, Int >>>>> >>>>> // or, for hiding: >>>>> import Swift using Int as _ >>>>> ``` >>>>> >>>>> 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. >>>>> On Wed, Jul 20, 2016 at 15:01 Brandon Knope <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> >>>>> On Jul 20, 2016, at 3:08 PM, Xiaodi Wu via swift-evolution >>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>> >>>>>> 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: >>>>>> >>>>>> ``` >>>>>> import Swift using (String, Int) >>>>>> // imports only String and Int >>>>>> import Swift using (String, Int) hiding (String) >>>>>> // imports only Int >>>>>> import Swift hiding (String, Int) >>>>>> // imports everything except String and Int >>>>>> import Swift hiding (String, Int) using (String) >>>>>> // imports *nothing*? nothing except String? everything except Int? >>>>>> confusing. >>>>>> ``` >>>>>> >>>>>> By contrast, Joe's proposed syntax (with some riffs) produces something >>>>>> much more terse *and* much more clear: >>>>>> >>>>>> ``` >>>>>> import Swift.* >>>>>> import Swift.(Int as MyInt, *) >>>>>> import Swift.(Int as _, *) >>>>>> ``` >>>>> >>>>> I really don't find this much clearer than the proposed one. The proposal >>>>> reads much clearer. >>>>> >>>>> Joe's syntax has a lot going on in my opinion. >>>>> >>>>> For the proposal, do we really need the parentheses? It makes the syntax >>>>> look heavier >>>>> >>>>> Brandon >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> On Wed, Jul 20, 2016 at 1:52 PM, Robert Widmann via swift-evolution >>>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>>> Hello all, >>>>>> >>>>>> 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. >>>>>> >>>>>> It can be had inline with this email, on Github >>>>>> <https://github.com/apple/swift-evolution/pull/440>, or as a gist >>>>>> <https://gist.github.com/CodaFi/42e5e5e94d857547abc381d9a9d0afd6>. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> ~Robert Widmann >>>>>> >>>>>> Qualified Imports Revisited >>>>>> >>>>>> Proposal: SE-NNNN >>>>>> <https://gist.github.com/CodaFi/NNNN-first-class-qualified-imports.md> >>>>>> Authors: Robert Widmann <https://github.com/codafi>, TJ Usiyan >>>>>> <https://github.com/griotspeak> >>>>>> Status: Awaiting review >>>>>> Review manager: TBD >>>>>> >>>>>> >>>>>> <https://gist.github.com/CodaFi/42e5e5e94d857547abc381d9a9d0afd6#introduction>Introduction >>>>>> >>>>>> We propose a complete overhaul of the qualified imports syntax and >>>>>> semantics. >>>>>> >>>>>> >>>>>> >>>>>> <https://gist.github.com/CodaFi/42e5e5e94d857547abc381d9a9d0afd6#motivation>Motivation >>>>>> >>>>>> 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 >>>>>> >>>>>> import class Foundation.Date >>>>>> 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. >>>>>> >>>>>> >>>>>> >>>>>> <https://gist.github.com/CodaFi/42e5e5e94d857547abc381d9a9d0afd6#proposed-solution>Proposed >>>>>> solution >>>>>> >>>>>> 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. >>>>>> >>>>>> >>>>>> >>>>>> <https://gist.github.com/CodaFi/42e5e5e94d857547abc381d9a9d0afd6#detailed-design>Detailed >>>>>> design >>>>>> >>>>>> Qualified import syntax will be revised to the following >>>>>> >>>>>> import-decl -> import <import-path> <(opt) import-directive-list> >>>>>> import-path -> <identifier> >>>>>> -> <identifier>.<identifier> >>>>>> import-directive-list -> <import-directive> >>>>>> -> <import-directive> <import-directive-list> >>>>>> import-directive -> using (<identifier>, ...) >>>>>> -> hiding (<identifier>, ...) >>>>>> 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: >>>>>> >>>>>> 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. >>>>>> >>>>>> // The only visible parts of Foundation in this file are >>>>>> // Foundation.Date, Foundation.DateFormatter, and >>>>>> Foundation.DateComponents >>>>>> // >>>>>> // Previously, this was >>>>>> // import class Foundation.Date >>>>>> // import class Foundation.DateFormatter >>>>>> // import class Foundation.DateComponents >>>>>> import Foundation using (Date, DateFormatter, DateComponents) >>>>>> 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. >>>>>> >>>>>> // Imports all of Foundation except `Date` >>>>>> import Foundation hiding (Date) >>>>>> 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. >>>>>> >>>>>> // Imports `DateFormatter` but the declaration of `Date` is hidden. >>>>>> import Foundation using (DateFormatter) >>>>>> >>>>>> var d = DateFormatter().date(from: "...") // Valid >>>>>> var dt : Date = DateFormatter().date(from: "...") // Invalid: Cannot use >>>>>> name of hidden type. >>>>>> d.addTimeInterval(5.0) // Invalid: Cannot use members of hidden type. >>>>>> Import directives chain to one another and can be used to create a >>>>>> fine-grained module import: >>>>>> >>>>>> // This imports Swift.Int, Swift.Double, and Swift.String but hides >>>>>> Swift.String.UTF8View >>>>>> import Swift using (String, Int, Double) >>>>>> hiding (String.UTF8View) >>>>>> Directive chaining occurs left-to-right: >>>>>> >>>>>> // This says to 1) Use Int 2) Hide String 3) rename Double to Triple. >>>>>> It is invalid >>>>>> // because 1) Int is available 2) String is not, error. >>>>>> import Swift using (Int) hiding (String) >>>>>> // Valid. This will be merged as `using (Int)` >>>>>> import Swift using () using (Int) >>>>>> // Valid. This will be merged as `hiding (String, Double)` >>>>>> import Swift hiding (String) hiding (Double) hiding () >>>>>> // Valid (if redundant). This will be merged as `using ()` >>>>>> import Swift using (String) hiding (String) >>>>>> Because import directives are file-local, they will never be exported >>>>>> along with the module that declares them. >>>>>> >>>>>> >>>>>> >>>>>> <https://gist.github.com/CodaFi/42e5e5e94d857547abc381d9a9d0afd6#impact-on-existing-code>Impact >>>>>> on existing code >>>>>> >>>>>> 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. >>>>>> >>>>>> >>>>>> >>>>>> <https://gist.github.com/CodaFi/42e5e5e94d857547abc381d9a9d0afd6#alternatives-considered>Alternatives >>>>>> considered >>>>>> >>>>>> 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. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> swift-evolution mailing list >>>>>> [email protected] <mailto:[email protected]> >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> swift-evolution mailing list >>>>>> [email protected] <mailto:[email protected]> >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
