[swift-evolution] Beef up Imports

[Kevin Ballard]

The reason why I say that we don't really need renaming is because you
only need renaming in order to avoid conflicts, and you can avoid
conflicts just by using a qualified import instead. As an example, if I
want to import some library that declares its own Result type, but I of
course have my own Result type as well, then I might say something like

import FrobLib hiding (Result) import qualified FrobLib (Result)

This will get me all of FrobLib except for Result, and also let me use
`FrobLib.Result` whenever I do need to reference that library's Result
type. Or if I need to reference it frequently I might even say

import qualified FrobLib as F (Result)

so I can just use `F.Result`.

In my experience, there's not much need for renaming once you can do
this with qualified imports.

-Kevin Ballard

On Tue, Jan 5, 2016, at 05:44 PM, Simon Pilkington wrote:
> 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), 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/20160107/0a4f1e3f/attachment.html>