[swift-evolution] Beef up Imports

[Pyry Jahkola]

> On 27 Dec 2015, at 07:12, Developer via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Therefore, I propose the introduction of 3 agda-esque operations for imports to replace the usual `import {func|typealias|struct|class|enum|etc.}` syntax:
> 
> 	• import Foo using (bar, Baz, qux, corge, …)
> 	• import Foo hiding (bar, baz, qux, corge, …)
> 	• import Foo renaming (grault to garply, waldo to fred, …)

+1, but why not just…?

import Foo using (bar, Baz, qux, waldo as fred)  // a "whitelist import"
import Foo hiding (bar, Baz, qux, waldo as fred) // a "blacklist import"

I've been able to work around identifier conflicts with the present import syntax but it gets clumsy with larger modules. I think both import-using and import-hiding would be very welcome in Swift, but the third notation made me double check its semantics from The Agda Wiki. Turns out <http://wiki.portal.chalmers.se/agda/pmwiki.php?n=ReferenceManual.Modules#mods> the renaming (...) syntax is actually an extension to the other two and is often used as a part of the one or the other:

import Foo using (bar, Baz, qux) renaming (waldo to fred)
import Foo hiding (bar, Baz, qux) renaming (waldo to fred)

Why not do without renaming? Just allow both import-using and import-hiding to optionally rename imported identifiers. Further, while these keywords can and should be made context-specific, I think it's simplest to reuse "as" as the associating keyword.

That would lead us to the proposed syntax:

import Foo using (bar, Baz, qux, waldo as fred)  // a "whitelist import"
import Foo hiding (bar, Baz, qux, waldo as fred) // a "blacklist import"

where the tuple-like parentheses enclose a potentially empty list of identifiers or "identifier as identifier" mappings. The examples below should clarify the meaning and intended use of these two statements.

> Again, it should be obvious by uniqueness of identifiers what each one is referencing, so qualification of each identifier is unnecessary.


Agreed. In addition, extending the import statement to class/enum/struct members doesn't make sense to me. Those don't conflict with the global scope at all.

— Pyry Jahkola


P.S. If this turns into a formal proposal, should we also address how imported operators should be dealt with? Can operators be selectively imported, hidden, or renamed? If renaming is made possible, we should be explicit on how the renamed operator inherits its associativity and precedence from the original one.


Examples

Suppose the module Foo contains the following identifiers:

// module Foo:
// - bar, Baz, qux, waldo

The "import-all" remains as it is in Swift 2:

import Foo

_ = (bar, Baz.self, qux, waldo) // All identifiers can be unqualified.

The "import-all" is synonymous with the longer "hide-nothing":

import Foo hiding ()

To hide or rename an identifier, fill in the parentheses:

import Foo hiding (Baz, waldo as fred)

_ = (bar, qux, fred)            // These names can be unqualified.
_ = (Foo.Baz.self, Foo.waldo)   // These names must be qualified.
_ = Foo.fred                    // Compiler error!

To import selectively, potentially renaming identifiers, use the import-using syntax:

import Foo using (Baz as FooBaz, qux, waldo as fred)

_ = (FooBaz.self, qux, fred)    // These names can be unqualified.
_ = (Foo.Baz.self, Foo.bar)     // These names must be qualified.

Finally, it's possible to require qualified use of the Foo module:

import Foo using ()

_ = (Foo.bar, Foo.Baz.self, Foo.qux, Foo.waldo) // OK.
_ = (bar, Baz.self, qux, waldo) // Compiler error x 4!

End.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151227/591d5e59/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151227/591d5e59/attachment.sig>