To be clear, I think that you should be allowed to have a symbol that has the same name as the module. I was talking about that alternative because other people on this thread preferred it, but this does not reflect my opinion at all. As Károly writes, one very big reason to dislike it is that there is no possible automated migration for users of frameworks that rely on this pattern.
Renaming imports is one additive way to solve the problem. I was asking Paulo how his proposal is going, though, because my intuition is that it's headed towards something like `object.Module::extensionMethod()` to disambiguate extension methods, and we could reuse whatever syntax it has for global module symbols too. Since I suggested _.Module.Class, it was brought to my attention (on this thread) that : is not an operator symbol, so there is no risk of ambiguity in Module::Class (which I think is better than _.Module.Class). Félix > Le 16 juil. 2016 à 19:06:14, Robert Widmann <devteam.cod...@gmail.com> a > écrit : > > I've been wanting to do this kind of overhaul for the last 6 months. My > original spitball thread is here > http://permalink.gmane.org/gmane.comp.lang.swift.evolution/1394 > <http://permalink.gmane.org/gmane.comp.lang.swift.evolution/1394> and I have > a draft of a proposal that I hope to put out soon that I can let you view (or > even coauthor if you desire) if anybody wishes to ping me off-list. > > ~Robert Widmann > > 2016/07/16 15:19、Félix Cloutier via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> のメッセージ: > >> 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? >> >> Félix >> >>> Le 20 juin 2016 à 17:33:03, Paulo Faria <pa...@zewo.io >>> <mailto:pa...@zewo.io>> a écrit : >>> >>> 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? >>> >>> >>>> On Jun 20, 2016, at 9:25 PM, Jordan Rose <jordan_r...@apple.com >>>> <mailto:jordan_r...@apple.com>> wrote: >>>> >>>> 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. >>>> >>>> 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. >>>> >>>> Jordan >>>> >>>> >>>>> On Jun 17, 2016, at 19:52, Félix Cloutier via swift-evolution >>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>>> >>>>> Hello all, >>>>> >>>>> I recently ran into a bug <http://stackoverflow.com/q/37892621/251153> >>>>> 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 already been reported >>>>> <https://bugs.swift.org/browse/SR-898>. >>>>> >>>>> 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: >>>>> >>>>> let set = OrderedSet<Int>() >>>>> // error: 'OrderedSet' is ambiguous for type lookup in this context >>>>> // Found this candidate: Foundation.OrderedSet:3:14 >>>>> // Found this candidate: BTree.OrderedSet:12:15 >>>>> To solve this, you would normally write BTree.OrderedSet, but now Swift >>>>> thinks that BTree is the BTree type, not the BTree module: >>>>> >>>>> let set = BTree.OrderedSet<Int>() >>>>> // error: reference to generic type 'BTree' requires arguments in <...> >>>>> 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. >>>>> >>>>> I can see several options (leaving "do nothing" aside, since I believe >>>>> that this needs to be resolved): >>>>> >>>>> Prevent modules from containing a type with the same name >>>>> Allow modules to be imported under different names (`import BTree as >>>>> BTreeModule`, `import BTreeModule = BTree` or any similar syntax) >>>>> Create a new syntax that indicates that you're naming a module, not a >>>>> type (like `_.BTree.OrderedSet`) >>>>> >>>>> Thoughts? >>>>> >>>>> Félix >>>>> >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> >>> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
