[Pitch] Deeper Xcode Integration for SwiftPM

[anandabits (Matthew Johnson)]

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!

Absolutely +1 for namespaces.

Even if you despise the concept of namespaces that seems like that can be addressed by a project and/or company style guide that explicitly forbids their use.

For the people/projects that would embrace namespaces, namespaces would be a godsend.

Sure, you can probably pull all kind of stunts to simulate namespaces, but besides creating additional work for the Swift team (and I do not say nor take that lightly), they really need to be supported and implemented at the language/syntax level for first class citizenry.

What benefit do namespaces provide that submodules would not?

···

On May 20, 2016, at 10:43 AM, Robert Schwalbe via swift-evolution <swift-evolution@swift.org> wrote:

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[griotspeak (TJ Usiyan)]

+1 for namespaces.

···

On Fri, May 20, 2016 at 10:52 AM, Haravikk via swift-evolution < swift-evolution@swift.org> wrote:

> On 20 May 2016, at 14:51, Krystof Vasa via swift-evolution < > swift-evolution@swift.org> wrote:
>
> 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.

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.

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.

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 ;)

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!
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Brandon_Knope]

This would be out of scope for Swift 3 right? Or is this relatively "easy" to implement?

Brandon

···

Sent from my iPad

On May 20, 2016, at 11:27 AM, Tony Allevato via swift-evolution <swift-evolution@swift.org> wrote:

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.

On Fri, May 20, 2016 at 8:08 AM T.J. Usiyan via swift-evolution <swift-evolution@swift.org> wrote:
+1 for namespaces.

On Fri, May 20, 2016 at 10:52 AM, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:

> On 20 May 2016, at 14:51, Krystof Vasa via swift-evolution <swift-evolution@swift.org> wrote:
>
> 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.

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.

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.

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 ;)

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!
_______________________________________________
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

[dev-null (Robert Schwalbe)]

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!

Absolutely +1 for namespaces.

Even if you despise the concept of namespaces that seems like that can be addressed by a project and/or company style guide that explicitly forbids their use.

For the people/projects that would embrace namespaces, namespaces would be a godsend.

Sure, you can probably pull all kind of stunts to simulate namespaces, but besides creating additional work for the Swift team (and I do not say nor take that lightly), they really need to be supported and implemented at the language/syntax level for first class citizenry.

[Tony_Allevato]

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.

···

On Fri, May 20, 2016 at 8:08 AM T.J. Usiyan via swift-evolution < swift-evolution@swift.org> wrote:

+1 for namespaces.

On Fri, May 20, 2016 at 10:52 AM, Haravikk via swift-evolution < > swift-evolution@swift.org> wrote:

> On 20 May 2016, at 14:51, Krystof Vasa via swift-evolution < >> swift-evolution@swift.org> wrote:
>
> 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.

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.

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.

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 ;)

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!
_______________________________________________
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

[anandabits (Matthew Johnson)]

We've been discussing some thing like this on another thread about
protocols and this looks like a great solution to the problem
expressed there with a very simple change in syntax (and no new
keyword involved). I'd like to see this turned into a separate
proposal (since I'm new on the group and lack the experience, I'm not
the most suitable person to write).

I agree with others that we can nowadays subvert the purpose of an
existing construct of the language to simulate a namespace and I
believe most people here agree that's not the best way to work but
that's what we have now. I think that's why we're here discussing the
idea of namespaces (or submodules, could someone disambiguate them,
please?).

The big difference is one of encapsulation.

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:

enum Foo { // alternatively: namespace Foo
    static func bar() -> String {}
    struct S {}
}

elsewhere:

import Foo

let s = S() // creates an instance of Foo.S which has been imported into the lexical context
let b = bar() // calls Foo.bar which has been imported into the lexical context

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.

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

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.

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

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.

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.

import Quartz.PDFKit
import Quartz.ImageKit

Quarts is one of these russian doll modules/submodule structure.

versioning part:

