[swift-evolution] [swift-evolution-announce] [Review] Remove C-style for-loops with conditions and incrementers
David Owens II
david at owensd.io
Thu Dec 10 19:17:45 CST 2015
Review of SE-0007
* What is your evaluation of the proposal?
I am against this change. I’ve seen no consideration of the performance implications that this change brings about. Also, many of the proposed alternatives tend towards using defer as the mechanism to provide consistent increments/decrements. However, this is problematic around the boundary edges as break and throw are not mechanisms that can halt the execution of the defer statement. So unlike the c-style loop that would not perform that code, the alternatives would.
* Is the problem being addressed significant enough to warrant a change to Swift?
No; it offers no alternative solution to maintain the performance that a c-style for-loop ensures. There is no general pattern than can be used to satisfy a c-style loop’s behavior; each proposed alternative has different issues.
* Does this proposal fit well with the feel and direction of Swift?
No, it limits the language’s ability to create concise and legible code when the situation does arise for a c-style loop.
This is the alternative to create a loop that matches the same functionality, including preventing the leaking of loop-variables.
var sum = 0
for var i = 1000, j = 2000; i > 0 && j > 0; i -= 1, j -= 2 {
if i % 2 == 0 { continue }
sum += 1
}
print(sum)
// versus
var sum = 0
if true { // some arbitrary scope mechanism is needed to contain i and j
var i = 1000, j = 2000
while i > 0 && j > 0 {
defer {
i -= 1
j -= 2
}
if i % 2 == 0 { continue }
sum += 1
}
}
print(sum)
To me, that is not a fair trade-off; maybe if the defer pattern could be used at all times and the leaking of the loop-variables was considered ok. There are some ways to consolidate the code so that it takes up less visual space, but I don’t do that for other constructs, so I don’t think that is a valid thing to try and do here. Also, the use of defer in this context is a somewhat of a trick that I’m not sure is even a good pattern to promote as it can lead to boundary-case crashes.
This is unsafe code:
var sum = 0
var i: UInt = 1000
while i >= 0 {
defer {
i -= 1
}
if i == 0 {
print("zero has been reached!")
break
}
if i % 2 == 0 { continue }
sum += 1
}
The defer statement is still executed, so now I need to come up with a different pattern to handle this type of problem.
* If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
n/a
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
A few hours. I’ve read the proposal multiple times and followed the mail threads. I’ve also done some basic performance analysis (attached mail) on the problem for some of the “improved” versions of the loop construct.
-David
> On Dec 7, 2015, at 12:44 PM, Douglas Gregor <dgregor at apple.com> wrote:
>
> Hello Swift community,
>
> The review of "Remove C-style for-loops with conditions and incrementers” begins now and runs through Thursday, December 10th. The proposal is available here:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0007-remove-c-style-for-loops.md <https://github.com/apple/swift-evolution/blob/master/proposals/0007-remove-c-style-for-loops.md>
>
> Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>
> or, if you would like to keep your feedback private, directly to the review manager.
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
>
> * What is your evaluation of the proposal?
> * Is the problem being addressed significant enough to warrant a change to Swift?
> * Does this proposal fit well with the feel and direction of Swift?
> * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
> * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md <https://github.com/apple/swift-evolution/blob/master/process.md>
>
> Cheers,
> Doug Gregor
> Review Manager
>
>
> _______________________________________________
> swift-evolution-announce mailing list
> swift-evolution-announce at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151210/3d1d78c4/attachment.html>
-------------- next part --------------
An embedded message was scrubbed...
From: David Owens II via swift-evolution <swift-evolution at swift.org>
Subject: Re: [swift-evolution] [Review] SE-0007 Remove C-style for-loops
with conditions and incrementers
Date: Thu, 10 Dec 2015 15:36:52 -0800
Size: 27384
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151210/3d1d78c4/attachment.eml>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151210/3d1d78c4/attachment-0001.html>
More information about the swift-evolution
mailing list