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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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