modX.framework
   modX.dylib
   Frameworks/
     modXsub1.framework
        modXsub1.dylib
     modXsub2.framework
        modXsub2.dylib

Good example. In this case you’re suggesting that we should be able to compile submodules independently from the containing module. However, they are still delivered together. This makes sense to me and I would support a submodule design that allows for it.

What I am questioning is whether we need namespaces that are open to extension by third parties.

···

On May 20, 2016, at 3:49 PM, L Mihalkovic <laurent.mihalkovic@gmail.com> wrote:

On May 20, 2016, at 10:30 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On May 20, 2016, at 2:48 PM, Leonardo Pessoa <me@lmpessoa.com <mailto:me@lmpessoa.com>> wrote:

If there is 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.

-Matthew

On 20 May 2016 at 12:45, Matthew Johnson via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On May 20, 2016, at 10:21 AM, Austin Zheng via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I think namespaces are definitely worth exploring.

Here's something that might be interesting to research. Right now, you can
have two protocols that have associated types with the same name. If you
adopt both protocols, you have to make the associated types the same, even
if they really don't have anything to do with each other. I think this might
be a good argument for how namespaces can make your code more expressive:

protocol A {
associatedtype Thing
func foo(x: Thing)
}

protocol B {
associatedtype Thing
func bar(x: Thing)
}

struct Foo : A, B {
func foo(x: Int) { }
// Error: type 'Foo' does not conform to protocol 'B'
// protocol requires function 'bar' with type 'Thing'
func bar(x: String) { }
}

In this example, I want to use "Int" for A's Thing type, and "String" for
B's Thing type, but I can’t.

This is totally orthogonal to namespaces. C# provides a mechanism to
clarify implementation of multiple interfaces with the same requirements and
it has nothing to do with C# namespaces. For example, it might be possible
to just prefix member declarations with the name of the protocol. These
implementations would not be visible via the primary type interface.

struct Foo : A, B {
typealias A.Thing = Int
typealias B.Thing = Bar
func foo(x: Int) { }
func bar(x: String) { }
}

We could also allow you to omit the protocol-specific declaration for one of
the conflicting protocols if you wanted that to be visible through the
interface of your concrete type.

struct Foo : A, B {
typealias A.Thing = Int
func foo(x: Int) { }
func bar(x: String) { }
}

The same mechanism could work for any members (properties, methods, etc).
In this case, `foo` is scoped specifically to the implementation of `A` even
though it is not resolving any ambiguity. It is not visible via the
interface of the concrete type `Foo`.

struct Foo : A, B {
typealias A.Thing = Int
func A.foo(x: Int) { }
func bar(x: String) { }
}

Best,
Austin

On May 20, 2016, at 5:16 AM, Adrian Zubarev via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I want to revive this topic.

Is there any technical reason why we can’t have namespaces in Swift? I’ve
found just a few threads about namespaces, but most of them had arguments to
use modules instead.

I’m fine with modules but they just don’t serve everything I would want to.
I can’t enforce the developer to use the modules name if there is no naming
conflict.

I asked in the SwiftPM mail list for a easier Xcode integration of modules,
but the response is exactly the opposite for using modules for namespaces
(read below).

If I’m building one huge project I don’t want to build a lot of different
modules just shiny namespaces and clean code.

So I ask the community again why can’t we have optional namespaces?
--
Adrian Zubarev
Sent with Airmail

Am 19. Mai 2016 bei 22:33:19, Daniel Dunbar (daniel_dunbar@apple.com <mailto:daniel_dunbar@apple.com>)
schrieb:

Right now modules are most appropriately used at the same granularity that
frameworks or shared libraries would be used in C/Obj-C/C++. This is the
situation for which the variety of access control modifiers in Swift and
things like Whole Module Optimization were designed for. While there are a
lot of reasons to like modules as a way to provide namespaces, they really
haven't been designed to provide these very fine grained namespaces.

