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 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> のメッセージ: > 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> 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> 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> wrote: >>>> >>>> Hello all, >>>> >>>> I recently ran into a bug 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. >>>> >>>> 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 >>>> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
