[swift-evolution] [Discussion] Namespaces

Vladimir.S svabox at gmail.com
Fri May 20 11:09:54 CDT 2016 

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 at swift.org <mailto:swift-evolution at 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 at apple.com
>> <mailto:daniel_dunbar at 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 at swift.org <mailto:swift-build-dev at 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 at swift.org <mailto:swift-build-dev at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-build-dev
>>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>

More information about the swift-evolution mailing list