<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Yeah I wrote that proposal. I eventually stripped it down to just disallow all capturing, but it was still not selected by the core team for review ¯\_(ツ)_/¯<div class=""><br class=""></div><div class="">As for capturing semantics, once you start working through use-cases, it’s becomes clear that it's going to require generalised existentials. Otherwise, how would you use a Generic<T>.P?</div><div class=""><br class=""></div><div class="">struct Generic<T> {</div><div class=""> protocol P { func f() -> T }</div><div class=""><br class=""></div><div class=""> var object: P // uh-oh! ‘Generic protocol can only be used as a generic parameter constraint'</div><div class="">}</div><div class=""><br class=""></div><div class="">So, you would need to add a generic parameter to actually <i class="">use</i> P from within Generic<T>, which of course limits you to a single concrete type of P:</div><div class=""><br class=""></div><div class="">struct Generic<T, TypeOfP> where TypeOfP: Self.P { // Could this even work? What if P captures TypeOfP?</div><div class=""> protocol P { /* … */ }</div><div class=""> var object: TypeOfP</div><div class="">}</div><div class=""><br class=""></div><div class="">Which is just yucky.</div><div class=""><br class=""></div><div class="">Ideally, the type of ‘object’ should be ‘Any<P where P.T == T>’, to express that it can be any conforming type with the appropriate constraints. You wouldn’t need to write that all out; we could infer that capturing is equivalent to a same-type constraint (or perhaps one of these “generalised supertype constraints” that were pitched recently). But we can’t express those kinds of existentials everywhere in the type-system today, so most examples of capturing fall down pretty quickly.</div><div class=""><br class=""></div><div class="">- Karl<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 25. Dec 2017, at 03:56, Slava Pestov via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">There was a proposal to allow protocols to be nested inside types at one point but it didn’t move forward.<br class=""><br class="">Basically, if the outer type is a non-generic class, struct or enum, there’s no conceptual difficulty at all.<br class=""><br class="">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:<br class=""><br class="">struct Generic<T> {<br class=""> protocol P {<br class=""> func f() -> T<br class=""> }<br class="">}<br class=""><br class="">struct Conforms : Generic<Int>.P {<br class=""> func f() -> Int { … } // Like this?<br class="">}<br class=""><br class="">let c = Conforms()<br class="">c is Generic<String>.P // is this false? Ie, are Generic<Int>.P and Generic<String>.P different protocols?<br class=""><br class="">Slava<br class=""><br class=""><blockquote type="cite" class="">On Dec 24, 2017, at 6:53 PM, Kelvin Ma via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">is there a reason why it’s not allowed to nest a protocol declaration inside another type?<br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></blockquote><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></div></body></html>