[swift-evolution] namespacing protocols to other types
Howard Lovatt
howard.lovatt at gmail.com
Sun Dec 24 22:36:11 CST 2017
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
More information about the swift-evolution
mailing list