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:
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 <gor@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 <panajev@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