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
