vv On Sun, Dec 24, 2017 at 11:36 PM, Howard Lovatt <howard.lov...@gmail.com> 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