[swift-evolution] [Discussion] Namespaces

Fri May 20 11:45:12 CDT 2016

Oh, yes, stupid me :-) 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 at gmail.com
>> <mailto:svabox at 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 at swift.org
>>>> <mailto: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>
>>>> <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> <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> <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> <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>