<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>Ruby has rules for how "return", "next" (= continue) and "break" behave in closures which match the expectations quite well. It allows next and break to return values, too.</div><div><br></div><div>-Thorsten </div><div><br>Am 09.01.2016 um 21:21 schrieb Greg Parker via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 8, 2016, at 10:00 PM, Jacob Bandes-Storch 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="">I sympathize with the problem statement, but I wonder if we should instead be considering ways of allowing control-flow statements (break, continue, return) to work from inside @noescape closures.</div></div></blockquote><br class=""></div><div>@noescape is insufficient to allow that. You need more constraints on the closure's caller, perhaps even cooperation from the closure's caller depending on how the control flow is supposed to work.</div><div><br class=""></div><div>Off the top of my head:</div><div>* The closure's caller can't call the closure more than once. Or if it does, it needs to participate in the control flow system somehow. (Example: what does `break` do in the middle of map().)</div><div>* Return values are complicated. You might need to limit the system to void returning closures only.</div><div>* Defining the closure in one place and handing it off in another is complicated. You might need to limit the system to closure literals only.</div><div><br class=""></div><div><br class=""></div><div>-- </div><div>Greg Parker <a href="mailto:gparker@apple.com" class="">gparker@apple.com</a> Runtime Wrangler</div><div><br class=""></div><div><br class=""></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=1MXK54sosN3xru3iYcLt0oBZ2w20i49gyogXctgrspdS-2F2eTMKXUhAqIVrJF5sATsLFuXfhFD1gv2KJzl5w8K5BR9EaQI4UKZ25tXlCreAJ0L5emrq7Kza4k3owTNvfr4DCxcd3QpX-2FwaCCV36k4b6WemzVibFwog-2BWEPzWMA7RssHLZeaqX3aVn3ihDaEV6U6MwQPkfxDIDeX5oqiyT3sWIaW4OOebkaLioYrR8ryo-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;">
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>