<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="">Just to add my thoughts, as I like the idea of adding the variables to the start somehow, but was wondering if might make sense to have a keyword such as "using", but allow it on all block statements, like-so:</div><div class=""><br class=""></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>// Original use-case of repeat … while</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>repeat using (var i = 0) {</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>// Do something</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>} while (i < 20)</font></div><div class=""><font face="Monaco" class=""><br class=""></font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>// for … in demonstrating combination of using and where</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>for eachItem in theItems using (var i = 0) where (i < 20) {</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>// Do something either until theItems run out or i reaches 20</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</font></div><div class=""><font face="Monaco" class=""><br class=""></font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>// Standard while loop</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>while let eachItem = it.next() using (var i = 0) where (i < 20) {</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>// As above, but with an iterator and a while loop and conditional binding to also stop on nil</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</font></div><div class=""><font face="Monaco" class=""><br class=""></font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>// Closure with its own captured variable</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>let myClosure:(Int) -> Int = using (var i = 0) { i += 1; return i * $0 }</font></div><div class=""><font face="Monaco" class=""><br class=""></font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>// If statements as well</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>if somethingIsTrue() using (var i = 0) where (i < 20) {</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>// Do something</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</font></div><div class=""><font face="Monaco" class=""><br class=""></font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>// Or even a do block; while it does nothing functionally new, I quite like it aesthetically</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>do using (var i = 0) {</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>// Do something</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</font></div><div class=""><br class=""></div><div class="">Unifying principle here is that anything created in the using clause belongs to the loop, conditional branch etc. only, but exists outside the block itself (thus persisting in the case of loops and closures). I quite like the possible interaction with where clauses here as a means to avoid simple inner conditionals as well.</div><div class=""><br class=""></div><div class="">Basically the two clauses can work nicely together to avoid some common inner and outer boilerplate, as well as reducing pollution from throwaway variables.</div><div class=""><br class=""></div><div class="">Only one I'm a bit iffy on is the closure; I'm trying to avoid declaring the captured variable externally, but I'm not convinced that having using on its own is clear enough?</div><div class=""><br class=""></div><div class="">Anyway, just an idea!</div><br class=""><div><blockquote type="cite" class=""><div class="">On 6 Jun 2017, at 18:45, Xiaodi Wu 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" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">On Tue, Jun 6, 2017 at 12:17 PM, Dave Abrahams via swift-evolution<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><span class=""><br class="">> On Tue, Jun 6, 2017 at 4:05 AM, Michael Savich via swift-evolution <<br class="">><span class="Apple-converted-space"> </span><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class="">><br class="">>> It recently occurred to me how nice it would be to be if we could avoid<br class="">>> declaring variables outside of loops that are only used inside them. I used<br class="">>> google’s site specific search (is that the canon way to search swift-evo?)<br class="">>> and only found one thread about this, (<a href="https://lists.swift.org/" rel="noreferrer" target="_blank" class="">https://lists.swift.org/</a><br class="">>> pipermail/swift-evolution/<wbr class="">Week-of-Mon-20160718/024657.<wbr class="">html) where from<br class="">>> what I could see it got a positive reception.<br class=""><br class=""></span>IMO this is a language design bug of the sort that makes itself<br class="">glaringly obvious after only a few uses of the feature in question. It<br class="">frustrates me that we haven't fixed it yet.<br class=""><span class=""><br class="">on Tue Jun 06 2017, Xiaodi Wu <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">> If I recall correctly, it was discussed during a time when additive<br class="">> proposals were not in scope, so it could not be proposed. Since at the<br class="">> moment we are currently between Swift 4 and Swift 5 evolution, the topic is<br class="">> not in scope either.<br class="">><br class="">> With respect to the idea itself, Taras's post--which appears to be the last<br class="">> on the subject--is useful to re-consider here:<br class="">><br class="">>> This is definitively something very useful but it also introduces a<br class="">>> strong asymmetry into Swift statements. In all control-flow statements, the<br class="">>> condition is part of the outer scope. Or, to be more precise, its part of<br class="">>> an intermediate scope between the outer and the inner scope (as you can<br class="">>> declare variables in the condition which are invisible to the outer scope<br class="">>> but visible to the inner scope). Your suggestion essentially moves the<br class="">>> condition of repeat {} while () to the inner scope. I think that the more<br class="">>> complex semantics is not worth the change.<br class=""><br class=""></span>I find that argument unconvincing, personally. Even if the condition in<br class=""><br class=""> <span class="Apple-converted-space"> </span>while condition {...}<br class=""><br class="">was “part of the inner scope,” it would be a distinction without a<br class="">difference, because you can't refer to a local variable before its<br class="">declaration, and the declaration of anything in the inner scope must<br class="">follow the condition.<br class=""><span class=""><br class=""><br class="">>><br class="">><br class="">> I recall being initially in favor of the idea myself. However, any sort of<br class="">> change of syntax is a big deal; it will prompt a lot of bikeshedding, and<br class="">> it will require engineering effort to implement that is sorely needed<br class="">> elsewhere. With time, I question whether this idea meets the necessarily<br class="">> high bar for changing syntax; indeed if the motivation is to keep something<br class="">> from the outer scope, it's trivial to make this happen with an outer `do`:<br class="">><br class="">> ```<br class="">> do {<br class="">> var i = 0<br class="">> repeat {<br class="">> // ...<br class="">> } while i < 42<br class="">> }<br class="">> ```<br class=""><br class=""></span>Don't you gag a little every time you have to add levels of nesting,<br class="">initialize variables twice, or separate declarations from<br class="">initializations as a workaround? I do.<br class=""></blockquote><div class=""> </div><div class="">Fair point.</div><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;">I'd rather not do this with extra syntax, myself.</blockquote><div class=""><br class=""></div><div class="">Right. My personal opinion today is really that if it's something that requires bikeshedding or extensive engineering, I'd rather not insist on it. But if it's something that can just happen, it's a nice-to-have.</div><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;">The change in<br class="">semantics in the rare case where a variable is shadowed inside a loop<br class="">body *and* used in a trailing condition can be handled with warnings and<br class="">migration.<span class="HOEnZb"><font color="#888888" class=""><br class=""></font></span></blockquote><div class=""><br class=""></div><div class="">Right, and migrating those cases *could* reveal and resolve unintentional errors too.</div><div class=""><br class=""></div><div class=""><br class=""></div></div></div></div><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">_______________________________________________</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">swift-evolution mailing list</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="mailto:swift-evolution@swift.org" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">swift-evolution@swift.org</a><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div><br class=""></body></html>