<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I left some review comments here:<div class=""><br class=""></div><div class=""><a href="https://github.com/apple/swift-evolution/commit/ff654e4" class="">https://github.com/apple/swift-evolution/commit/ff654e4</a></div><div class=""><br class=""></div><div class="">Slava</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 18, 2017, at 12:17 AM, Karl Wagner &lt;<a href="mailto:razielim@gmail.com" class="">razielim@gmail.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 18 Jan 2017, at 01:07, Douglas Gregor &lt;<a href="mailto:dgregor@apple.com" class="">dgregor@apple.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Nov 5, 2016, at 2:44 AM, Karl via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">On 2 Nov 2016, at 20:54, Slava Pestov &lt;<a href="mailto:spestov@apple.com" class="">spestov@apple.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class="Apple-interchange-newline">On Nov 2, 2016, at 8:32 AM, Paul Cantrell &lt;<a href="mailto:cantrell@pobox.com" class="">cantrell@pobox.com</a>&gt; wrote:<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Oct 24, 2016, at 4:43 PM, Slava Pestov &lt;<a href="mailto:spestov@apple.com" class="">spestov@apple.com</a>&gt; wrote:<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Oct 24, 2016, at 8:12 AM, Paul Cantrell &lt;<a href="mailto:cantrell@pobox.com" class="">cantrell@pobox.com</a>&gt; wrote:<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Oct 24, 2016, at 5:09 AM, Slava Pestov via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:<br class=""><br class="">However protocols nested inside types and types nested inside protocols is still not supported, because protocols introduce a separate series of issues involving associated types and the ’Self’ type.<br class=""><br class="">The hard part of getting nested generics right is what to do if a nested type ‘captures’ generic parameters of the outer type. For non-protocol types, the behavior here is pretty straightforward.<br class=""><br class="">If we allow protocols to be nested inside other types, we have to decide what to do if the protocol ‘closes over’ generic parameters of the outer type. For example,<br class=""><br class="">struct A&lt;T&gt; {<br class="">protocol P {<br class="">func requirement() -&gt; T<br class="">}<br class="">}<br class=""><br class="">Presumably A&lt;Int&gt;.P and A&lt;String&gt;.P are distinct types, and A.P has a hidden associated type corresponding to the type parameter ’T’?<br class=""><br class="">The other case is problematic too — the nested type might refer to an associated type of the outer protocol:<br class=""><br class="">protocol P {<br class="">associatedtype A<br class=""><br class="">struct T {<br class="">var value: A<br class="">}<br class="">}<br class=""><br class="">Now writing P.T does not make sense, for the same reason that we cannot form an existential of type P.A. We could prohibit references to outer associated types of this form, or we could figure out some way to give it a meaning. If C is a concrete type conforming to P, then certainly C.T makes sense, for instance. Internally, the nested type A.T could have a hidden ‘Self’ generic type parameter, so that writing C.T is really the same as P.T&lt;C&gt;.<br class=""><br class="">Protocols nested inside protocols also have the same issue.<br class=""></blockquote><br class="">FWIW, in almost all the situations where I’ve wanted to nest types inside protocols and generic types, it’s only as a namespacing convenience. Most often, it’s an enum type that’s used only by a single method, and having it at the top of the module namespace adds clutter.<br class=""><br class="">Here’s a real life example pared down. I wish I could do this:<br class=""><br class="">public struct ResponseContentTransformer&lt;InputContentType, OutputContentType&gt;: ResponseTransformer {<br class=""><br class="">&nbsp;&nbsp;public init(onInputTypeMismatch mismatchAction: InputTypeMismatchAction = .error) {<br class="">&nbsp;&nbsp;&nbsp;&nbsp;...<br class="">&nbsp;&nbsp;}<br class=""><br class="">&nbsp;&nbsp;public enum InputTypeMismatchAction { &nbsp;// Does not depend on generic types above<br class="">&nbsp;&nbsp;&nbsp;&nbsp;case error<br class="">&nbsp;&nbsp;&nbsp;&nbsp;case skip<br class="">&nbsp;&nbsp;&nbsp;&nbsp;case skipIfOutputTypeMatches<br class="">&nbsp;&nbsp;}<br class=""><br class="">}<br class=""><br class="">InputTypeMismatchAction is tightly associated with ResponseContentTransformer, and is confusing as a top-level type.<br class=""><br class="">What do you think about providing a “no captures” modifier for nested types — like static inner classes in Java? Then Swift could provide the namespace nesting I wish for this without having to resolve the trickier type capture questions yet.<br class=""><br class="">Alternatively, what if (1) outer types aren’t capture unless they’re referenced, and (2) nesting is only illegal if there’s a capture? Then my code above would compile, as would this:<br class=""><br class="">public struct S&lt;T&gt; {<br class="">&nbsp;&nbsp;public enum Foo {<br class="">&nbsp;&nbsp;&nbsp;&nbsp;case yin<br class="">&nbsp;&nbsp;&nbsp;&nbsp;case yang<br class="">&nbsp;&nbsp;}<br class="">}<br class=""><br class="">…but this wouldn’t:<br class=""><br class="">public struct S&lt;T&gt; {<br class="">&nbsp;&nbsp;public enum Foo {<br class="">&nbsp;&nbsp;&nbsp;&nbsp;case yin(thing: T) &nbsp;// capture of T illegal (for now)<br class="">&nbsp;&nbsp;&nbsp;&nbsp;case yang<br class="">&nbsp;&nbsp;}<br class="">}<br class=""><br class="">Either of these approaches would allow hygienic namespacing now while leaving the door open to outer type capture in the future.<br class=""></blockquote><br class="">Yeah, this makes sense for a first cut at this feature.<br class=""><br class="">Slava<br class=""></blockquote><br class="">Should I take a crack at writing up a proposal for this? Now? After ABI work is done? (Probably the latter “OK if no captures” approach?) Eager to help; don’t want to be in the way.<br class=""></blockquote><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">Just speaking for myself and not the whole team — I think you can submit the proposal at any time, we’re unlikely to get around to doing it, if you want to take a crack that would be great (again, with ‘no captures’ it’s “trivial”).</span><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">Slava</span><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class="">P</blockquote></div></blockquote></div><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Sorry, let this slip. Proposal sent -&nbsp;<a href="https://github.com/apple/swift-evolution/pull/552" class="">https://github.com/apple/swift-evolution/pull/552</a></div></div></blockquote><br class=""></div><div class="">(Coming back to this after a very long time)</div><div class=""><br class=""></div><div class="">One very high-level comment: one of your early examples is making the Delegate of a view. Did you consider making this an Objective-C translation rule as well, so that *Delegate and *DataSource protocols would be imported as nested types within a class with the name signified by *, e.g.,&nbsp;</div><div class=""><br class=""></div><div class=""><font face="Menlo" class=""><span class="Apple-tab-span" style="white-space:pre">        </span>class UITableView {</font></div><div class=""><font face="Menlo" class=""><span class="Apple-tab-span" style="white-space:pre">        </span>&nbsp; @objc(UITableViewDataSource)</font></div><div class=""><font face="Menlo" class=""><span class="Apple-tab-span" style="white-space:pre">        </span>&nbsp; protocol DataSource { … }</font></div><div class=""><font face="Menlo" class=""><br class=""></font></div><div class=""><font face="Menlo" class=""><span class="Apple-tab-span" style="white-space: pre;">        </span>&nbsp; @objc(UITableViewDelegate)</font></div><div class=""><font face="Menlo" class=""><span class="Apple-tab-span" style="white-space: pre;">        </span>&nbsp; protocol Delegate { … }</font></div><div class=""><font face="Menlo" class=""><span class="Apple-tab-span" style="white-space:pre">        </span>}</font></div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>- Doug</div><div class=""><br class=""></div><br class=""></div></div></blockquote></div><br class=""><div class="">Yes, and platform SDK changes are mentioned under “Source Compatibility”.</div><div class=""><br class=""></div><div class="">I’ve removed the standard library stuff from it now, that can happen later. Would we be able to get the ball rolling on getting it reviewed?</div><div class=""><br class=""></div><div class="">Thanks</div><div class=""><br class=""></div><div class="">- Karl</div><div class=""><br class=""></div></div></div></blockquote></div><br class=""></div></body></html>