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 <[email protected]> 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 <[email protected]> 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 >>> <[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
