<div dir="ltr">On Tue, Jun 6, 2017 at 12:17 PM, Dave Abrahams via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Tue, Jun 6, 2017 at 4:05 AM, Michael Savich via swift-evolution <<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
>> It recently occurred to me how nice it would be to be if we could avoid<br>
>> declaring variables outside of loops that are only used inside them. I used<br>
>> google’s site specific search (is that the canon way to search swift-evo?)<br>
>> and only found one thread about this, (<a href="https://lists.swift.org/" rel="noreferrer" target="_blank">https://lists.swift.org/</a><br>
>> pipermail/swift-evolution/<wbr>Week-of-Mon-20160718/024657.<wbr>html) where from<br>
>> what I could see it got a positive reception.<br>
<br>
</span>IMO this is a language design bug of the sort that makes itself<br>
glaringly obvious after only a few uses of the feature in question. It<br>
frustrates me that we haven't fixed it yet.<br>
<span class=""><br>
on Tue Jun 06 2017, Xiaodi Wu <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
<br>
> If I recall correctly, it was discussed during a time when additive<br>
> proposals were not in scope, so it could not be proposed. Since at the<br>
> moment we are currently between Swift 4 and Swift 5 evolution, the topic is<br>
> not in scope either.<br>
><br>
> With respect to the idea itself, Taras's post--which appears to be the last<br>
> on the subject--is useful to re-consider here:<br>
><br>
>> This is definitively something very useful but it also introduces a<br>
>> strong asymmetry into Swift statements. In all control-flow statements, the<br>
>> condition is part of the outer scope. Or, to be more precise, its part of<br>
>> an intermediate scope between the outer and the inner scope (as you can<br>
>> declare variables in the condition which are invisible to the outer scope<br>
>> but visible to the inner scope). Your suggestion essentially moves the<br>
>> condition of repeat {} while () to the inner scope. I think that the more<br>
>> complex semantics is not worth the change.<br>
<br>
</span>I find that argument unconvincing, personally. Even if the condition in<br>
<br>
while condition {...}<br>
<br>
was “part of the inner scope,” it would be a distinction without a<br>
difference, because you can't refer to a local variable before its<br>
declaration, and the declaration of anything in the inner scope must<br>
follow the condition.<br>
<span class=""><br>
<br>
>><br>
><br>
> I recall being initially in favor of the idea myself. However, any sort of<br>
> change of syntax is a big deal; it will prompt a lot of bikeshedding, and<br>
> it will require engineering effort to implement that is sorely needed<br>
> elsewhere. With time, I question whether this idea meets the necessarily<br>
> high bar for changing syntax; indeed if the motivation is to keep something<br>
> from the outer scope, it's trivial to make this happen with an outer `do`:<br>
><br>
> ```<br>
> do {<br>
> var i = 0<br>
> repeat {<br>
> // ...<br>
> } while i < 42<br>
> }<br>
> ```<br>
<br>
</span>Don't you gag a little every time you have to add levels of nesting,<br>
initialize variables twice, or separate declarations from<br>
initializations as a workaround? I do.<br></blockquote><div> </div><div>Fair point.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'd rather not do this with extra syntax, myself.</blockquote><div><br></div><div>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> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The change in<br>
semantics in the rare case where a variable is shadowed inside a loop<br>
body *and* used in a trailing condition can be handled with warnings and<br>
migration.<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>Right, and migrating those cases *could* reveal and resolve unintentional errors too.</div><div><br></div><div><br></div></div></div></div>