[swift-evolution] [Proposal][Discussion] Qualified Imports

[Leonardo Pessoa]

I'm not very fond of this proposal at all as I don't believe there
will be much gain with it (correct me if I'm wrong but libraries in
Swift are monolithic and nothing to Java, where there is a benefit in
doing this). That said, if this really has to go, Joe's syntax seems
much cleaner but I'd drop the requirement for a dot and implicitly
require anything by omiting the parenthesis. Thus:

   import Swift
   import Swift(Int as MyInt, *)
   import Swift(Int as _, *)

Also supporting this form does not break existing code since the first
option here is how we already do.

L

On 20 July 2016 at 16:08, Xiaodi Wu via swift-evolution
<swift-evolution at swift.org> 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 _, *)
> ```
>
>
> On Wed, Jul 20, 2016 at 1:52 PM, Robert Widmann via swift-evolution
> <swift-evolution at swift.org> 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
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>