<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><div>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<br></div>
<div> </div>
<div>import FrobLib hiding (Result)<br></div>
<div>import qualified FrobLib (Result)<br></div>
<div> </div>
<div>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<br></div>
<div> </div>
<div>import qualified FrobLib as F (Result)<br></div>
<div> </div>
<div>so I can just use `F.Result`.<br></div>
<div> </div>
<div>In my experience, there's not much need for renaming once you can do this with qualified imports.<br></div>
<div> </div>
<div>-Kevin Ballard<br></div>
<div> </div>
<div>On Tue, Jan 5, 2016, at 05:44 PM, Simon Pilkington wrote:<br></div>
<blockquote type="cite"><div>I like the fact that this would retain simplicity for basic uses - developers could continue to use '<b>import</b> 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.<br></div>
<div> </div>
<div>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 <b>renaming</b> syntax -<br></div>
<div><b>import</b> Mod <b>hiding</b> (x,y) <b>renaming</b> (z as zz)<br></div>
<div> </div>
<div>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.<br></div>
<div> </div>
<div>+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.<br></div>
<div> </div>
<div>-Simon<br></div>
<div> </div>
<div><blockquote type="cite"><div>On 29 Dec 2015, at 11:47 AM, Kevin Ballard via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div>
<div> </div>
<div><div><div>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.<br></div>
<div> </div>
<div>I'm tempted to say we should just crib Haskell's import rules (<a href="https://wiki.haskell.org/Import">https://wiki.haskell.org/Import</a>), 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<br></div>
<div> </div>
<div><span class="font" style="font-family:menlo, consolas, 'courier new', monospace, sans-serif"><b>import</b> Mod // imports Mod and all its members</span><br></div>
<div><span class="font" style="font-family:menlo, consolas, 'courier new', monospace, sans-serif"><b>import</b> Mod () // only provides access to protocol conformances declared in Mod, doesn't actually <b>import</b> anything</span><span class="font" style="font-family:menlo, consolas, 'courier new', monospace, sans-serif"></span><br></div>
<div><span class="font" style="font-family:menlo, consolas, 'courier new', monospace, sans-serif"><b>import</b> Mod <b>(</b>x,y<b>)</b> // imports `x` and `y`, which are also accessible as e.g. `Mod.x`, but does not provide `z` or `Mod.z`</span><span class="font" style="font-family:menlo, consolas, 'courier new', monospace, sans-serif"></span><br></div>
<div><span class="font" style="font-family:menlo, consolas, 'courier new', monospace, sans-serif"><b>import qualified</b> Mod // imports Mod but all access to members has to go through it, e.g. `Mod.x`</span><span class="font" style="font-family:menlo, consolas, 'courier new', monospace, sans-serif"></span><br></div>
<div><span class="font" style="font-family:menlo, consolas, 'courier new', monospace, sans-serif"><b>import qualified</b> Mod <b>(</b>x,y<b>)</b> // imports Mod but only provides access to `Mod.x` and `Mod.y` but not e.g. `Mod.z`</span><span class="font" style="font-family:menlo, consolas, 'courier new', monospace, sans-serif"></span><br></div>
<div><span class="font" style="font-family:menlo, consolas, 'courier new', monospace, sans-serif"><b>import </b>Mod <b>hiding</b> <b>(</b>x,y<b>)</b> // imports Mod and its members except for `x` or `y`</span><br></div>
<div><span class="font" style="font-family:menlo, consolas, 'courier new', monospace, sans-serif"><b>import qualified</b> Mod <b>hiding</b> <b>(</b>x,y<b>)</b> // imports e.g. `Mod.z` but not `Mod.x` or `Mod.y`</span><span class="font" style="font-family:menlo, consolas, 'courier new', monospace, sans-serif"><b></b></span><br></div>
<div><span class="font" style="font-family:menlo, consolas, 'courier new', monospace, sans-serif"><b>import</b> Mod <b>as</b> Foo // imports Mod and renames the module to Foo, so e.g. `x` and `Foo.x` are accessible</span><br></div>
<div><span class="font" style="font-family:menlo, consolas, 'courier new', monospace, sans-serif"><b>import</b> Mod <b>as</b> Foo <b>(</b>x,y<b>)</b> // renames Mod to Foo, provides `x`, `y`, `Foo.x`, and `Foo.y`</span><span class="font" style="font-family:menlo, consolas, 'courier new', monospace, sans-serif"></span><br></div>
<div><span class="font" style="font-family:menlo, consolas, 'courier new', monospace, sans-serif"><b>import qualified</b> Mod <b>as</b> Foo // renames Mod to Foo, all members are accessible via the module e.g. `Foo.x`</span><span class="font" style="font-family:menlo, consolas, 'courier new', monospace, sans-serif"></span><br></div>
<div><span class="font" style="font-family:menlo, consolas, 'courier new', monospace, sans-serif"><b>import qualified</b> Mod <b>as</b> Foo <b>(</b>x,y<b>)</b> // renames Mod to Foo, provides access to `Foo.x` and `Foo.y` but not e.g. `Foo.z`</span><span class="font" style="font-family:menlo, consolas, 'courier new', monospace, sans-serif"></span><br></div>
<div> </div>
<div>Furthermore, you can have multiple import statements from the same module, so you can say something like<br></div>
<div> </div>
<div><span class="font" style="font-family:menlo, consolas, 'courier new', monospace, sans-serif"><b>import qualified</b> Mod</span><br></div>
<div><span class="font" style="font-family:menlo, consolas, 'courier new', monospace, sans-serif"><b>import</b> Mod <b>(</b>x,y<b>)</b></span><br></div>
<div> </div>
<div>to provide access to all of Mod qualified with the name, and additionally import `x` and `y` as unqualified identifiers.<br></div>
<div> </div>
<div>-Kevin Ballard<br></div>
<div><img style="height:1px !important;width:1px !important;border-top-width:0px !important;border-right-width:0px !important;border-bottom-width:0px !important;border-left-width:0px !important;margin-top:0px !important;margin-bottom:0px !important;margin-right:0px !important;margin-left:0px !important;padding-top:0px !important;padding-bottom:0px !important;padding-right:0px !important;padding-left:0px !important;" border="0" height="1" width="1" alt="" src="https://www.fastmailusercontent.com/proxy/0aad25aa13c74a12b71e0b6b44fb34142e92fcb1572a1a208c356b1e73c91b32/8647470737a3f2f25723030323431303e23647e23756e64676279646e2e65647f27766f2f60756e6f35707e6d34713c685a493a6241617d68694d223646333931717259467637424155794a7c633531465c6530575d4b4f6b62463d6f42705a574443454d223641376d22364f64736979356672316567755e4e4b49394135353076767071434e41653e47327163345b6542494946516b4d2232495669723361745c4438367d22324979357158657a64505c46694a7862503741524533545a535c6f4a575b6479686c65343167554c483b4372586d2236436d485f6254697f65686361603f6e423d22324a4f62567a65784543507a53636d6148475f62413a6d66486532724454556554796d6a42495861697345496245716b6859664c44335b4966584467637d23344/open"><br></div>
</div>
<div>_______________________________________________<br></div>
<div>swift-evolution mailing list<br></div>
<div><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br></div>
<div>https://lists.swift.org/mailman/listinfo/swift-evolution<br></div>
</div>
</blockquote></div>
</blockquote><div> </div>
</body>
</html>