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 > <[email protected]> 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 >> <[email protected]> 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
