<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 12:08 PM, Tony Allevato <<a href="mailto:allevato@google.com" class="">allevato@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_quote"><div dir="ltr" class="">On Fri, May 20, 2016 at 9:37 AM Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class=""><blockquote type="cite" class=""><div class="">On May 20, 2016, at 11:15 AM, Tony Allevato <<a href="mailto:allevato@google.com" target="_blank" class="">allevato@google.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Fri, May 20, 2016 at 8:48 AM Matthew Johnson <<a href="mailto:matthew@anandabits.com" target="_blank" class="">matthew@anandabits.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class=""><blockquote type="cite" class=""><div class="">On May 20, 2016, at 10:27 AM, Tony Allevato via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class=""><div class="">Another use case to consider: code generation. There, namespaces can be vital; they let you isolate code that you may have no real control over (for example, data models that correspond to remote services) from the rest of your code to avoid collisions. In some cases that can be achieved by putting the shared code in its own module, but if that data description format has hierarchical namespaces/packages of its own (Google's protocol buffers, for example), then the lack of namespaces forces the code generator to come up with contrived schemes for naming nested entities (like the Objective-C implementation, which uses underscore_delimited_names). The result is that Swift code using those services would look *very* unnatural.</div></div></div></blockquote><div class=""><br class=""></div></div></div><div style="word-wrap: break-word;" class=""><div class=""><div class="">What benefits do namespaces provide that empty enums and / or submodules do not? This isn’t clear to me and I think it is an essential part of the case that must be made.<span style="line-height: 1.5;" class=""> </span></div></div></div></blockquote><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class=""><div class=""><br class=""></div><div class="">Nobody is arguing that we don’t need a way to isolate names. The question is whether namespaces are the right mechanism for doing that or not.</div></div></div></blockquote><div class=""><br class=""></div><div class="">I'm certainly flexible on the way that organization manifests itself. In a general sense, u<span style="line-height: 1.5;" class="">sing structs-with-private-initializers or enums seems like abuse of those constructs. Generic types also can't be nested yet (but this is well-known and on the list of things to fix).</span></div></div></div></div></blockquote><div class=""><br class=""></div></div></div><div style="word-wrap: break-word;" class=""><div class=""><div class="">Yes, it’s definitely an abuse, but one with a reasonable degree of utility. I bring it up primarily to drive the discussion of what people want namespaces to do that this does not do today. I don’t actually think they are a sufficient solution. :-)</div></div></div><div style="word-wrap: break-word;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><div class="gmail_quote"><div class=""><br class=""></div><div class="">Some other concerns from my own experience in the domain of code generation:</div><div class=""><br class=""></div><div class="">I need to be able to define namespaces/organization in the source code, not as an artifact of the build system, which may prevent submodules from working as intended. Unless we want to be so prescriptive as to say, this is the One True Way that you will build your Swift code and nothing else matters, in which case I could probably generate a companion Swift package manifest.</div></div></div></div></blockquote><div class=""><br class=""></div></div></div><div style="word-wrap: break-word;" class=""><div class=""><div class="">I would expect submodules to be able to do this. The compilation target is the module. Submodules are defined in source<span class="Apple-converted-space"> </span><i class="">within</i> the module, but otherwise provide the same benefits of encapsulation that modules do. For example, `internal` visibility would be restricted to the submodule (which raises the question of whether we would want the ability to distinguish “submodule only” vs “whole module” visibility).</div><div class=""><br class=""></div><div class="">Namespaces and submodules are similar enough that we probably shouldn’t have both. There are a couple of primary differences between them IMO. The big one is that namespaces only deal with encapsulating names, whereas modules and submodules deal with encapsulation more generally. </div><div class=""><br class=""></div><div class="">The other is that depending on the design of namespaces, it might be possible to introduce names into the same namespace from *different* modules. That is a questionable capability in my mind and I would prefer to have the more generalized encapsulation of submodules.</div></div></div><div style="word-wrap: break-word;" class=""><div class=""><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><div class="gmail_quote"><div class=""><br class=""></div><div class="">Would submodules support circular references between them? If module Foo.Bar has a type that references something in Foo.Baz, and Foo.Baz has a type that references something in Foo.Bar, will that import work (they don't even have to be circular references between two *types*, just different types within two *modules*)? If it's like regular top-level modules now, that's not possible, because A can't import B if B imports A.</div></div></div></div></blockquote><div class=""><br class=""></div></div></div><div style="word-wrap: break-word;" class=""><div class=""><div class="">This is a good question. This is kind of thing I was looking for. I would hope this is possible since they are compiled together.</div></div></div><div style="word-wrap: break-word;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><div class="gmail_quote"><div class=""><br class=""></div><div class="">Structs/enums as faux namespaces also fall apart if you try to link multiple build artifacts into the same library or executable. Let's say I'm using a code generator to generate types from a data model that defines a namespace Foo. Let's go on to say that, due to the way the dependencies of my project are structured, the code for type Foo.Bar is generated separately from Foo.Baz. <span style="line-height: 1.5;" class="">Each run of the code generator needs to be independent, so in order to do that, it defines an empty Foo struct and extend it with the types inside that namespace that are generated in that run.</span><span style="line-height: 1.5;" class=""> So, in one run I have this:</span></div><div class=""><br class=""></div><div class="">generated1/Foo.swift:</div><div class="">public struct Foo { private init() {} }</div><div class=""><br class=""></div><div class=""><span style="line-height: 1.5;" class="">generated1</span><span style="line-height: 1.5;" class="">/</span>Foo.Bar.swift:</div><div class="">extension Foo {</div><div class=""> <span class="Apple-converted-space"> </span>struct Bar { ... }</div><div class="">}</div><div class=""><br class=""></div><div class="">and in another run, I have this:</div><div class=""><div class=""><br class=""></div><div class=""><span style="line-height: 1.5;" class="">generated2</span><span style="line-height: 1.5;" class="">/</span>Foo.swift:</div><div class="">public struct Foo { private init() {} }</div><div class=""><br class=""></div><div class=""><span style="line-height: 1.5;" class="">generated2</span><span style="line-height: 1.5;" class="">/</span>Foo.Baz.swift:</div><div class="">extension Foo {</div><div class=""> <span class="Apple-converted-space"> </span>struct Baz { ... }</div><div class="">}</div><br class=""></div><div class="">I have two copies of the Foo struct, so I can't easily compile these sources into object files and then pull them all together to link. Even though Foo doesn't contain anything other than nested types, the compiler outputs metadata symbols for Foo itself that causes duplicate link errors.</div></div></div></div></blockquote><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><div class="gmail_quote"><div class=""><br class=""></div><div class="">Swift as it is today already gets me *almost* the whole way there—merging the .swiftmodules produced from the builds above works fine and results in a module that defines both Bar and Baz inside Foo. Essentially, my use case would be solved if I could somehow say "Foo is not actually a type, it's used for organization and name mangling only, so please don't include any symbols for it alone in the output binary". Then everything would link correctly.</div></div></div></div></blockquote><div class=""><br class=""></div></div></div><div style="word-wrap: break-word;" class=""><div class=""><div class="">If you absolutely need the two runs to be totally independent I can see why it is frustrating to be so close. What is the reason that you can’t have them share the struct “namespace” declarations in a third folder? It’s not a good long-term solution but might help you move forward with what we have available today.</div></div></div></blockquote><div class=""><br class=""></div><div class="">In my situation, the build system puts artifacts in a derived path based on its source path in the workspace; using additional rules to move them into different locations or merge them is nontrivial, and inconvenient for the end user who wants to build two different dependencies and have them "just work" (especially since they could be dependencies of dependencies that they pull in without their knowledge).</div></div></div></div></blockquote><div><br class=""></div><div>I’m confused by “build two different dependences”. Are they building two totally separate target modules? This can’t be the case can it? If so, the structs would be independent because they would be in separate modules, even thought they have the same name. `Generated1.Foo` would not be the same as `Generated2.Foo`.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_quote"><div class=""><br class=""></div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class=""><div class=""><br class=""></div><div class="">namespaces/Foo.swift:</div></div></div><div style="word-wrap: break-word;" class=""><div class=""><div class=""><br class="">public struct Foo { private init() {} }</div></div></div><div style="word-wrap: break-word;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div dir="ltr" class="">On Fri, May 20, 2016 at 8:08 AM T.J. Usiyan via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="ltr" class="">+1 for namespaces. </div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, May 20, 2016 at 10:52 AM, Haravikk via swift-evolution<span class=""> </span><span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span><span class=""> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><span class=""><br class="">> On 20 May 2016, at 14:51, Krystof Vasa via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class="">><br class="">> When you have namespaces Car and Animal and each contains a class called List, IMHO there should be classes CarList and AnimalList. It's more verbose, but you imediately know which class is being used in opposite of just using List.<br class=""><br class=""></span>Why not use Car.List and Animal.List when its unclear from context? With Swift’s type inference you don’t often need to specify types anyway so your editor will know which list type you’re using based on how you obtained it.<br class=""><br class="">That said it does depend on the purpose of each List; do they have any commonality? They could for example both be generic List implementations, but were never factored out into a common module. If however they are specialised constructs specific to cars or animals, then the prefix may make most sense.<br class=""><br class="">For example, in the libdispatch thread the naming of Dispatch.DispatchQueue was queried, however this isn’t a general purpose queue type, it’s more specialised than that, so a name of “Queue” doesn’t convoy enough information, just as List might not. But it depends on what it actually does, which a basic example tends not to include ;)<br class=""><br class=""><br class="">Anyway, I’m +1 for namespaces everywhere, some names can be common. For example Node could be related to trees, physics engines and all sorts of constructs. “Node” may be a perfectly fine name for these. That said, these are sometimes tied to specific types in which case nesting them may make more sense, which I believe is already being addressed (currently we can’t nest generic types)? It’s certainly not as simple as it can appear!<br class=""><div class=""><div class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></blockquote></div></div></div></blockquote></div></div></blockquote></div></div></div></blockquote></div></div><div style="word-wrap: break-word;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class=""><blockquote type="cite" class=""><div class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div></div></blockquote></div></div></div></blockquote></div></div></blockquote></div></div></div></blockquote></div><br class=""></body></html>