If your package is big enough that it benefits from having a single class
that serves as the entry point to it, it would also make sense to call it
the same thing as your package.
I don't really like preventing modules from having a class with the same
name, precisely because I think that it's an intuitive thing to do.
I could go with Module::Class too, given that : is not an operator
Paulo, given that I'm not sure about the direction that you're taking,
it's a little hard to come up with a good name. "Disambiguating namespaces"
or "namespace selection" or something like that could be a good start,
Le 20 juin 2016 à 17:33:03, Paulo Faria <firstname.lastname@example.org> 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
On Jun 20, 2016, at 9:25 PM, Jordan Rose <email@example.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.
On Jun 17, 2016, at 19:52, Félix Cloutier via swift-evolution < >> firstname.lastname@example.org> wrote:
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
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
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`)
swift-evolution mailing list
swift-evolution mailing list