[Pitch] Deeper Xcode Integration for SwiftPM


(Adrian Zubarev) #1

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: https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160215/000272.html

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


(Daniel Dunbar) #2

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> 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: https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160215/000272.html

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


(Adrian Zubarev) #3

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) 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> 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: https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160215/000272.html

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
https://lists.swift.org/mailman/listinfo/swift-build-dev


(Austin Zheng) #4

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.

Best,
Austin

···

On May 20, 2016, at 5:16 AM, Adrian Zubarev via swift-evolution <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: https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160215/000272.html

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


(Austin Zheng) #5

Good to know. Maybe it's not namespacing proper, but it's a component in a larger system (which allows disambiguation of ambiguously named types by hierarchical qualification), and should be at least thought about.

Austin

···

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

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: https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160215/000272.html

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


(Leonardo Pessoa) #6

Adrian, I myself don't see a reason other than "Objective-C never had it so why bother about it now?" Most (if not all) .net languages support optional namespaces and even PHP began supporting it in version 5 (if I'm not sure if the version is right). No technical reason against and I'm particularly in favour too so let's hear the others in the group.

···

-----Original Message-----
From: "Adrian Zubarev via swift-evolution" <swift-evolution@swift.org>
Sent: ‎20/‎05/‎2016 09:16 AM
To: "swift-evolution@swift.org" <swift-evolution@swift.org>
Subject: [swift-evolution] [Discussion] Namespaces

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) 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> 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: https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160215/000272.html

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)
<div style="font-family: Helvetica, Arial; font-size:

[The entire original message is not included.]


(Matthew Johnson) #7

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) { }
}

···

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

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: https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160215/000272.html

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 <mailto: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


(Krystof Vasa) #8

I personally dislike the habit of deliberately naming different classes using the same name within a single project/module/library, just using different namespaces - one should be able to deduct from the code *which* class is being used without excessive checking.

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.

I don't have much experience with C++ and C#, but sometimes I have to dive into C# code and you can hear my teeth grind since there is a declaration of a variable of class List and you have no idea which List is this, since there are dozens of classes with this name. You don't always have the code in an IDE to resolve the symbol for you, sometimes you browse it on git, etc.

Which is why I personally find modules sufficient in providing a way to prevent naming collisions, yet strict enough to discourage the habits of other languages described above.

Hence for me -1 on introducing multiple namespaces within a single module.

···

On May 20, 2016, at 3:27 PM, Leonardo Pessoa via swift-evolution <swift-evolution@swift.org> wrote:

Adrian, I myself don't see a reason other than "Objective-C never had it so why bother about it now?" Most (if not all) .net languages support optional namespaces and even PHP began supporting it in version 5 (if I'm not sure if the version is right). No technical reason against and I'm particularly in favour too so let's hear the others in the group.
From: Adrian Zubarev via swift-evolution <mailto:swift-evolution@swift.org>
Sent: ‎20/‎05/‎2016 09:16 AM
To: swift-evolution@swift.org <mailto:swift-evolution@swift.org>
Subject: [swift-evolution] [Discussion] Namespaces

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: https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160215/000272.html

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)

[The entire original message is not included.]
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Luis Henrique Borges) #9

Good example, +1 for namespaces in swift.

···

On Fri, May 20, 2016 at 4:21 PM, Austin Zheng via swift-evolution < 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.

Best,
Austin

On May 20, 2016, at 5:16 AM, Adrian Zubarev via swift-evolution < > 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)
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> 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:
https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160215/000272.html

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


(Leonardo Pessoa) #10

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

···

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

On May 20, 2016, at 10:21 AM, Austin Zheng via swift-evolution > <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> 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)
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> 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:
https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160215/000272.html

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


(Adrian Zubarev) #11

+1 for this example! :slight_smile:

···

--
Adrian Zubarev
Sent with Airmail

Am 20. Mai 2016 bei 17:20:42, Austin Zheng (austinzheng@gmail.com) schrieb:

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.

Best,
Austin

On May 20, 2016, at 5:16 AM, Adrian Zubarev via swift-evolution <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) 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> 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: https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160215/000272.html

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


(Vladimir) #12

+1

Exactly in this example I'd probably want to have this to make it all clear regarding 'things':

struct Foo : A,B {
   typealias A.Thing = Int
   typealias B.Thing = String

   func foo(x: Int) { }
   func bar(x: String) { }
}

···

On 20.05.2016 18:21, Austin Zheng via swift-evolution 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:

protocolA {
  associatedtypeThing
  funcfoo(x: Thing)
}

protocolB {
  associatedtypeThing
  funcbar(x: Thing)
}

