<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="">Hi Victor,<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 10, 2015, at 2:25 PM, Виктор Шаманов 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 dir="ltr" class=""><span style="font-size:13px" class="">Happy Friday everyone!</span><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class="">I wonder why the protocol declaration should be only at the file scope?</div><div style="font-size:13px" class="">Is this a design choice or limitation of the current implementation?</div></div></div></blockquote><div><br class=""></div>It is mostly the latter. As long as a protocol does not generic parameters from the outer type, there shouldn’t be any conceptual difficulties in allowing this, just implementation churn. It would make a good beginner project for someone who wants to dive deeper into Sema.</div><div><br class=""></div><div>As for capturing generic parameters in nested types, we do want to make this possible for nested concrete types, but it needs a fair bit of Sema and SIL work. For protocols, one can imagine something like this:</div><div><br class=""></div><div>class C<T> {</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>protocol P {</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>func f() -> T</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>struct S : P {</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>func f() -> T { … }</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div>}</div><div><br class=""></div><div>However I’m not sure what the implementation implications of this are.</div><div><br class=""></div><div>Slava</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class="">I think, the ability of declaring protocols inside the other declarations would improve readability and code-organization.</div><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class="">For example, instead of:</div><div style="font-size:13px" class=""><br class=""></div><blockquote style="font-size:13px;margin:0px 0px 0px 40px;border:none;padding:0px" class=""><div class="">protocol UITableViewDelegate {</div><div class="">...</div><div class="">}</div><div class=""><br class=""></div><div class="">class UITableView {</div><div class=""> var delegate: UITableViewDelegate?</div><div class="">}</div></blockquote><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class="">we would write:</div><div style="font-size:13px" class=""><br class=""></div><blockquote style="font-size:13px;margin:0px 0px 0px 40px;border:none;padding:0px" class=""><div class="">class UITableView {</div><div class=""><br class=""></div></blockquote><blockquote style="font-size:13px;margin:0px 0px 0px 40px;border:none;padding:0px" class=""><div class=""> protocol Delegate {</div><div class=""> ...</div><div class=""> }</div></blockquote><blockquote style="font-size:13px;margin:0px 0px 0px 40px;border:none;padding:0px" class=""><div class=""><br class=""></div><div class=""> var delegate: Delegate?</div><div class="">}</div></blockquote><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class="">Thanks</div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=NLTid1W7V2mxBEfr5Y3KfTntaxSmOQp5vjACZc9Eh1-2FgZ65px6LoijxEOB2K8E6-2B0c6uHQSJAAwdWma-2FMEIvzFgLasfMoUac5CjhxKohBL-2BIIo7OgoGlRRL8nSMFcN5J-2BbmdIO8kbEDLDfCthePCv0YDiUYwu4UaQJbAUh0UK60COIScIGryNq2I4ndApn93SFD-2BlhL3dcXFE55eGBVgMvbn4DX3cwwWp0ypbG9GQ0w-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" 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></blockquote></div><br class=""></div></body></html>