Fixing modules that contain a type with the same name

Felix_Cloutier1 · June 18, 2016, 2:52am

Hello all,

I recently ran into a bug <swift - How can I disambiguate a type and a module with the same name? - Stack Overflow; 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

Felix_Cloutier1 · June 20, 2016, 4:16pm

If no one has anything to say, I'll be starting a proposal to introduce the _.Module.Type syntax.

Félix

···

Le 17 juin 2016 à 19:52:45, Félix Cloutier via swift-evolution <swift-evolution@swift.org> a écrit :

Hello all,

I recently ran into a bug <swift - How can I disambiguate a type and a module with the same name? - Stack Overflow; 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
https://lists.swift.org/mailman/listinfo/swift-evolution

jrose · June 21, 2016, 12:25am

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 <swift - How can I disambiguate a type and a module with the same name? - Stack Overflow; 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
https://lists.swift.org/mailman/listinfo/swift-evolution

xwu · June 20, 2016, 4:45pm

I'm not sure that `_.` reads very well; it rather seems to denote that
there is no module name.

The most conservative change would be to prohibit module names that collide
with a contained (public) type. If, later, this is found to be unduly
restrictive, another syntax can be designed and added. I don't believe it
is a commonly seen design pattern, though, is it?

···

On Mon, Jun 20, 2016 at 11:16 Félix Cloutier <swift-evolution@swift.org> wrote:

If no one has anything to say, I'll be starting a proposal to introduce
the _.Module.Type syntax.

Félix

Le 17 juin 2016 à 19:52:45, Félix Cloutier via swift-evolution < > swift-evolution@swift.org> a écrit :

Hello all,

I recently ran into a bug <swift - How can I disambiguate a type and a module with the same name? - Stack Overflow; 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
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

VladimirS · June 20, 2016, 5:01pm

I'd like to suggest such alternative syntax to mention in your proposal:

Module::Type

···

On 20.06.2016 19:16, Félix Cloutier via swift-evolution wrote:

If no one has anything to say, I'll be starting a proposal to introduce the
_.Module.Type syntax.

Félix

Le 17 juin 2016 à 19:52:45, Félix Cloutier via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :

Hello all,

I recently ran into a bug
<swift - How can I disambiguate a type and a module with the same name? - Stack Overflow; 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:

>letset=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:

>letset=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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Paulo_Faria · June 21, 2016, 12:33am

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_rose@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 <swift - How can I disambiguate a type and a module with the same name? - Stack Overflow; 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

Felix_Cloutier1 · June 21, 2016, 2:08am

I'm trying to reply to everybody in this message.

I think that it's a rather common and intuitive thing to name a module after its most important class, especially for small-ish packages. What would you call a package that provides a BTree, or a BigInt, and not much else? I'd also make the case that ManagedObject wouldn't be an awful name for CoreData, or Animation for CoreAnimation. 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 character.

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, maybe?

Félix

···

Le 20 juin 2016 à 17:33:03, Paulo Faria <paulo@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_rose@apple.com <mailto:jordan_rose@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 <swift - How can I disambiguate a type and a module with the same name? - Stack Overflow; 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

Felix_Cloutier1 · June 21, 2016, 4:12am

I think that it takes some chutzpah to declare that your B-tree is authoritative enough that it should be called "BTreeCore". I also by far prefer BTree to MyBTree or BTreePackage; of course these are all possible workarounds for a name resolution *bug*, but they certainly don't sound great to me.

I'm also not suggesting that you can just do away with the "kit" or "core" in a module name: I'm saying that I find it intuitive to take the main class of a package and name your package after it. It's not like you can instantiate the Web from WebKit!

Either way, these <https://github.com/kirsteins/BigInteger> things <https://github.com/lorentey/BTree> happen and I don't see anything fundamentally wrong with it. I'd prefer a fix to a restriction.

Félix

···

Le 20 juin 2016 à 19:21:45, Xiaodi Wu <xiaodi.wu@gmail.com> a écrit :

On Mon, Jun 20, 2016 at 9:08 PM, Félix Cloutier <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I'm trying to reply to everybody in this message.

I think that it's a rather common and intuitive thing to name a module after its most important class, especially for small-ish packages. What would you call a package that provides a BTree, or a BigInt, and not much else?

BTreeCore, BTreeKit, BTreePackage, MyBTree, MyBTreeCore, MyBTreeKit, MyBTreePackage...

I'd also make the case that ManagedObject wouldn't be an awful name for CoreData, or Animation for CoreAnimation.

On the contrary, I think these show that some sort of prefix or suffix is greatly beneficial. IMO, Data would be an absurd package name. Note how it's WebKit, UIKit, SpriteKit and not Web, UI, Sprite.

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 character.

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, maybe?

Félix

Le 20 juin 2016 à 17:33:03, Paulo Faria <paulo@zewo.io <mailto:paulo@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_rose@apple.com <mailto:jordan_rose@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 <swift - How can I disambiguate a type and a module with the same name? - Stack Overflow; 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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

xwu · June 21, 2016, 2:21am

I'm trying to reply to everybody in this message.

I think that it's a rather common and intuitive thing to name a module
after its most important class, especially for small-ish packages. What
would you call a package that provides a BTree, or a BigInt, and not much
else?

BTreeCore, BTreeKit, BTreePackage, MyBTree, MyBTreeCore, MyBTreeKit,
MyBTreePackage...

I'd also make the case that ManagedObject wouldn't be an awful name for
CoreData, or Animation for CoreAnimation.

On the contrary, I think these show that some sort of prefix or suffix is
greatly beneficial. IMO, Data would be an absurd package name. Note how
it's WebKit, UIKit, SpriteKit and not Web, UI, Sprite.

···