structFoo : A, B{
  funcfoo(x: Int) { }
  // Error: type 'Foo' does not conform to protocol 'B'
  // protocol requires function 'bar' with type 'Thing'
  funcbar(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.

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: https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160215/000272.html

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 <mailto: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


(Vladimir) #13

But this works:

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

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

struct Foo: A,B {
   typealias Thing = String

   func foo(x: Int) { }
   func foo(x: String) { }
}

or this also works:

struct Foo: A,B {
   typealias Thing = Int

   func foo(x: Int) { }
   func foo(x: String) { }
}

···

On 20.05.2016 18:21, Austin Zheng via swift-evolution 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:

protocolA {
  associatedtypeThing
  funcfoo(x: Thing)
}

protocolB {
  associatedtypeThing
  funcbar(x: Thing)
}

structFoo : A, B{
  funcfoo(x: Int) { }
  // Error: type 'Foo' does not conform to protocol 'B'
  // protocol requires function 'bar' with type 'Thing'
  funcbar(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.

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: https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160215/000272.html

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 <mailto: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


(Austin Zheng) #14

Yes. In this case you are basically telling the compiler which of the two foo()s you want to use to satisfy the protocol requirement, and which is just another method that happens to also be named foo().

Austin

···

On May 20, 2016, at 9:09 AM, Vladimir.S <svabox@gmail.com> wrote:

But this works:

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

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

struct Foo: A,B {
typealias Thing = String

func foo(x: Int) { }
func foo(x: String) { }
}

or this also works:

struct Foo: A,B {
typealias Thing = Int

func foo(x: Int) { }
func foo(x: String) { }
}

On 20.05.2016 18:21, Austin Zheng via swift-evolution 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:

protocolA {
associatedtypeThing
funcfoo(x: Thing)
}

protocolB {
associatedtypeThing
funcbar(x: Thing)
}

structFoo : A, B{
funcfoo(x: Int) { }
// Error: type 'Foo' does not conform to protocol 'B'
// protocol requires function 'bar' with type 'Thing'
funcbar(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.

Best,
Austin

On May 20, 2016, at 5:16 AM, Adrian Zubarev via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto: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>
<mailto: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> <mailto: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: https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160215/000272.html

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> <mailto: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 <mailto:swift-evolution@swift.org> <mailto: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


(Matthew Johnson) #15

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.

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 May 20, 2016, at 2:48 PM, Leonardo Pessoa <me@lmpessoa.com> wrote:

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

On May 20, 2016, at 10:21 AM, Austin Zheng via swift-evolution >> <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> 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)
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> 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:
https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160215/000272.html

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


(Haravikk) #16

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 :wink:

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!

···

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.


(Adrian Zubarev) #17

I personally dislike the habit of deliberately naming different classes using the same name within a single project/module/library, just using different namespaces - one should be able to deduct from the code *which* class is being used without excessive checking.

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.
I assume you would still stick around with a standalone `SomeCustomeViewDelegate` protocol rather than use `SomeCustomView.Delegate` and nest the `Delegate` protocol inside `SomeCustomView`? This isn’t an example about namespaces but you get the idea.

What looks better to you?

protocol SomeCustomeViewDelegate {…}

or

extension SomeCustomView {

 protocol Delegate \{…\}

}

I don't have much experience with C++ and C#, but sometimes I have to dive into C# code and you can hear my teeth grind since there is a declaration of a variable of class List and you have no idea which List is this, since there are dozens of classes with this name. You don't always have the code in an IDE to resolve the symbol for you, sometimes you browse it on git, etc.

Which is why I personally find modules sufficient in providing a way to prevent naming collisions, yet strict enough to discourage the habits of other languages described above.
In my eyes namespaces in Swift (if we get them) should be optional which will allow someone write clear code if there is any desire.

For my project I’m working on it’s something like:

Reference.Buffer

Reference.String

Where I’m working with Pointers inside.

If I will use a module for this in my project, there will be a name collision with String when I forget about `Reference.`.

One can already achieve a pseudo namespaces by abusing structs for example.

struct Namespace {
private init() {}
}

But you still can something like:

extension Namespace { … }

This doesn’t fell right.

Downside of modules in a huge project is that you might need re-build modules all over again when you changes something. :confused:

···

--
Adrian Zubarev
Sent with Airmail


(Vladimir) #18

Oh, yes, stupid me :slight_smile: Was playing with code and forget to change B.foo to B.bar to check.

IMO We definitely need improvements in protocol implementation in types.

···

On 20.05.2016 19:14, Austin Zheng wrote:

Yes. In this case you are basically telling the compiler which of the two
foo()s you want to use to satisfy the protocol requirement, and which is
just another method that happens to also be named foo().

Austin

On May 20, 2016, at 9:09 AM, Vladimir.S <svabox@gmail.com >> <mailto:svabox@gmail.com>> wrote:

But this works:

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

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

struct Foo: A,B {
typealias Thing = String

func foo(x: Int) { }
func foo(x: String) { }
}

or this also works:

struct Foo: A,B {
typealias Thing = Int

func foo(x: Int) { }
func foo(x: String) { }
}

On 20.05.2016 18:21, Austin Zheng via swift-evolution 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:

protocolA {
associatedtypeThing
funcfoo(x: Thing)
}

protocolB {
associatedtypeThing
funcbar(x: Thing)
}

structFoo : A, B{
funcfoo(x: Int) { }
// Error: type 'Foo' does not conform to protocol 'B'
// protocol requires function 'bar' with type 'Thing'
funcbar(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.

Best,
Austin

On May 20, 2016, at 5:16 AM, Adrian Zubarev via swift-evolution >>>> <swift-evolution@swift.org >>>> <mailto: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>
<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> <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: https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160215/000272.html

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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
<mailto: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


(L Mihalkovic) #19

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

···

On May 20, 2016, at 10:30 PM, Matthew Johnson via swift-evolution <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:
https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160215/000272.html

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


(Matthew Johnson) #20

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.

···

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 <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 :wink:

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