<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 20, 2016, at 2:48 PM, Leonardo Pessoa <<a href="mailto:me@lmpessoa.com" class="">me@lmpessoa.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">We've been discussing some thing like this on another thread about<br class="">protocols and this looks like a great solution to the problem<br class="">expressed there with a very simple change in syntax (and no new<br class="">keyword involved). I'd like to see this turned into a separate<br class="">proposal (since I'm new on the group and lack the experience, I'm not<br class="">the most suitable person to write).<br class=""><br class="">I agree with others that we can nowadays subvert the purpose of an<br class="">existing construct of the language to simulate a namespace and I<br class="">believe most people here agree that's not the best way to work but<br class="">that's what we have now. I think that's why we're here discussing the<br class="">idea of namespaces (or submodules, could someone disambiguate them,<br class="">please?).<br class=""></div></div></blockquote><div><br class=""></div><div>The big difference is one of encapsulation.</div><div><br class=""></div><div>Namespaces encapsulate names to avoid naming conflicts. It is common for them to be open to extension across modules, similar to how types in Swift are open to extension across module boundaries. Empty enums approximate this aspect of namespaces very well. One thing they do not (currently) support is the ability to import names from a namespace into a lexical scope so they may used directly, without the namespace prefix. Here’s a hypothetical example where that limitation is removed:</div><div><br class=""></div><div>enum Foo { // alternatively: namespace Foo</div><div> static func bar() -> String {}</div><div> struct S {}</div><div>}</div><div><br class=""></div><div>elsewhere:</div><div><br class=""></div><div>import Foo</div><div><br class=""></div><div>let s = S() // creates an instance of Foo.S which has been imported into the lexical context</div><div>let b = bar() // calls Foo.bar which has been imported into the lexical context</div><div><br class=""></div><div>I think it would be interesting to consider allowing the top-level / static names of a type to be imported into a lexical context whether we have namespaces or not.</div><div><br class=""></div><div>One minor difference between an empty enum and a namespace is that you can define instance methods for an empty enum even though you can’t actually instantiate an empty enum (one could argue that this should not be allowed).</div><div><br class=""></div><div>The duplicate definition issue Tony mentioned is probably the most significant difference between an empty enum and a namespace. Related to this is the need to use `extension Foo` syntax everywhere except the initial introduction of `enum Foo`. The ability to use `namespace Foo` everywhere and not worry about duplicate definition is the most important reason why empty enums do not suffice as a substitute for namespaces.</div><div><br class=""></div><div>Submodules are different in that they are first class modules in every respect, they just happen to be compiled as a part of their containing module. They provide more encapsulation, but because of that they *are not* open to extension in the way that namespaces can be (depending on the design of the namespace feature).</div><div><br class=""></div><div>The big question in my mind is whether we really need a namespace mechanism that is open to extension across module boundaries. There is a good reason types are open to extension across module boundaries: it allows you to retroactively conform them to protocols, introduce additional methods, etc. These reasons do not apply to namespaces. </div><div><br class=""></div><div>If there isn’t a compelling argument that we need such a mechanism submodules will prove to be a better solution. I believe this will be the right answer for Swift, but am certainly willing to listen to counter-arguments.</div><div><br class=""></div><div>If there <i class="">is</i> a compelling argument for open namespaces then the question becomes whether the benefit is sufficient to support them either *instead of* or *in addition to* submodules. </div><div><br class=""></div><div>-Matthew</div><div><br class=""></div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class=""><br class=""><br class="">On 20 May 2016 at 12:45, Matthew Johnson via swift-evolution<br class=""><<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><blockquote type="cite" class=""><br class="">On May 20, 2016, at 10:21 AM, Austin Zheng via swift-evolution<br class=""><<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">I think namespaces are definitely worth exploring.<br class=""><br class="">Here's something that might be interesting to research. Right now, you can<br class="">have two protocols that have associated types with the same name. If you<br class="">adopt both protocols, you have to make the associated types the same, even<br class="">if they really don't have anything to do with each other. I think this might<br class="">be a good argument for how namespaces can make your code more expressive:<br class=""><br class="">protocol A {<br class=""> associatedtype Thing<br class=""> func foo(x: Thing)<br class="">}<br class=""><br class="">protocol B {<br class=""> associatedtype Thing<br class=""> func bar(x: Thing)<br class="">}<br class=""><br class="">struct Foo : A, B {<br class=""> func foo(x: Int) { }<br class=""> // Error: type 'Foo' does not conform to protocol 'B'<br class=""> // protocol requires function 'bar' with type 'Thing'<br class=""> func bar(x: String) { }<br class="">}<br class=""><br class="">In this example, I want to use "Int" for A's Thing type, and "String" for<br class="">B's Thing type, but I can’t.<br class=""><br class=""><br class="">This is totally orthogonal to namespaces. C# provides a mechanism to<br class="">clarify implementation of multiple interfaces with the same requirements and<br class="">it has nothing to do with C# namespaces. For example, it might be possible<br class="">to just prefix member declarations with the name of the protocol. These<br class="">implementations would not be visible via the primary type interface.<br class=""><br class="">struct Foo : A, B {<br class=""> typealias A.Thing = Int<br class=""> typealias B.Thing = Bar<br class=""> func foo(x: Int) { }<br class=""> func bar(x: String) { }<br class="">}<br class=""><br class="">We could also allow you to omit the protocol-specific declaration for one of<br class="">the conflicting protocols if you wanted that to be visible through the<br class="">interface of your concrete type.<br class=""><br class="">struct Foo : A, B {<br class=""> typealias A.Thing = Int<br class=""> func foo(x: Int) { }<br class=""> func bar(x: String) { }<br class="">}<br class=""><br class="">The same mechanism could work for any members (properties, methods, etc).<br class="">In this case, `foo` is scoped specifically to the implementation of `A` even<br class="">though it is not resolving any ambiguity. It is not visible via the<br class="">interface of the concrete type `Foo`.<br class=""><br class="">struct Foo : A, B {<br class=""> typealias A.Thing = Int<br class=""> func A.foo(x: Int) { }<br class=""> func bar(x: String) { }<br class="">}<br class=""><br class=""><br class="">Best,<br class="">Austin<br class=""><br class=""><br class="">On May 20, 2016, at 5:16 AM, Adrian Zubarev via swift-evolution<br class=""><<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">I want to revive this topic.<br class=""><br class="">Is there any technical reason why we can’t have namespaces in Swift? I’ve<br class="">found just a few threads about namespaces, but most of them had arguments to<br class="">use modules instead.<br class=""><br class="">I’m fine with modules but they just don’t serve everything I would want to.<br class="">I can’t enforce the developer to use the modules name if there is no naming<br class="">conflict.<br class=""><br class="">I asked in the SwiftPM mail list for a easier Xcode integration of modules,<br class="">but the response is exactly the opposite for using modules for namespaces<br class="">(read below).<br class=""><br class="">If I’m building one huge project I don’t want to build a lot of different<br class="">modules just shiny namespaces and clean code.<br class=""><br class="">So I ask the community again why can’t we have optional namespaces?<br class="">--<br class="">Adrian Zubarev<br class="">Sent with Airmail<br class=""><br class="">Am 19. Mai 2016 bei 22:33:19, Daniel Dunbar (<a href="mailto:daniel_dunbar@apple.com" class="">daniel_dunbar@apple.com</a>)<br class="">schrieb:<br class=""><br class="">Right now modules are most appropriately used at the same granularity that<br class="">frameworks or shared libraries would be used in C/Obj-C/C++. This is the<br class="">situation for which the variety of access control modifiers in Swift and<br class="">things like Whole Module Optimization were designed for. While there are a<br class="">lot of reasons to like modules as a way to provide namespaces, they really<br class="">haven't been designed to provide these very fine grained namespaces.<br class=""><br class="">My guess is that the right answer here doesn't really involve the Xcode<br class="">integration, but rather figuring out the right way that these concepts fit<br class="">into the language in a first class way. I would expect concepts like<br class="">submodules or namespaces to be language concepts that Xcode just exposes,<br class="">not something that was coupled together.<br class=""><br class=""> - Daniel<br class=""><br class="">On May 18, 2016, at 12:37 PM, Adrian Zubarev via swift-build-dev<br class=""><<a href="mailto:swift-build-dev@swift.org" class="">swift-build-dev@swift.org</a>> wrote:<br class=""><br class="">I’d like to discuss an idea that will make development in Xcode easier. I<br class="">assume that SwiftPM will see its Xcode integration when the final version<br class="">will be released.<br class=""><br class="">Problem I’ll try to describe is mostly about namespaces. Right now some<br class="">people abuses enums, struct or classes to create a namespace for a specific<br class="">need.<br class=""><br class="">class Reference {<br class=""> class String { … }<br class=""> class Character {<br class=""> enum Error { … }<br class=""> }<br class=""><br class=""> private init() {}<br class="">}<br class=""><br class="">This will create a pseudo namespace for the nested types:<br class=""><br class="">* Reference.String<br class="">* Reference.Character<br class="">* Reference.Character.Error<br class=""><br class="">One could argue of using modules instead of abusing a class here, which is a<br class="">great argument.<br class=""><br class="">The problem that comes to my mind here is that we will have to create<br class="">subprojects inside our main project file and using the references to them<br class="">just to achieve that shiny namespace.<br class="">One could also use SwiftPM, which is awesome, but there is a need to<br class="">re-build the module if any changes have been done. As soon as we’ll create<br class="">some complex dependencies between different modules this will get messy.<br class=""><br class="">Before posting here I asked Joe Groff if there is any mailing list I can use<br class="">to discuss my idea. He told me this might be a good place, because I was<br class="">referring to the package manager. Then I’ve done my research to not create<br class="">any redundant thread, but I only found one topic about the integration of<br class="">SwiftPM in Xcode:<br class=""><a href="https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160215/000272.html" class="">https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160215/000272.html</a><br class=""><br class="">So here are my thoughts about a deeper integration of SwiftPM here:<br class=""><br class="">- What if Xcode will introduce two new types of groups (the folder color<br class="">could be orange like Swift for example, or even contain the bird icon).<br class="">- These groups are analogous to already existing group types except they’ll<br class="">represent Swift modules / packages<br class="">- Basically we’ll have a single project file with multiple modules, where<br class="">these modules should only exist inside that project (this is my own need<br class="">right now)<br class="">- Such a package / module group will have a configurable utilities, where<br class="">one could configure the modules<br class="">- This will reduce the re-building process, allow us to keep everything (not<br class="">only .a or we’ll be able to hide .a files and just keep the sourcefiles<br class="">inside such groups) inside a single project, gain the shiny namespaces like<br class="">above, and make the file management way easier<br class="">- This also should allow us create cross-dependencies if there is a good<br class="">need for that in our project<br class=""><br class="">+ MainProject<br class="">|<br class="">+—Reference (module)<br class="">|<br class="">+—+— Magic (module)<br class=""> |<br class=""> +— SomeSubMagic (module)<br class=""><br class="">We could easily create cross dependencies between modules here by just using<br class="">the modules names and the types they provide.<br class=""><br class="">// SomeSubMagic is a sub module of Magic<br class="">class SomeSubMagic {<br class=""> var magic: Magic // referring to its parent module<br class="">}<br class=""><br class="">What do you think about this?<br class=""><br class="">--<br class="">Adrian Zubarev<br class="">Sent with Airmail<br class="">_______________________________________________<br class="">swift-build-dev mailing list<br class="">swift-build-dev@swift.org<br class="">https://lists.swift.org/mailman/listinfo/swift-build-dev<br class=""><br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class="">swift-evolution@swift.org<br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""><br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class="">swift-evolution@swift.org<br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""><br class=""><br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class="">swift-evolution@swift.org<br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""><br class=""></blockquote></div></div></blockquote></div><br class=""></body></html>