> On Jul 20, 2016, at 5:56 PM, Robert Widmann <[email protected]> wrote: > > Max and I had a discussion about how overloading would work here. We came to > the conclusion that we probably don’t need an “overload picker” because it > defeats the point of an overloaded name in the first place. > > As for the extension members, the current qualified import mechanism doesn’t > allow you to get that specific and I don’t see a reason why we should either. > Plus we dropped member imports from the revision :)
I suppose it can be added later, but I consider the inability to deal with extension method conflicts to be a pretty serious language shortcoming today. It would be nice to fix that. -Joe > That can come later as an additive change on top of this system. > >> On Jul 20, 2016, at 5:53 PM, Joe Groff <[email protected]> wrote: >> >> One thing to consider is that Swift has compound names, and also extension >> members, which are modularized but also scoped to the extended nominal type >> or protocol. Extension method collisions are a non-theoretical issue. >> Whatever bikeshed we pick, we'll want a syntax able to support something >> like this: >> >> // Pick Int extension members from Module >> import Module using Int.extensionProperty, Int.extensionMethod(label:) >> >> Maybe there's also a need to pick a specific decl out of an overload set by >> type. I hope not… >> >> -Joe >> >>> On Jul 20, 2016, at 11:52 AM, Robert Widmann via swift-evolution >>> <[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, or as a gist. >>> >>> Thanks, >>> >>> ~Robert Widmann >>> >>> Qualified Imports Revisited >>> >>> • Proposal: SE-NNNN >>> • Authors: Robert Widmann, TJ Usiyan >>> • Status: Awaiting review >>> • Review manager: TBD >>> >>> Introduction >>> >>> We propose a complete overhaul of the qualified imports syntax and >>> semantics. >>> >>> >>> 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. >>> >>> >>> 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. >>> >>> >>> 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. >>> >>> >>> 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. >>> >>> >>> 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] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