My guess is that the right answer here doesn't really involve the Xcode
integration, but rather figuring out the right way that these concepts fit
into the language in a first class way. I would expect concepts like
submodules or namespaces to be language concepts that Xcode just exposes,
not something that was coupled together.

- Daniel

On May 18, 2016, at 12:37 PM, Adrian Zubarev via swift-build-dev >>>> <swift-build-dev@swift.org <mailto:swift-build-dev@swift.org>> wrote:

I’d like to discuss an idea that will make development in Xcode easier. I
assume that SwiftPM will see its Xcode integration when the final version
will be released.

Problem I’ll try to describe is mostly about namespaces. Right now some
people abuses enums, struct or classes to create a namespace for a specific
need.

class Reference {
   class String { … }
   class Character {
       enum Error { … }
   }

   private init() {}
}

This will create a pseudo namespace for the nested types:

* Reference.String
* Reference.Character
* Reference.Character.Error

One could argue of using modules instead of abusing a class here, which is a
great argument.

The problem that comes to my mind here is that we will have to create
subprojects inside our main project file and using the references to them
just to achieve that shiny namespace.
One could also use SwiftPM, which is awesome, but there is a need to
re-build the module if any changes have been done. As soon as we’ll create
some complex dependencies between different modules this will get messy.

Before posting here I asked Joe Groff if there is any mailing list I can use
to discuss my idea. He told me this might be a good place, because I was
referring to the package manager. Then I’ve done my research to not create
any redundant thread, but I only found one topic about the integration of
SwiftPM in Xcode:
[swift-build-dev] SwiftPM Xcode Integration

So here are my thoughts about a deeper integration of SwiftPM here:

- What if Xcode will introduce two new types of groups (the folder color
could be orange like Swift for example, or even contain the bird icon).
- These groups are analogous to already existing group types except they’ll
represent Swift modules / packages
- Basically we’ll have a single project file with multiple modules, where
these modules should only exist inside that project (this is my own need
right now)
- Such a package / module group will have a configurable utilities, where
one could configure the modules
- This will reduce the re-building process, allow us to keep everything (not
only .a or we’ll be able to hide .a files and just keep the sourcefiles
inside such groups) inside a single project, gain the shiny namespaces like
above, and make the file management way easier
- This also should allow us create cross-dependencies if there is a good
need for that in our project

+ MainProject
>
+—Reference (module)
>
+—+— Magic (module)
     >
     +— SomeSubMagic (module)

We could easily create cross dependencies between modules here by just using
the modules names and the types they provide.

// SomeSubMagic is a sub module of Magic
class SomeSubMagic {
   var magic: Magic // referring to its parent module
}

What do you think about this?

--
Adrian Zubarev
Sent with Airmail
_______________________________________________
swift-build-dev mailing list
swift-build-dev@swift.org <mailto:swift-build-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-build-dev

_______________________________________________
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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

[Tony_Allevato]

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.

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.

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.

I'm certainly flexible on the way that organization manifests itself. In a
general sense, using 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).

Some other concerns from my own experience in the domain of code generation:

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.

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.

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. 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. So, in one run I have this:

generated1/Foo.swift:
public struct Foo { private init() {} }

generated1/Foo.Bar.swift:
extension Foo {
  struct Bar { ... }
}

and in another run, I have this:

generated2/Foo.swift:
public struct Foo { private init() {} }

generated2/Foo.Baz.swift:
extension Foo {
  struct Baz { ... }
}

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.

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.

···

On Fri, May 20, 2016 at 8:48 AM Matthew Johnson <matthew@anandabits.com> wrote:

On May 20, 2016, at 10:27 AM, Tony Allevato via swift-evolution < > swift-evolution@swift.org> wrote:

On Fri, May 20, 2016 at 8:08 AM T.J. Usiyan via swift-evolution < > swift-evolution@swift.org> wrote:

+1 for namespaces.

On Fri, May 20, 2016 at 10:52 AM, Haravikk via swift-evolution < >> swift-evolution@swift.org> wrote:

