[swift-evolution] Beef up Imports

[Simon Pilkington]

I like the fact that this would retain simplicity for basic uses - developers could continue to use 'import Mod' and not even know about the more advanced syntax unless they need that power. The additional syntax seems like a natural progression from the base case.

Kevin, I understand the motivation for not really needed renaming for qualified imports but it feels like we would still need them for unqualified/global ones.  Do you think this is a valid use case? As suggested previously I think this would be least confusing/ambiguous by using a seperate renaming syntax -
import Mod hiding (x,y) renaming (z as zz)

An import statement such as above could equally be handled by seperate imports - one for hiding and one for renaming - and it might be worth being flexible and support both styles.

+1 to submodules as well, particularly if integrated into SPM to help optimise/reduce compile times when a module depends only on part of an otherwise related group of functionality that should be vended/consumed/versioned together.

-Simon

> On 29 Dec 2015, at 11:47 AM, Kevin Ballard via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I like the idea here, but I'm not sold on the syntax. I also do explicitly want an `import qualified`. And with qualified imports, I question whether we really need to support renaming in the import syntax here.
>  
> I'm tempted to say we should just crib Haskell's import rules (https://wiki.haskell.org/Import <https://wiki.haskell.org/Import>), with the minor change that importing members by name still makes them accessible via the module name too (in Haskell `import Mod (x, y)` makes `x` and `y` visible but does not make `Mod.x` or `Mod.y` visible). This lets you say things like
>  
> import Mod // imports Mod and all its members
> import Mod () // only provides access to protocol conformances declared in Mod, doesn't actually import anything
> import Mod (x,y) // imports `x` and `y`, which are also accessible as e.g. `Mod.x`, but does not provide `z` or `Mod.z`
> import qualified Mod // imports Mod but all access to members has to go through it, e.g. `Mod.x`
> import qualified Mod (x,y) // imports Mod but only provides access to `Mod.x` and `Mod.y` but not e.g. `Mod.z`
> import Mod hiding (x,y) // imports Mod and its members except for `x` or `y`
> import qualified Mod hiding (x,y) // imports e.g. `Mod.z` but not `Mod.x` or `Mod.y`
> import Mod as Foo // imports Mod and renames the module to Foo, so e.g. `x` and `Foo.x` are accessible
> import Mod as Foo (x,y) // renames Mod to Foo, provides `x`, `y`, `Foo.x`, and `Foo.y`
> import qualified Mod as Foo // renames Mod to Foo, all members are accessible via the module e.g. `Foo.x`
> import qualified Mod as Foo (x,y) // renames Mod to Foo, provides access to `Foo.x` and `Foo.y` but not e.g. `Foo.z`
>  
> Furthermore, you can have multiple import statements from the same module, so you can say something like
>  
> import qualified Mod
> import Mod (x,y)
>  
> to provide access to all of Mod qualified with the name, and additionally import `x` and `y` as unqualified identifiers.
>  
> -Kevin Ballard
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160106/254e0519/attachment.html>