<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">For what it’s worth, I renamed OrderedSet to SortedSet in the Swift 3 version of BTree, so the original instance of this issue is hopefully no more.</div><div class=""><br class=""></div><div class="">Prohibiting modules from containing a symbol of the same name would require a mass renaming of many microframeworks. Besides BTree, I also have BigInt, Deque and RedBlackTree; I know Rob Rix has Result, Box, Either, Memo, Delay, Stream, BinaryTree, etc.; and there are oodles more. Renaming them is certainly doable, but it definitely would be a pain in the neck for everyone involved. I’m not even sure what naming convention we should use: most of these packages essentially consist of the type that they’re named after, and naming them like this was the most obvious option. (These names work well at the point of use, too: you want to use Result, so you need to import Result). Requiring/allowing reverse DNS-style module names (e.g. com.apple.Foundation) would be one way to solve the naming issue, but this seems hard to incorporate into the language at this point.)</div><div class=""><br class=""></div><div class=""><div class="">I’d much prefer having “import Foo as Bar” as a (hopefully) easy-to-implement stop-gap solution than to give up on these nice microframework names. This would not break existing code.</div><div class=""><br class=""></div></div><div class="">I like the idea to allow absolute naming to resolve ambiguous names, but using _ for the root symbol seems very different to its usual meaning. Perhaps it's worth spending the # character on this: #.BTree.OrderedSet<Int>. Or how about "<>.BTree.OrderedSet<Int>”? None of these would be intuitively clear to read, though (and they need special magic to make sure a “<root>.BTree.” prefix is resolved to mean the module, not the struct.). If nested modules are in the cards for a future Swift, not having a delimiter at the end of the module path could become an issue.</div><div class=""><br class=""></div><div class="">What if we allowed type expressions like “(OrderedSet<Int> in BTree)” or “(OrderedSet<Foo> from Foundation)”? The swapped order sure is strange though, and I have no idea if such a construct would fit in the grammar. But at least the meaning of it is reasonably clear, and the same scheme could also support the extension method case: e.g., "foo.(bar in MyModule)()”.</div><div class=""><br class=""></div><div class=""><div class="">C# has a somewhat similar issue with its namespaces: <a href="https://blogs.msdn.microsoft.com/ericlippert/2010/03/09/do-not-name-a-class-the-same-as-its-namespace-part-one/" class="">https://blogs.msdn.microsoft.com/ericlippert/2010/03/09/do-not-name-a-class-the-same-as-its-namespace-part-one/</a>. They have "global::” to refer to their root namespace, and they discourage (but not prohibit) naming a class the same as its enclosing namespace. I think Java's concept of obscured names is also relevant, but I’ll leave it to someone else to decipher the specification. :-)</div></div><div class=""><br class=""></div><div class="">-- </div><div class="">Karoly</div><div class="">@lorentey</div><div class=""><br class=""></div><div class=""><div class=""><div class=""><div><blockquote type="cite" class=""><div class="">On 2016-07-17, at 01:07, Félix Cloutier via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">There is a lot of potential for it to be a breaking change. Currently, you can do module qualification with Module.Symbol. This causes problems. The two most obvious solutions (change the "operator" between Module and Symbol, or prevent symbols from having the same name as their module) are breaking changes.<br class=""><div class="">
<br class="Apple-interchange-newline"><span style="font-family: 'Lucida Grande'; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Félix</span>
</div>
<br class=""><div class=""><blockquote type="cite" class=""><div class="">Le 16 juil. 2016 à 16:01:28, David Hart <<a href="mailto:david@hartbit.com" class="">david@hartbit.com</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class="">I don't see anything source breaking here. I'm fairly sure it's 100% additive and will therefore wait for after Swift 3.</div><div class=""><br class="">On 17 Jul 2016, at 00:19, Félix Cloutier via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class="">There is about 2 weeks left for source-breaking proposals, and this is going to be one of them. How is progress going? Do you think that you'll have enough time to push it out of the door?<br class=""><div class="">
<br class="Apple-interchange-newline"><span style="font-family: 'Lucida Grande'; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Félix</span>
</div>
<br class=""><div class=""><blockquote type="cite" class=""><div class="">Le 20 juin 2016 à 17:33:03, Paulo Faria <<a href="mailto:paulo@zewo.io" class="">paulo@zewo.io</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Yeah! I’m working on a formal proposal that would solve the same problem. Jordan, the problem he described is exactly like the one you explained to me, haha. Now I’m a bit confused about how the proposal should be called. Have any suggestions? What title could fit the two use cases we mentioned. By the way, can you see any other use case that would be solved with the same solution?<div class=""><br class=""></div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 20, 2016, at 9:25 PM, Jordan Rose <<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I've been encouraging Paulo Faria to mention this case in his push for a way to disambiguate extension methods, with the thought being we could then use the same syntax to differentiate top-level names as well.</div><div class=""><br class=""></div><div class="">I'd also be happy with the "import as" syntax. The underscore syntax seems a little opaque, but I suppose it wouldn't come up very often.</div><div class=""><br class=""></div><div class="">Jordan</div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 17, 2016, at 19:52, Félix Cloutier via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hello all,<div class=""><br class=""></div><span class="">I recently </span><a href="http://stackoverflow.com/q/37892621/251153" class="">ran into a bug</a><span class=""> that leaves me unable to fully-qualify the name of a type. If you import a module named Foo that also contains a type named Foo, attempts to fully-qualify any name in the Foo module will instead attempt to find something inside the Foo type. This bug has </span><a href="https://bugs.swift.org/browse/SR-898" class="">already been reported</a><span class="">.<br class=""></span><div class=""><br class=""></div><div class="">Here's an example with Károly Lőrentey's BTree module (which also contains a BTree type) that I encountered while trying to use the OrderedSet type:</div><div class=""><br class=""></div><div class=""><pre class="default prettyprinted prettyprint" style="margin-top: 0px; padding: 5px; border: 0px; font-size: 13px; width: auto; max-height: 600px; overflow: auto; font-family: Consolas, Menlo, Monaco, 'Lucida Console', 'Liberation Mono', 'DejaVu Sans Mono', 'Bitstream Vera Sans Mono', 'Courier New', monospace, sans-serif; background-color: rgb(239, 240, 241); color: rgb(57, 51, 24); word-wrap: normal;"><code style="margin: 0px; padding: 0px; border: 0px; font-family: Consolas, Menlo, Monaco, 'Lucida Console', 'Liberation Mono', 'DejaVu Sans Mono', 'Bitstream Vera Sans Mono', 'Courier New', monospace, sans-serif; white-space: inherit;" class=""><span class="kwd" style="margin: 0px; padding: 0px; border: 0px; color: rgb(16, 16, 148);">let</span><span class="pln" style="margin: 0px; padding: 0px; border: 0px; color: rgb(48, 51, 54);"> </span><span class="kwd" style="margin: 0px; padding: 0px; border: 0px; color: rgb(16, 16, 148);">set</span><span class="pln" style="margin: 0px; padding: 0px; border: 0px; color: rgb(48, 51, 54);"> </span><span class="pun" style="margin: 0px; padding: 0px; border: 0px; color: rgb(48, 51, 54);">=</span><span class="pln" style="margin: 0px; padding: 0px; border: 0px; color: rgb(48, 51, 54);"> </span><span class="typ" style="margin: 0px; padding: 0px; border: 0px; color: rgb(43, 145, 175);">OrderedSet</span><span class="pun" style="margin: 0px; padding: 0px; border: 0px; color: rgb(48, 51, 54);"><</span><span class="typ" style="margin: 0px; padding: 0px; border: 0px; color: rgb(43, 145, 175);">Int</span><span class="pun" style="margin: 0px; padding: 0px; border: 0px; color: rgb(48, 51, 54);">>()</span><span class="pln" style="margin: 0px; padding: 0px; border: 0px; color: rgb(48, 51, 54);">
</span><span class="com" style="margin: 0px; padding: 0px; border: 0px; color: rgb(133, 140, 147);">// error: 'OrderedSet' is ambiguous for type lookup in this context</span><span class="pln" style="margin: 0px; padding: 0px; border: 0px; color: rgb(48, 51, 54);">
</span><span class="com" style="margin: 0px; padding: 0px; border: 0px; color: rgb(133, 140, 147);">// Found this candidate: Foundation.OrderedSet:3:14</span><span class="pln" style="margin: 0px; padding: 0px; border: 0px; color: rgb(48, 51, 54);">
</span><span class="com" style="margin: 0px; padding: 0px; border: 0px; color: rgb(133, 140, 147);">// Found this candidate: BTree.OrderedSet:12:15</span></code></pre><div class="">To solve this, you would normally write BTree.OrderedSet, but now Swift thinks that BTree is the BTree type, not the BTree module:</div><div class=""><br class=""></div><div class=""><pre class="default prettyprinted prettyprint" style="margin-top: 0px; padding: 5px; border: 0px; font-size: 13px; width: auto; max-height: 600px; overflow: auto; font-family: Consolas, Menlo, Monaco, 'Lucida Console', 'Liberation Mono', 'DejaVu Sans Mono', 'Bitstream Vera Sans Mono', 'Courier New', monospace, sans-serif; background-color: rgb(239, 240, 241); color: rgb(57, 51, 24); word-wrap: normal;"><code style="margin: 0px; padding: 0px; border: 0px; font-family: Consolas, Menlo, Monaco, 'Lucida Console', 'Liberation Mono', 'DejaVu Sans Mono', 'Bitstream Vera Sans Mono', 'Courier New', monospace, sans-serif; white-space: inherit;" class=""><span class="kwd" style="margin: 0px; padding: 0px; border: 0px; color: rgb(16, 16, 148);">let</span><span class="pln" style="margin: 0px; padding: 0px; border: 0px; color: rgb(48, 51, 54);"> </span><span class="kwd" style="margin: 0px; padding: 0px; border: 0px; color: rgb(16, 16, 148);">set</span><span class="pln" style="margin: 0px; padding: 0px; border: 0px; color: rgb(48, 51, 54);"> </span><span class="pun" style="margin: 0px; padding: 0px; border: 0px; color: rgb(48, 51, 54);">=</span><span class="pln" style="margin: 0px; padding: 0px; border: 0px; color: rgb(48, 51, 54);"> </span><span class="typ" style="margin: 0px; padding: 0px; border: 0px; color: rgb(43, 145, 175);">BTree</span><span class="pun" style="margin: 0px; padding: 0px; border: 0px; color: rgb(48, 51, 54);">.</span><span class="typ" style="margin: 0px; padding: 0px; border: 0px; color: rgb(43, 145, 175);">OrderedSet</span><span class="pun" style="margin: 0px; padding: 0px; border: 0px; color: rgb(48, 51, 54);"><</span><span class="typ" style="margin: 0px; padding: 0px; border: 0px; color: rgb(43, 145, 175);">Int</span><span class="pun" style="margin: 0px; padding: 0px; border: 0px; color: rgb(48, 51, 54);">>()</span><span class="pln" style="margin: 0px; padding: 0px; border: 0px; color: rgb(48, 51, 54);">
</span><span class="com" style="margin: 0px; padding: 0px; border: 0px; color: rgb(133, 140, 147);">// error: reference to generic type 'BTree' requires arguments in <...></span></code></pre><div class="">Any fix will require a change to the language, and as Jordan Rose stated on the bug, it "needs design", so I would like to bring up the issue and discuss possible solutions.</div></div><div class=""><br class=""></div><div class="">I can see several options (leaving "do nothing" aside, since I believe that this needs to be resolved):</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">Prevent modules from containing a type with the same name</li><li class="">Allow modules to be imported under different names (`import BTree as BTreeModule`, `import BTreeModule = BTree` or any similar syntax)</li><li class="">Create a new syntax that indicates that you're naming a module, not a type (like `_.BTree.OrderedSet`)</li></ul><div class=""><br class=""></div></div><div class="">Thoughts?</div><div class="">
<br class="Apple-interchange-newline"><span style="font-family: 'Lucida Grande'; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Félix</span>
</div>
<br class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></div></div></body></html>