> On 20 May 2016, at 14:51, Krystof Vasa via swift-evolution < >>> swift-evolution@swift.org> wrote:
>
> 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.

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.

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.

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 ;)

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!
_______________________________________________
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

[DevAndArtist (Adrian Meister)]

Can submodules enforce the developer to use its name ’Submodule.SomeClass’? Do I have to re-build submodules when I made any changes to them before building the outside code base? Can they efficiently used for cross decencies between different modules/submodules?

···

——
Empty enums is an abuse of the language!

--
Adrian Zubarev
Sent with Airmail

Am 20. Mai 2016 bei 17:49:29, Matthew Johnson via swift-evolution (swift-evolution@swift.org) schrieb:

On May 20, 2016, at 10:43 AM, Robert Schwalbe via swift-evolution <swift-evolution@swift.org> wrote:

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!

Absolutely +1 for namespaces.

Even if you despise the concept of namespaces that seems like that can be addressed by a project and/or company style guide that explicitly forbids their use.

For the people/projects that would embrace namespaces, namespaces would be a godsend.

Sure, you can probably pull all kind of stunts to simulate namespaces, but besides creating additional work for the Swift team (and I do not say nor take that lightly), they really need to be supported and implemented at the language/syntax level for first class citizenry.

What benefit do namespaces provide that submodules would not?

_______________________________________________
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

[L_Mihalkovic]

Regards
(From mobile)

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.

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.

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.

Yes, IMO they would, for the simple fact that they would be a easy to recognize boundary line where the linking behavior would changes (this is what modules do). Because of modules being tied to the dylib behavior, it means namespaces would have to follow suit and basically limit themselves to be submodules (I'm sure something could be done to pretend that 2 separate dylibs form a single namespace, but i am not sure this is the best way for someone to use their time, not to mention how it would break all the work done in the last couple years with profile optimizations).

···

On May 20, 2016, at 5:48 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

On May 20, 2016, at 10:27 AM, Tony Allevato via swift-evolution <swift-evolution@swift.org> wrote:

On Fri, May 20, 2016 at 8:08 AM T.J. Usiyan via swift-evolution <swift-evolution@swift.org> wrote:
+1 for namespaces.

On Fri, May 20, 2016 at 10:52 AM, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:

> On 20 May 2016, at 14:51, Krystof Vasa via swift-evolution <swift-evolution@swift.org> wrote:
>
> 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.

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.

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.

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 ;)

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!
_______________________________________________
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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[anandabits (Matthew Johnson)]

Can submodules enforce the developer to use its name ’Submodule.SomeClass’?

Ideally we would have flexible import syntax that allows for control over *how* names are imported into a lexical context (including the ability to import names within a very specific scope if desired).

Do I have to re-build submodules when I made any changes to them before building the outside code base?

All submodules are part of the same target as the module that contains them.

Can they efficiently used for cross decencies between different modules/submodules?

Cross decencies? I don’t understand.

——
Empty enums is an abuse of the language!

But it is a practical and effective one. Introducing a new construct like namespaces must carry significant advantages over what is already possible.

···

On May 20, 2016, at 10:54 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

--
Adrian Zubarev
Sent with Airmail

Am 20. Mai 2016 bei 17:49:29, Matthew Johnson via swift-evolution (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) schrieb:

> On May 20, 2016, at 10:43 AM, Robert Schwalbe via swift-evolution <swift-evolution@swift.org> wrote:
>
>> 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!
>
> Absolutely +1 for namespaces.
>
> Even if you despise the concept of namespaces that seems like that can be addressed by a project and/or company style guide that explicitly forbids their use.
>
> For the people/projects that would embrace namespaces, namespaces would be a godsend.
>
> Sure, you can probably pull all kind of stunts to simulate namespaces, but besides creating additional work for the Swift team (and I do not say nor take that lightly), they really need to be supported and implemented at the language/syntax level for first class citizenry.

What benefit do namespaces provide that submodules would not?

> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

[anandabits (Matthew Johnson)]

