> On Tue, Jun 6, 2017 at 4:05 AM, Michael Savich via swift-evolution < > swift-evolution@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@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 _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution