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