I'm pretty sure he meant "cross dependencies”

It’s still unclear to me how namespaces might help in a way that submodules wouldn’t. Can one of you provide an example of the problem you have in mind and how it is solved with namespaces?

···

On May 20, 2016, at 11:09 AM, Brandon Knope <bknope@me.com> wrote:

Brandon

Sent from my iPad

On May 20, 2016, at 12:06 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On May 20, 2016, at 10:54 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Can submodules enforce the developer to use its name ’Submodule.SomeClass’?

Ideally we would have flexible import syntax that allows for control over *how* names are imported into a lexical context (including the ability to import names within a very specific scope if desired).

Do I have to re-build submodules when I made any changes to them before building the outside code base?

All submodules are part of the same target as the module that contains them.

Can they efficiently used for cross decencies between different modules/submodules?

Cross decencies? I don’t understand.

——
Empty enums is an abuse of the language!

But it is a practical and effective one. Introducing a new construct like namespaces must carry significant advantages over what is already possible.

--
Adrian Zubarev
Sent with Airmail

Am 20. Mai 2016 bei 17:49:29, Matthew Johnson via swift-evolution (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) schrieb:

> On May 20, 2016, at 10:43 AM, Robert Schwalbe via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
>> 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!
>
> Absolutely +1 for namespaces.
>
> Even if you despise the concept of namespaces that seems like that can be addressed by a project and/or company style guide that explicitly forbids their use.
>
> For the people/projects that would embrace namespaces, namespaces would be a godsend.
>
> Sure, you can probably pull all kind of stunts to simulate namespaces, but besides creating additional work for the Swift team (and I do not say nor take that lightly), they really need to be supported and implemented at the language/syntax level for first class citizenry.

What benefit do namespaces provide that submodules would not?

> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

[anandabits (Matthew Johnson)]

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.

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.

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.

I'm certainly flexible on the way that organization manifests itself. In a general sense, using 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).

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

Some other concerns from my own experience in the domain of code generation:

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.

I would expect submodules to be able to do this. The compilation target is the module. Submodules are defined in source within 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).

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.

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.

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.

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.

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. 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. So, in one run I have this:

generated1/Foo.swift:
public struct Foo { private init() {} }

generated1/Foo.Bar.swift:
extension Foo {
  struct Bar { ... }
}

and in another run, I have this:

generated2/Foo.swift:
public struct Foo { private init() {} }

generated2/Foo.Baz.swift:
extension Foo {
  struct Baz { ... }
}

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.

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.

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.

namespaces/Foo.swift:
public struct Foo { private init() {} }

···

On May 20, 2016, at 11:15 AM, Tony Allevato <allevato@google.com> wrote:
On Fri, May 20, 2016 at 8:48 AM Matthew Johnson <matthew@anandabits.com <mailto:matthew@anandabits.com>> wrote:

On May 20, 2016, at 10:27 AM, Tony Allevato via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Fri, May 20, 2016 at 8:08 AM T.J. Usiyan via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
+1 for namespaces.

On Fri, May 20, 2016 at 10:52 AM, Haravikk via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

> On 20 May 2016, at 14:51, Krystof Vasa via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
> 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.

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.

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.

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 ;)

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!
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

[Brandon_Knope]

I'm pretty sure he meant "cross dependencies"

Brandon

···

Sent from my iPad

On May 20, 2016, at 12:06 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

On May 20, 2016, at 10:54 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

Can submodules enforce the developer to use its name ’Submodule.SomeClass’?

Ideally we would have flexible import syntax that allows for control over *how* names are imported into a lexical context (including the ability to import names within a very specific scope if desired).

Do I have to re-build submodules when I made any changes to them before building the outside code base?

All submodules are part of the same target as the module that contains them.

Can they efficiently used for cross decencies between different modules/submodules?

Cross decencies? I don’t understand.

——
Empty enums is an abuse of the language!

But it is a practical and effective one. Introducing a new construct like namespaces must carry significant advantages over what is already possible.

