Does this debate not arise from a common duality of purpose of the "for
(;;)" construct?
[in passing, and to acknowledge its longevity, I'll note I first saw this
"FOR .." years ago when learning FORTRAN]
--> Iterating Through the Members of a Collection .. Erica's proposal hits
this first usage nicely because, typically, the 'index' value is irrelevant
so why force its existence? I think everyone is happy that the old
construct is exorcised for this case.
--> Generating Values of a Variable Local to the Loop .. or the
"scientific, engineering, statistical, technical" use that Ted refers to.
In this case the "for (;;)" loop's purpose *is* the generation of the
'index' value, and the old construct does this more nicely than the new
[though I'll moderate my enthusiasm in a moment].
When you consider the total power of the "for (;;)" usage, several awesome,
and ghastly, things emerge. You'll think of more, but I think of using a
non-integer index; I think of compound statements before, after and between
the semi-colons; I think of the central conditional and the number of times
that I have fallen prey to an off-by-one error; I think of the final
'iteration' as being an arbitrary computation.
A simple example might be: for (altitude = 0.1; altitude < 10e6; altitude
=* 10.0) { . . . }
The two purposes I'm drawing out are not mutually exclusive, of course.
They're more like the ends of continuum of purposes, and each end can be
implemented (torturously?) by the others end's syntax. We've focused
attention on one end in SE-0007; now we need to do the same for the other
end. I look forward to Ted's suggestion for an elegant expression of
the "scientific,
engineering, statistical, technical" usage.
Finally, I'll note that when SE-0007 was being considered, I asked how I
might do the second case (I needed to span Doubles from X to Y in jumps of
Z. The best answer (of several), at that time, was:
extension ClosedInterval where Bound: Strideable {
func by(n: Bound.Stride) -> StrideThrough {
return start.stride(through: end, by: n)
}
}
and
for angle in (X...Y).by(Z) { . . }
We can do better.
On Sat, Mar 19, 2016 at 2:58 PM, Patrick Gili via swift-evolution <
swift-evolution@swift.org> wrote:
> I understand this. I am looking forward to see what Ted proposes.
>
> -Patrick
>
> On Mar 19, 2016, at 2:31 PM, Ross O'Brien
> wrote:
>
> But the discussion is no longer about 'do we really need to take this
> feature out?'. The feature is already out. It's deprecated in Swift 2.2.
> The discussion is 'is there a compelling reason to put it back in again?'.
>
> We still have for-in loops. We still have repeat while. We still have
> forEach. Iteration isn't going anywhere; it just doesn't have this peculiar
> semi-colon structure any more. It's a confusing structure for beginning
> programmers to learn in the first place, and Swift doesn't use semi-colons
> so much.
>
> On Sat, Mar 19, 2016 at 6:06 PM, Patrick Gili via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> On Mar 18, 2016, at 7:19 PM, Ted F.A. van Gaalen
>> wrote:
>>
>> On Chris’s advice, I’ve spawned this into a new discussion topic, for
>> which the base could be
>> part of what I wrote in relation to SE-0007.
>>
>>
>> Hello Patrick
>> as I wrote:
>>
>> As a result of removing the classical for loop it is to be expected that
>> lot of people might consider thinking twice about switching to Swift, If
>> they have to live without (or cumbersome work around) language elements
>> that have proven to be very useful for at least a few decades...
>>
>>
>> There are two groups of people to consider:
>>
>> 1) OS X and iOS developers; this group is stuck with whatever the
>> language brings them, for good or bad. If this group of people doesn't like
>> a decision made by the community, they can grumble about it for awhile,
>> suck in a deep breath, and move on.
>>
>> 2) Others; this group may be considering using Swift to develop software
>> on other platforms and in other environments. If this group of people
>> doesn't like a decision made by the community, they may think twice and it
>> could significantly impact the uptake by this group of developers. I think
>> it is wise that the community lubricate the transition to Swift as much as
>> possible for this group of developers. I ask if leaving this kind of syntax
>> in the language is so bad? Does it fall in the same category as removing
>> function currying? My gut tells me not, but I could be wrong.
>>
>>
>> I also find it of the most importance to keep Swift accessible for all
>> kinds of programmers
>> from starters to academic.
>>
>> Graig Federighi said
>> *We think it should be everywhere and used by everyone.*
>>
>>
>> I subscribe to that.
>>
>>
>> -TedvG
>>
>>
>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
