<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 &lt;<a href="mailto:me@lmpessoa.com" class="">me@lmpessoa.com</a>&gt; 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. &nbsp;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. &nbsp;Empty enums approximate this aspect of namespaces very well. &nbsp;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. &nbsp;Here’s a hypothetical &nbsp;example where that limitation is removed:</div><div><br class=""></div><div>enum Foo { // alternatively: namespace Foo</div><div>&nbsp; &nbsp; static func bar() -&gt; String {}</div><div>&nbsp; &nbsp; 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. &nbsp;Related to this is the need to use `extension Foo` syntax everywhere except the initial introduction of `enum Foo`. &nbsp;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. &nbsp;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. &nbsp;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. &nbsp;These reasons do not apply to namespaces. &nbsp;</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. &nbsp;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>&nbsp;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. &nbsp;</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="">&lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:<br class=""><blockquote type="cite" class=""><br class="">On May 20, 2016, at 10:21 AM, Austin Zheng via swift-evolution<br class="">&lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; 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=""> &nbsp;associatedtype Thing<br class=""> &nbsp;func foo(x: Thing)<br class="">}<br class=""><br class="">protocol B {<br class=""> &nbsp;associatedtype Thing<br class=""> &nbsp;func bar(x: Thing)<br class="">}<br class=""><br class="">struct Foo : A, B {<br class=""> &nbsp;func foo(x: Int) { }<br class=""> &nbsp;// Error: type 'Foo' does not conform to protocol 'B'<br class=""> &nbsp;// protocol requires function 'bar' with type 'Thing'<br class=""> &nbsp;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. &nbsp;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. &nbsp;For example, it might be possible<br class="">to just prefix member declarations with the name of the protocol. &nbsp;These<br class="">implementations would not be visible via the primary type interface.<br class=""><br class="">struct Foo : A, B {<br class=""> &nbsp;typealias A.Thing = Int<br class=""> &nbsp;typealias B.Thing = Bar<br class=""> &nbsp;func foo(x: Int) { }<br class=""> &nbsp;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=""> &nbsp;typealias A.Thing = Int<br class=""> &nbsp;func foo(x: Int) { }<br class=""> &nbsp;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. &nbsp;It is not visible via the<br class="">interface of the concrete type `Foo`.<br class=""><br class="">struct Foo : A, B {<br class=""> &nbsp;typealias A.Thing = Int<br class=""> &nbsp;func A.foo(x: Int) { }<br class=""> &nbsp;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="">&lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; 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="">&lt;<a href="mailto:swift-build-dev@swift.org" class="">swift-build-dev@swift.org</a>&gt; 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=""> &nbsp;&nbsp;&nbsp;class String { … }<br class=""> &nbsp;&nbsp;&nbsp;class Character {<br class=""> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;enum Error { … }<br class=""> &nbsp;&nbsp;&nbsp;}<br class=""><br class=""> &nbsp;&nbsp;&nbsp;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=""> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<br class=""> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+— 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=""> &nbsp;&nbsp;&nbsp;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>