--
Adrian Zubarev
Sent with Airmail

Am 20. Mai 2016 bei 17:49:29, Matthew Johnson via swift-evolution (swift-evolution@swift.org) schrieb:

> On May 20, 2016, at 10:43 AM, Robert Schwalbe via swift-evolution <swift-evolution@swift.org> wrote:
>
>> 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!
>
> Absolutely +1 for namespaces.
>
> Even if you despise the concept of namespaces that seems like that can be addressed by a project and/or company style guide that explicitly forbids their use.
>
> For the people/projects that would embrace namespaces, namespaces would be a godsend.
>
> Sure, you can probably pull all kind of stunts to simulate namespaces, but besides creating additional work for the Swift team (and I do not say nor take that lightly), they really need to be supported and implemented at the language/syntax level for first class citizenry.

What benefit do namespaces provide that submodules would not?

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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[cloutiertyler (Tyler Cloutier)]

This seems like a problem that would be better solved by adopting the Python philosophy that you must provide the full namespace for types, either upon import or explicitly in the code. It also makes searching things in the code easier as it’s clear exactly which namespace each type belongs to.

I don’t see any other motivation for why would you want to force a developer to use the submodule name. If there are no conflicts, why force them to use it?

···

On May 20, 2016, at 8:54 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

Can submodules enforce the developer to use its name ’Submodule.SomeClass’? Do I have to re-build submodules when I made any changes to them before building the outside code base? Can they efficiently used for cross decencies between different modules/submodules?

——
Empty enums is an abuse of the language!

--
Adrian Zubarev
Sent with Airmail

Am 20. Mai 2016 bei 17:49:29, Matthew Johnson via swift-evolution (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) schrieb:

> On May 20, 2016, at 10:43 AM, Robert Schwalbe via swift-evolution <swift-evolution@swift.org> wrote:
>
>> 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!
>
> Absolutely +1 for namespaces.
>
> Even if you despise the concept of namespaces that seems like that can be addressed by a project and/or company style guide that explicitly forbids their use.
>
> For the people/projects that would embrace namespaces, namespaces would be a godsend.
>
> Sure, you can probably pull all kind of stunts to simulate namespaces, but besides creating additional work for the Swift team (and I do not say nor take that lightly), they really need to be supported and implemented at the language/syntax level for first class citizenry.

What benefit do namespaces provide that submodules would not?

> _______________________________________________
> 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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

[Brandon_Knope]

I'm definitely leaning toward submodules too. That seems more "Swifty" to me.

I too would like to see some examples of namespaces in action

Brandon

···

On May 20, 2016, at 12:12 PM, Matthew Johnson <matthew@anandabits.com> wrote:

On May 20, 2016, at 11:09 AM, Brandon Knope <bknope@me.com> wrote:

I'm pretty sure he meant "cross dependencies”

It’s still unclear to me how namespaces might help in a way that submodules wouldn’t. Can one of you provide an example of the problem you have in mind and how it is solved with namespaces?

Brandon

Sent from my iPad

On May 20, 2016, at 12:06 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

On May 20, 2016, at 10:54 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

Can submodules enforce the developer to use its name ’Submodule.SomeClass’?

Ideally we would have flexible import syntax that allows for control over *how* names are imported into a lexical context (including the ability to import names within a very specific scope if desired).

Do I have to re-build submodules when I made any changes to them before building the outside code base?

All submodules are part of the same target as the module that contains them.

Can they efficiently used for cross decencies between different modules/submodules?

Cross decencies? I don’t understand.

——
Empty enums is an abuse of the language!

But it is a practical and effective one. Introducing a new construct like namespaces must carry significant advantages over what is already possible.

--
Adrian Zubarev
Sent with Airmail

Am 20. Mai 2016 bei 17:49:29, Matthew Johnson via swift-evolution (swift-evolution@swift.org) schrieb:

