<div dir="ltr">As a ruby programmer, I have to admit that I've tried to do this in Swift several times before remembering again that it isn't possible.<div>+1<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 28, 2016 at 3:44 PM, Howard Lovatt 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">+1 very handy to associate types together<div class="HOEnZb"><div class="h5"><br><br>On Friday, 29 April 2016, Michael Peternell via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think that would be a good feature.<br>
<br>
> Am 28.04.2016 um 19:15 schrieb Brad Hilton via swift-evolution <<a>swift-evolution@swift.org</a>>:<br>
><br>
> Type nesting allows some convenient and straightforward semantics that we see inside the Swift standard library such as views on String like String.CharacterView, String.UnicodeScalarView, etc. However a protocol cannot be nested in a type and gives a non-obvious error that the “Declaration is only valid at file scope.” Just as other nested types allow proper contextual scoping, a nested protocol could make a lot sense for a number of patterns. For example, there are many “Delegate” protocols throughout the Cocoa frameworks. Here’s a controller/delegate pattern before and after type nesting:<br>
><br>
> // Without type nesting<br>
><br>
> protocol MyControllerDelegate : class {<br>
><br>
> }<br>
><br>
> class MyController {<br>
><br>
> weak var delegate: MyControllerDelegate?<br>
><br>
> }<br>
><br>
> // With type nesting<br>
><br>
> class MyController {<br>
><br>
> weak var delegate: Delegate?<br>
><br>
> protocol Delegate : class {<br>
><br>
> }<br>
><br>
> }<br>
><br>
> Though the change is mostly semantics, it does allow an explicit association between My Controller and the Delegate instead of only a named association. It also cleans up the module name space like other nested types and makes associated protocols more discoverable in my opinion.<br>
><br>
> I’d love to hear everyone’s thoughts.<br>
><br>
> Brad Hilton<br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a>swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a>swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote><br><br></div></div><span class="HOEnZb"><font color="#888888">-- <br>-- Howard.<br>
</font></span><br>_______________________________________________<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/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">kurt@CircleW.org<br><a href="http://www.CircleW.org/kurt/" target="_blank">http://www.CircleW.org/kurt/</a><br></div>
</div></div></div>