On Mon, Jun 20, 2016 at 9:08 PM, Félix Cloutier <swift-evolution@swift.org> wrote:

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
character.

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,
maybe?

Félix

Le 20 juin 2016 à 17:33:03, Paulo Faria <paulo@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_rose@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 <swift - How can I disambiguate a type and a module with the same name? - Stack Overflow; 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
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

xwu · June 21, 2016, 4:37am

I think that it takes some chutzpah to declare that your B-tree is
authoritative enough that it should be called "BTreeCore".

I don't know why it sounds more authoritative than `BTree` itself. If you
and I both name a type `BTree` (very logical), then it's up to the module
name to distinguish them. But if we both think it's 'obvious' that our own
`BTree` type should be the one that's in the module named `BTree`, isn't
that a claim to authoritativeness?

I also by far prefer BTree to MyBTree or BTreePackage; of course these are

all possible workarounds for a name resolution *bug*, but they certainly
don't sound great to me.

I'm not entirely convinced that this definitely falls into the category of
a bug. I'd imagine there's a cogent argument why type names and module
names should be mutually distinct; it's too late in the evening for me to
come up with one at the moment.

···

On Mon, Jun 20, 2016 at 11:12 PM, Félix Cloutier <felixcca@yahoo.ca> wrote:

I'm also not suggesting that you can just do away with the "kit" or "core"
in a module name: I'm saying that I find it intuitive to take the main
class of a package and name your package after it. It's not like you can
instantiate the Web from WebKit!

Either way, these <https://github.com/kirsteins/BigInteger> things
<https://github.com/lorentey/BTree> happen and I don't see anything
fundamentally wrong with it. I'd prefer a fix to a restriction.

Félix

Le 20 juin 2016 à 19:21:45, Xiaodi Wu <xiaodi.wu@gmail.com> a écrit :

On Mon, Jun 20, 2016 at 9:08 PM, Félix Cloutier <swift-evolution@swift.org > > wrote:

I'm trying to reply to everybody in this message.

I think that it's a rather common and intuitive thing to name a module
after its most important class, especially for small-ish packages. What
would you call a package that provides a BTree, or a BigInt, and not much
else?

BTreeCore, BTreeKit, BTreePackage, MyBTree, MyBTreeCore, MyBTreeKit,
MyBTreePackage...

I'd also make the case that ManagedObject wouldn't be an awful name for
CoreData, or Animation for CoreAnimation.

On the contrary, I think these show that some sort of prefix or suffix is
greatly beneficial. IMO, Data would be an absurd package name. Note how
it's WebKit, UIKit, SpriteKit and not Web, UI, Sprite.

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
character.

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,
maybe?

Félix

Le 20 juin 2016 à 17:33:03, Paulo Faria <paulo@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_rose@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 <swift - How can I disambiguate a type and a module with the same name? - Stack Overflow; 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
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Felix_Cloutier1 · July 16, 2016, 10:19pm

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 <paulo@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_rose@apple.com <mailto:jordan_rose@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 <swift - How can I disambiguate a type and a module with the same name? - Stack Overflow; 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

codafi · July 17, 2016, 2:06am

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 <paulo@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_rose@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

hartbit · July 16, 2016, 11:01pm

I don't see anything source breaking here. I'm fairly sure it's 100% additive and will therefore wait for after Swift 3.

···

On 17 Jul 2016, at 00:19, Félix Cloutier via swift-evolution <swift-evolution@swift.org> wrote:

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 <paulo@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_rose@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

Felix_Cloutier1 · July 16, 2016, 11:07pm

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.

Félix

···

Le 16 juil. 2016 à 16:01:28, David Hart <david@hartbit.com> a écrit :

I don't see anything source breaking here. I'm fairly sure it's 100% additive and will therefore wait for after Swift 3.

On 17 Jul 2016, at 00:19, Félix Cloutier via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

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 <paulo@zewo.io <mailto:paulo@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_rose@apple.com <mailto:jordan_rose@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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

Felix_Cloutier1 · July 17, 2016, 4:06am

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.codafi@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 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 <paulo@zewo.io <mailto:paulo@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_rose@apple.com <mailto:jordan_rose@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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

lorentey · July 17, 2016, 1:49am

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.

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.)

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.

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.

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)()”.

C# has a somewhat similar issue with its namespaces: https://blogs.msdn.microsoft.com/ericlippert/2010/03/09/do-not-name-a-class-the-same-as-its-namespace-part-one/\. 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. :-)

···

--
Karoly
@lorentey

On 2016-07-17, at 01:07, Félix Cloutier via swift-evolution <swift-evolution@swift.org> wrote:

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.

Félix

Le 16 juil. 2016 à 16:01:28, David Hart <david@hartbit.com <mailto:david@hartbit.com>> a écrit :

I don't see anything source breaking here. I'm fairly sure it's 100% additive and will therefore wait for after Swift 3.

On 17 Jul 2016, at 00:19, Félix Cloutier via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

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 <paulo@zewo.io <mailto:paulo@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_rose@apple.com <mailto:jordan_rose@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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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

Max_Howell1 · July 21, 2019, 2:10pm

Sorry to resurrect this ancient thread but I felt it worth pointing out that XCTest has this problem (the module contains an XCTest class), so like, it's not just a matter of telling third parties to “name their modules better” we have to deal with this when using the SDK itself.

beccadax · July 21, 2019, 9:42pm

Believe me, some of us are well aware of the XCTest problem.

camsoft · November 14, 2022, 1:57pm

I just ran into this problem today 6 years after this topic was opened, please tell me this has been fixed and that there is a way to disambiguate the module name from a type define in the same module?

xwu · November 14, 2022, 3:02pm

There has been no improvement in this area that I’m aware of.