> On May 20, 2016, at 10:43 AM, Robert Schwalbe via swift-evolution <swift-evolution@swift.org> wrote:
>
>> 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!
>
> Absolutely +1 for namespaces.
>
> Even if you despise the concept of namespaces that seems like that can be addressed by a project and/or company style guide that explicitly forbids their use.
>
> For the people/projects that would embrace namespaces, namespaces would be a godsend.
>
> Sure, you can probably pull all kind of stunts to simulate namespaces, but besides creating additional work for the Swift team (and I do not say nor take that lightly), they really need to be supported and implemented at the language/syntax level for first class citizenry.

What benefit do namespaces provide that submodules would not?

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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Tony_Allevato]

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.

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.

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.

I'm certainly flexible on the way that organization manifests itself. In a
general sense, using 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).

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

Some other concerns from my own experience in the domain of code
generation:

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.

I would expect submodules to be able to do this. The compilation target
is the module. Submodules are defined in source *within* 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).

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.

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.

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.

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.

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. 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. So, in one run I have this:

generated1/Foo.swift:
public struct Foo { private init() {} }

generated1/Foo.Bar.swift:
extension Foo {
  struct Bar { ... }
}

and in another run, I have this:

generated2/Foo.swift:
public struct Foo { private init() {} }

generated2/Foo.Baz.swift:
extension Foo {
  struct Baz { ... }
}

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.

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.

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.

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

···

On Fri, May 20, 2016 at 9:37 AM Matthew Johnson <matthew@anandabits.com> wrote:

On May 20, 2016, at 11:15 AM, Tony Allevato <allevato@google.com> wrote:
On Fri, May 20, 2016 at 8:48 AM Matthew Johnson <matthew@anandabits.com> > wrote:

On May 20, 2016, at 10:27 AM, Tony Allevato via swift-evolution < >> swift-evolution@swift.org> wrote:

namespaces/Foo.swift:

public struct Foo { private init() {} }

On Fri, May 20, 2016 at 8:08 AM T.J. Usiyan via swift-evolution < >> swift-evolution@swift.org> wrote:

+1 for namespaces.

On Fri, May 20, 2016 at 10:52 AM, Haravikk via swift-evolution < >>> swift-evolution@swift.org> wrote:

> On 20 May 2016, at 14:51, Krystof Vasa via swift-evolution < >>>> swift-evolution@swift.org> wrote:
>
> 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.

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.

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.

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 ;)

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!
_______________________________________________
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

[DevAndArtist (Adrian Meister)]

Can submodules enforce the developer to use its name ’Submodule.SomeClass’?

Ideally we would have flexible import syntax that allows for control over *how* names are imported into a lexical context (including the ability to import names within a very specific scope if desired).
Ok fine.

Do I have to re-build submodules when I made any changes to them before building the outside code base?

All submodules are part of the same target as the module that contains them.

Can they efficiently used for cross decencies between different modules/submodules?

Cross decencies? I don’t understand.
Sorry it’s me again: "cross dependencies“

MainProject (module/package)

>__Submodule
> >__SubSubmodule
>__AnotherSubmodule

Can I enforce usage of `AnotherSubmodule.Someclass` inside of `SubSubmodule`???
Empty enums is an abuse of the language!

But it is a practical and effective one. Introducing a new construct like namespaces must carry significant advantages over what is already possible.

Still abuse of the language no matter how you turn it. I don’t say `namespaces` should only do the same enums do (in my case it would be enough), if there is more they could solve sure why not. Thats a discussion is for isn’t it? I’m not an expert so I want to learn from people that might provide good examples and reasons why namespaces are good or not.

···

On May 20, 2016, at 10:54 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

--
Adrian Zubarev
Sent with Airmail

[DevAndArtist (Adrian Meister)]

I don’t see any other motivation for why would you want to force a developer to use the submodule name. If there are no conflicts, why force them to use it?
In my particular case I have something like this where i communicate to the developer that there are references involved:

Reference.Buffer

Reference.String

Reference.Character

