<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=""><div class="">Extremely strong +1.</div><div class=""><br class=""></div><div class="">I’ve got a bunch of Objective-C-style really long type names of the sort “MyProtocol”, “MyProtocolSomeTypeEnum”, “MyProtocolSomeOptionsEnum”, etc. It would be really nice to make those Swiftier.</div><div class=""><br class=""></div><div class="">Charles</div><br class=""><div><blockquote type="cite" class=""><div class="">On Oct 17, 2016, at 12:59 PM, Karl 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=""><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="">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" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160425/016074.html</a><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">so to summarise, newly legal would be:</div><div class=""><br class=""></div><div class="">class MyClass {</div><div class=""><br class=""></div><div class=""> protocol Delegate {</div><div class=""> }</div><div class="">}</div><div class=""><br class=""></div><div class="">and also:</div><div class=""><br class=""></div><div class="">protocol MyProto {</div><div class=""><br class=""></div><div class=""> enum SomeValue {</div><div class=""> }</div><div class=""><br class=""></div><div class=""> protocol Delegate {</div><div class=""> associatedType ExpectedContent</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func receive(_: ExpectedContent, for: SomeValue)</div><div class=""><br class=""></div><div class=""> protocol SecondaryTarget {</div><div class=""> func receive(_ : ExpectedContent)</div><div class=""> }</div><div class=""> }</div><div class="">}</div><div class=""><br class=""></div><div class="">When conforming to a nested protocol, you can just use the name of the protocol:</div><div class=""><br class=""></div><div class="">class Host : MyProto.Delegate {</div><div class="">}</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">class SecondaryProcessor : Host.SecondaryTarget {</div><div class="">}</div><div class=""><br class=""></div><div class="">If we’re good with this, I’ll write up a proposal.</div><div class=""><div class=""><div class=""><br class=""></div><div class="">- Karl</div></div></div></div>_______________________________________________<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></blockquote></div><br class=""></body></html>