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

[Xiaodi Wu]

On Tue, Jun 6, 2017 at 12:17 PM, Dave Abrahams via swift-evolution <
swift-evolution at swift.org> wrote:

>
> > 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.
>

Fair point.


> I'd rather not do this with extra syntax, myself.


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.


> 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.
>

Right, and migrating those cases *could* reveal and resolve unintentional
errors too.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170606/8033ec21/attachment.html>