And so on. String or Character would collide with Swift.String and Swift.Character here. Namespaces would solve this (or submodules).

···

--
Adrian Zubarev
Sent with Airmail

Am 20. Mai 2016 bei 21:18:46, Tyler Cloutier (cloutiertyler@aol.com) schrieb:

I don’t see any other motivation for why would you want to force a developer to use the submodule name. If there are no conflicts, why force them to use it?

[anandabits (Matthew Johnson)]

Can submodules enforce the developer to use its name ’Submodule.SomeClass’?

Ideally we would have flexible import syntax that allows for control over *how* names are imported into a lexical context (including the ability to import names within a very specific scope if desired).

Ok fine.

Do I have to re-build submodules when I made any changes to them before building the outside code base?

All submodules are part of the same target as the module that contains them.

Can they efficiently used for cross decencies between different modules/submodules?

Cross decencies? I don’t understand.

Sorry it’s me again: "cross dependencies“

MainProject (module/package)

   >__Submodule
   > >__SubSubmodule
   >__AnotherSubmodule

Can I enforce usage of `AnotherSubmodule.Someclass` inside of `SubSubmodule`???

With a sufficiently flexible import mechanism you could import `AnotherSubmodule` such that `Someclass` is referenced in the way that you see fit in a specific scope. You could not require all uses to use the full name `AnotherSubmodule.Someclass`. That is a stylistic choice. However, namespaces usually allow for similar flexibility so I don’t see this as a distinction between namespaces and submodules.

Empty enums is an abuse of the language!

But it is a practical and effective one. Introducing a new construct like namespaces must carry significant advantages over what is already possible.

Still abuse of the language no matter how you turn it. I don’t say `namespaces` should only do the same enums do (in my case it would be enough), if there is more they could solve sure why not. Thats a discussion is for isn’t it? I’m not an expert so I want to learn from people that might provide good examples and reasons why namespaces are good or not.

Yes, as I mentioned elsewhere, I agree that we need more. But I want us to be clear on what problems we are solving and what capabilities we need. Empty enums are a good point of reference for that discussion as they are what we have today.

···

On May 20, 2016, at 11:16 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

On May 20, 2016, at 10:54 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

--
Adrian Zubarev
Sent with Airmail
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

[anandabits (Matthew Johnson)]

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.

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.

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.

I'm certainly flexible on the way that organization manifests itself. In a general sense, using 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).

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

Some other concerns from my own experience in the domain of code generation:

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.

I would expect submodules to be able to do this. The compilation target is the module. Submodules are defined in source within 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).

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.

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.

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.

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.

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. 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. So, in one run I have this:

generated1/Foo.swift:
public struct Foo { private init() {} }

generated1/Foo.Bar.swift:
extension Foo {
  struct Bar { ... }
}

and in another run, I have this:

generated2/Foo.swift:
public struct Foo { private init() {} }

generated2/Foo.Baz.swift:
extension Foo {
  struct Baz { ... }
}

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.

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.

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.

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

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

···

On May 20, 2016, at 12:08 PM, Tony Allevato <allevato@google.com> wrote:
On Fri, May 20, 2016 at 9:37 AM Matthew Johnson <matthew@anandabits.com <mailto:matthew@anandabits.com>> wrote:

On May 20, 2016, at 11:15 AM, Tony Allevato <allevato@google.com <mailto:allevato@google.com>> wrote:
On Fri, May 20, 2016 at 8:48 AM Matthew Johnson <matthew@anandabits.com <mailto:matthew@anandabits.com>> wrote:

On May 20, 2016, at 10:27 AM, Tony Allevato via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

namespaces/Foo.swift:

public struct Foo { private init() {} }

On Fri, May 20, 2016 at 8:08 AM T.J. Usiyan via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
+1 for namespaces.

On Fri, May 20, 2016 at 10:52 AM, Haravikk via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

> On 20 May 2016, at 14:51, Krystof Vasa via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
> 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.

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.

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.

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 ;)

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!
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution