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 > <[email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
