Re: [swift-evolution] Fixing modules that contain a type with the same name

[Félix Cloutier via swift-evolution]

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  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 
> > のメッセージ:
> 
>> 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 >> > 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 > 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 
> > 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()
> // 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()
> // 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 

Re: [swift-evolution] Fixing modules that contain a type with the same name

[Robert Widmann via swift-evolution]

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  
のメッセージ:

> 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  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  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 
  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()
 // 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()
 // 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

Re: [swift-evolution] Fixing modules that contain a type with the same name

[Károly Lőrentey via swift-evolution]

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. Or how about 
"<>.BTree.OrderedSet”? None of these would be intuitively clear to read, 
though (and they need special magic to make sure a “.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 in BTree)” or 
“(OrderedSet 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 
>  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 > > 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 
>> > 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 > 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  > 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 
>> 

Re: [swift-evolution] Fixing modules that contain a type with the same name

[Félix Cloutier via swift-evolution]

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  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 
> > 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 >> > 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 > 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 
> > 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()
> // 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()
> // 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

Re: [swift-evolution] Fixing modules that contain a type with the same name

[David Hart via swift-evolution]

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 
>  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  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  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 
  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()
 // 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()
 // 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

Re: [swift-evolution] Fixing modules that contain a type with the same name

[Félix Cloutier via swift-evolution]

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  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 > > 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 
>>> > 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()
>>> // 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()
>>> // 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

Re: [swift-evolution] Fixing modules that contain a type with the same name

[Xiaodi Wu via swift-evolution]

On Mon, Jun 20, 2016 at 11:12 PM, Félix Cloutier  wrote:

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


> 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  things
>  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  a écrit :
>
> On Mon, Jun 20, 2016 at 9:08 PM, Félix Cloutier  > 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  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  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()// 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 

Re: [swift-evolution] Fixing modules that contain a type with the same name

[Félix Cloutier via swift-evolution]

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  things 
 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  a écrit :
> 
> On Mon, Jun 20, 2016 at 9:08 PM, Félix Cloutier  > 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 > > 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 >> > 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 
 > 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()
 // 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()
 // 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 

Re: [swift-evolution] Fixing modules that contain a type with the same name

[Xiaodi Wu via swift-evolution]

On Mon, Jun 20, 2016 at 9:08 PM, Félix Cloutier 
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  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  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()// 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()// 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

Re: [swift-evolution] Fixing modules that contain a type with the same name

[Félix Cloutier via swift-evolution]

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  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 > > 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 
>>> > 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()
>>> // 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()
>>> // 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

Re: [swift-evolution] Fixing modules that contain a type with the same name

[Paulo Faria via swift-evolution]

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  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 
>> > 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()
>> // 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()
>> // 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

Re: [swift-evolution] Fixing modules that contain a type with the same name

[Jordan Rose via swift-evolution]

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 
>  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()
> // 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()
> // 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

Re: [swift-evolution] Fixing modules that contain a type with the same name

[Vladimir.S via swift-evolution]

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
> a écrit :

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:

|letset=OrderedSet()// 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()// 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

Re: [swift-evolution] Fixing modules that contain a type with the same name

[Xiaodi Wu via swift-evolution]

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 
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  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()// 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()// 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