<div dir="ltr">I want this feature. Both class in protocol and protocol in class could clean up many relationships but I think that a blocking concern is "How does this interact with generics?" Nesting types in generic types is already disallowed and how different is this feature from that?</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 17, 2016 at 2:20 PM, Adrian Zubarev via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div class="m_-1870003603720591240bloop_markdown"><p>Two weeks ago there was a similar pitch here <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161003/027643.html" target="_blank">https://lists.swift.org/<wbr>pipermail/swift-evolution/<wbr>Week-of-Mon–20161003/027643.<wbr>html</a></p>
<p>In general I’m in favor of this feature, but I don’t know any technical issues this might have or does already have.</p>
<p>As I said in the other thread.</p>
<ul>
<li><p>I’m for nested everything.</p></li>
<li><p>Nested <code>extensions</code> to reduce noise at some point, BUT this should not remove <code>extension A.B { … }</code> completely. </p>
<pre><code class="m_-1870003603720591240swift">class A {
class B { … }
extension B { … } // extends A.B
}
</code></pre></li>
<li><p>We already have <code>A.B</code> syntax for extensions, why don’t we allow it for type declarations to reduce nesting (sometimes you don’t want to cluster everything)? Basically something like <code>class A.B { … }</code> would be a shortcut for <code>extension A { class B { … } }</code> and is bounded by the access modifier of <code>A</code>. (This is probably additive.)</p></li><span class="HOEnZb"><font color="#888888">
</font></span></ul><span class="HOEnZb"><font color="#888888">
<p></p></font></span></div><div class="m_-1870003603720591240bloop_original_html"><span class="HOEnZb"><font color="#888888"><div id="m_-1870003603720591240bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div> <br> <div id="m_-1870003603720591240bloop_sign_1476727943171306240" class="m_-1870003603720591240bloop_sign"><div style="font-family:helvetica,arial;font-size:13px">-- <br>Adrian Zubarev<br>Sent with Airmail</div></div></font></span><div><div class="h5"> <br><p class="m_-1870003603720591240airmail_on">Am 17. Oktober 2016 um 19:59:54, Karl via swift-evolution (<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>) schrieb:</p> </div></div><blockquote type="cite" class="m_-1870003603720591240clean_bq"><span><div style="word-wrap:break-word"><div></div><div><div><div class="h5">
I was just doing some googling, turns out there was a discussion
about nesting protocols in other types that seemed to go positively
a long time ago: <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160425/016074.html" target="_blank">https://lists.swift.org/<wbr>pipermail/swift-evolution/<wbr>Week-of-Mon-20160425/016074.<wbr>html</a>
<div><br></div>
<div>I would additionally like to propose that protocols
be allowed to contain nested types (including other protocols).
Relevant ABI issue is that the standard library contains enums for
“FloatingPointRoundingRule”, “FloatingPointClassification” and
“FloatingPointSign”. They would probably be better expressed as
“FloatingPoint.RoundingRule”, “.Sign", etc.</div>
<div><br></div>
<div>so to summarise, newly legal would be:</div>
<div><br></div>
<div>class MyClass {</div>
<div><br></div>
<div> protocol Delegate {</div>
<div> }</div>
<div>}</div>
<div><br></div>
<div>and also:</div>
<div><br></div>
<div>protocol MyProto {</div>
<div><br></div>
<div> enum SomeValue {</div>
<div> }</div>
<div><br></div>
<div> protocol Delegate {</div>
<div> associatedType
ExpectedContent</div>
<div><br></div>
<div>func receive(_: ExpectedContent, for:
SomeValue)</div>
<div><br></div>
<div> protocol SecondaryTarget
{</div>
<div> func
receive(_ : ExpectedContent)</div>
<div> }</div>
<div> }</div>
<div>}</div>
<div><br></div>
<div>When conforming to a nested protocol, you can just
use the name of the protocol:</div>
<div><br></div>
<div>class Host : MyProto.Delegate {</div>
<div>}</div>
<div><br></div>
<div>Except if a protocol in the chain has associated
types, then you must use a concrete, conforming type instead (as
you would in the first example — MyClass.Delegate):</div>
<div><br></div>
<div>class SecondaryProcessor : Host.SecondaryTarget
{</div>
<div>}</div>
<div><br></div>
<div>If we’re good with this, I’ll write up a
proposal.</div>
<div>
<div>
<div><br></div>
<div>- Karl</div>
</div>
</div></div></div><span class="">
______________________________<wbr>_________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br></span></div></div></span></blockquote></div><div class="m_-1870003603720591240bloop_markdown"><p></p></div></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div>