[swift-evolution] namespacing protocols to other types

[Jon Gilbert]

Amen. This seems like an appropriate step towards better name-spacing, and it’s one we have sorely missed on one manor project at work. 

We maintain a framework that wraps our various web APIs with convenience methods and data model types. Since the APIs are versioned, we have nested most things inside a struct or enum that has “_V1”, “_V2” etc. appended. The protocols not being able to go inside there is pretty annoying. 

Still, even if protocols could be nested inside non-generic struct and enum types, it still doesn’t seem like the best way to name-space in the first place, because at that point, we are not making a “name space struct/enum” for any other purpose than name-spacing. It just seems like that’s not what those types are intended to be used for. 

If you are using a struct/enum/class more than just namespacing, then OK, because I can definitely understand wanting to nest a delegate protocol under the type whose delegate it will be, for example.

However, name-spacing via a struct/enum just for versioning or just to group some things together by domain does not seem like a good style over-all. Because then, everything has to be indented one additional level than it really should be, and you get all these extraneous extensions everywhere. It’s just not pretty.

I’d much rather have an easier way to work with modules and module maps that did not involve cluttering up the project in XCode with 30 extra build targets that causes 30 sub-frameworks. This seems to have a very negative impact on app load times from what our testing has indicated, and this kind of name-spacing relies on changes to the XCode project file, making it harder to track in git and maintain across multiple project files, etc. Is there currently a better workaround?

There must be a compelling reason why we cannot simply namespace by typing “namespace MyNameSpace” at the top of each source file. I don’t know what the reason is, but I am kind if afraid to ask, since it feels like the kind of thing that surely has been debated here ad nauseam in the past... I will research list history later.

I have a feeling the ABI Resilience doc talking a lot about the @versioned and @available keywords might hint at another option for the use case at my job, but it certainly does not seem to replace an easy and clean way to namespace.  

Jon


> On Dec 24, 2017, at 20:36, Howard Lovatt via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I would say yes they are different for the example. Definitely something I miss is nesting types to given a seperate namespace. 
> 
> -- Howard. 
> 
>> On 24 Dec 2017, at 9:56 pm, Slava Pestov via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> There was a proposal to allow protocols to be nested inside types at one point but it didn’t move forward.
>> 
>> Basically, if the outer type is a non-generic class, struct or enum, there’s no conceptual difficulty at all.
>> 
>> If the outer type is a generic type or another protocol, you have a problem where the inner protocol can reference generic parameters or associated types of the outer type. This would either have to be banned, or we would need to come up with coherent semantics for it:
>> 
>> struct Generic<T> {
>> protocol P {
>>   func f() -> T
>> }
>> }
>> 
>> struct Conforms : Generic<Int>.P {
>> func f() -> Int { … } // Like this?
>> }
>> 
>> let c = Conforms()
>> c is Generic<String>.P // is this false? Ie, are Generic<Int>.P and Generic<String>.P different protocols?
>> 
>> Slava
>> 
>>> On Dec 24, 2017, at 6:53 PM, Kelvin Ma via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> is there a reason why it’s not allowed to nest a protocol declaration inside another type?
>>> _______________________________________________
>>> swift-evolution mailing list
>>> 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
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution