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]> 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]> wrote: >> >> >>> On Jul 20, 2016, at 3:08 PM, Xiaodi Wu via swift-evolution >>> <[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]> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
