<div dir="ltr">That makes sense too. It might be a little less elegant in appearance, but I think all the expressive power is there.<div><br></div><div>Thanks for answering my questions; I&#39;m now at +0 with this proposal and look forward to seeing what other people have to say, for or again.<br><div><br></div><div>Austin</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 2, 2016 at 11:26 AM, Joe Groff <span dir="ltr">&lt;<a href="mailto:jgroff@apple.com" target="_blank">jgroff@apple.com</a>&gt;</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"><span class=""><br><div><blockquote type="cite"><div>On Feb 2, 2016, at 11:12 AM, Austin Zheng via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br><div><div style="word-wrap:break-word">Hmm...the rationale that Joe provided makes a lot of sense.<div><br></div><div>One question - is the explicit closure syntax amenable to multiple levels of currying? In particular, what are the scoping rules for the placeholders $<i>n </i>- are they limited to the immediate closure within which they appear, or can they be used within further-nested closures?</div></div></div></blockquote><br></div></span><div>Currently, they&#39;re always scoped to the immediate closure, so you need to use explicit named parameters if you want to nest closures.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-Joe</div><br></font></span></div></blockquote></div><br></div>