[swift-evolution] Rekindling: "Extending declaration scope to condition for `repeat { } while ()"

[Dave Abrahams]

> On Tue, Jun 6, 2017 at 4:05 AM, Michael Savich via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> It recently occurred to me how nice it would be to be if we could avoid
>> declaring variables outside of loops that are only used inside them. I used
>> google’s site specific search (is that the canon way to search swift-evo?)
>> and only found one thread about this, (https://lists.swift.org/
>> pipermail/swift-evolution/Week-of-Mon-20160718/024657.html) where from
>> what I could see it got a positive reception.

IMO this is a language design bug of the sort that makes itself
glaringly obvious after only a few uses of the feature in question.  It
frustrates me that we haven't fixed it yet.

on Tue Jun 06 2017, Xiaodi Wu <swift-evolution at swift.org> wrote:

> If I recall correctly, it was discussed during a time when additive
> proposals were not in scope, so it could not be proposed. Since at the
> moment we are currently between Swift 4 and Swift 5 evolution, the topic is
> not in scope either.
>
> With respect to the idea itself, Taras's post--which appears to be the last
> on the subject--is useful to re-consider here:
>
>> This is definitively something very useful but it also introduces a
>> strong asymmetry into Swift statements. In all control-flow statements, the
>> condition is part of the outer scope. Or, to be more precise, its part of
>> an intermediate scope between the outer and the inner scope (as you can
>> declare variables in the condition which are invisible to the outer scope
>> but visible to the inner scope). Your suggestion essentially moves the
>> condition of repeat {} while () to the inner scope. I think that the more
>> complex semantics is not worth the change.

I find that argument unconvincing, personally.  Even if the condition in

  while condition {...} 

was “part of the inner scope,” it would be a distinction without a
difference, because you can't refer to a local variable before its
declaration, and the declaration of anything in the inner scope must
follow the condition.


>> 
>
> I recall being initially in favor of the idea myself. However, any sort of
> change of syntax is a big deal; it will prompt a lot of bikeshedding, and
> it will require engineering effort to implement that is sorely needed
> elsewhere. With time, I question whether this idea meets the necessarily
> high bar for changing syntax; indeed if the motivation is to keep something
> from the outer scope, it's trivial to make this happen with an outer `do`:
>
> ```
> do {
>   var i = 0
>   repeat {
>     // ...
>   } while i < 42
> }
> ```

Don't you gag a little every time you have to add levels of nesting,
initialize variables twice, or separate declarations from
initializations as a workaround?  I do.

I'd rather not do this with extra syntax, myself.  The change in
semantics in the rare case where a variable is shadowed inside a loop
body *and* used in a trailing condition can be handled with warnings and
migration.

-- 
-Dave