I did not realize that change occurred with `do {}`! That seems like it should be a regression, given that previously there was explicitly a fix-it to rewrite naked `{}` to `do {}`. On Sat, Jun 10, 2017 at 09:06 Gor Gyolchanyan <g...@gyolchanyan.com> wrote:
> Yeah, that's why I mentioned a big **if** at the end. I love the `do { }` > construct or variable isolation purposes and logical grouping, but > unfortunately, Swift 4 has made it a lot uglier, by making it an error in > its current form: > > do { > let a = "123" > print(a) > } // error: missing `while`, also use `repeat` instead > > The workaround is to do this: > > do { > let a = "123" > print(a) > }; > > It might seem like a little change, but this really really bugs me for > some reason. I always felt like semicolons in Swift should never be > mandatory and should only be used for writing multiple statements on the > same line. > > Overall, I agree that this isn't a big enough reason to change the syntax > for. Let's just make the `do { }` great again instead. > > > On Jun 10, 2017, at 3:33 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > _Every_ addition to the basic syntax of the language is, by definition, > high cost. The bar for additions to the standard library is already very > high; the bar for additions to control flow syntax would be extraordinarily > high. > > The proposed use case here is far from the original topic of repeat {} > while, which is unique because the condition lexically follows the loop. > > For those loops in Swift where it is possible to declare variables in the > condition, these live in a magical middle scope that is intuitive to use > but also an exception to the rule of thumb that scopes are surrounded by > braces. As I wrote earlier, it is possible to manually create an analogous > scope by surrounding any loop with do {}. Any addition to the language > would have to be vastly superior to this currently possible alternative, > and I seriously doubt it is possible to invent such a thing because > anything shorter than the four letters in “do {}” would also obscure the > existence of the middle scope being created. > > > On Sat, Jun 10, 2017 at 08:05 Goffredo Marocchi via swift-evolution < > swift-evolution@swift.org> wrote: > >> If it is low cost and people do not come up with regressions/high cost + >> negative impact scenarios then I would say go full steam ahead. It does >> address an annoying scenario. >> >> Sent from my iPhone >> >> On 10 Jun 2017, at 12:04, Gor Gyolchanyan <g...@gyolchanyan.com> wrote: >> >> Not much, I think. The `where` clause already exists, conditional `let` >> and `var` binding already exists. It'd take loosening up conditional >> binding rules a bit and expanding the lexical structure to include `let` >> and `var` bindings in `repeat`. >> >> On Jun 10, 2017, at 2:01 PM, Goffredo Marocchi <pana...@gmail.com> wrote: >> >> Quite interesting :), what impact would it have on the compiler? >> >> Sent from my iPhone >> >> On 10 Jun 2017, at 11:46, Gor Gyolchanyan via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> I think a better way of achieving this would be to use the already >> existing `where` keyword in loops. The way it works right now is as follows: >> >> let many = [1, 2, 3, 4, 5] >> for each in many where each % 2 == 0 { >> print("found an even number: \(each)") >> } >> >> Unfortunately, unlike all other conditional scopes, `where` does not >> allow `let` and `var` bindings in it, so I'd suggest we add ability to do >> that: >> >> let many: [Int?] = [1, 2, nil, 3, 4, nil, 5] >> for each in many where let number = each { >> print("found a non-nil number: \(number)") >> } >> >> Or, more interestingly: >> >> for each in many where let number = each, number % 2 == 0 { >> print("found a non-nil even number: \(number)") >> } >> >> And in case of a while loop: >> >> var optional: Int? = 1 >> while let nonoptional = optional { >> if nonoptional >= 10 { >> optional = nil >> } >> optional = nonoptional + 1 >> } >> >> But this is only for optional unpacking, so another addition would be to >> allow any `let` and `var` bindings in conditional scopes without them >> contributing to the condition itself: >> >> while let a = 0, a < 10 { >> a += 1 >> print(a) >> } >> >> And finally, allow these bindings in `repeat`: >> >> repeat let a = 0 { >> a += 1 >> print(0) >> } while a < 10 >> >> I think **if** the core team would consider this a worthwhile addition, >> this would be a less invasive and more intuitive way of achieving what you >> want. >> >> On Jun 10, 2017, at 1:31 PM, Haravikk via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> Not sure if my e-mail didn't go through or if discussion just fizzled >> out; one other benefit if we ever move to a proper message board is we >> might gain the ability to bump topics. Anyway, I'll resend my message just >> in case: >> >> >> >> 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: >> >> // Original use-case of repeat … while >> repeat using (var i = 0) { >> // Do something >> } while (i < 20) >> >> // for … in demonstrating combination of using and where >> for eachItem in theItems using (var i = 0) where (i < 20) { >> // Do something either until theItems run out or i reaches 20 >> } >> >> // Standard while loop >> while let eachItem = it.next() using (var i = 0) where (i < 20) { >> // As above, but with an iterator and a while loop and conditional >> binding to also stop on nil >> } >> >> // Closure with its own captured variable >> let myClosure:(Int) -> Int = using (var i = 0) { i += 1; return i * $0 } >> >> // If statements as well >> if somethingIsTrue() using (var i = 0) where (i < 20) { >> // Do something >> } >> >> // Or even a do block; while it does nothing functionally new, I quite >> like it aesthetically >> do using (var i = 0) { >> // Do something >> } >> >> 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. >> >> Basically the two clauses can work nicely together to avoid some common >> inner and outer boilerplate, as well as reducing pollution from throwaway >> variables. >> >> 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? >> >> Anyway, just an idea! >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution