[swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

[Ted F.A. van Gaalen]

Grüezi wohl Taras

you wrote:

> I find it quite irritating that you keep repeating these untrue facts. Again: both for loops compile to exactly the same code. 


Alas, I don’t understand you irritation, 
but it is your irritation, not mine.

Please note again, that “for ... in …”  always has 
some sort of collection type as its argument..
At run time, the content of a collection 
is in most cases unpredictable.
Ergo: this implies that in these cases,
the compiler cannot optimize the collection 
part of the “for … in …” statement out of the way. 
In an attempt to overcome this restriction, 
it would need to analyze all entities that have 
influenced the content of the collection, 
which is virtually impossible.
     
I do not understand your aversion against 
the for loop I brought forward, as it does not 
conflict at all with the “for ... in …” construct 
and probably also does not stand in the way 
of possible future extensions that could be 
added to the "for in..” construct. 

E.g. For similar reasons one could be irritated by 
the brave attempts of some of us to supply 
most peculiar variants of “Strides", seemingly,
at least as seen from my limited perspective,
to compensate the loss of the classical for-loop’s
facilities...  
In spite of all this being very fascinating and 
creative, to me, this effort is comparable with
trying to climb the Eiffel tower, equipped
with boxing gloves and diving fins.
it could irritate me.. However it does not,
for the mere reason that I do not fully 
understand their motives and logical grounds...
Nevertheless, they might -or might not- 
have good reasons to do so, as we no 
doubt will find out sooner or later...
In any case, this does affect the collection-based
“for … in …” only, and has no impact on the 
“for v from v1 to v2 by vstep” 
that I am proposing. 



> Collection-based for loop can express exactly the same semantics, so why do you need a new construct when you already have a perfectly good one to do the job? 


For the simple reason that there are no collections involved: 
I have very clearly described and motivated it. 
Please read it again, thank you.

By the way, it is not a new construct as it has been
existing for decades.

I took the liberty to read about you on the internet. Interesting.

I’ve read that you have a degree in linguistics, 
which makes me assume that of all people, 
you’d understand that in most languages 
there are many different ways to express something,
and that the way to express or say something 
is mostly determined by contextual aspects... 
So in the light of this very specific knowledge
that you have, I fail to understand what your
objections are against the presence of 
two slightly different for-loop variants
that can co-exist easily and are effective,
each in its own different context?  

Last but not least, you might find this interesting:
(although I am almost sure you have read it before)

http://blog.oxforddictionaries.com/2014/09/george-orwell-newspeak/

and then most particularly in this text: 

“Newspeak goals and real-world ramifications”

I cannot completely clear myself from the association
of this with the removal of certain Swift language 
elements..


Met vriendelijke groeten.
TedvG


 

> On 31.03.2016, at 10:11, Taras Zakharko <taras.zakharko at googlemail.com> wrote:
> 
> 
>> On 30 Mar 2016, at 22:05, Ted F.A. van Gaalen via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Again I need to emphasize very strongly that this for-loop really 
>> has absolutely 
>>      nothing, nada, zilch, niente, nichts, niets, niks, rien, zero, nenio,
>> to do with the: 
>> 
>> for i in stride(…. 
>> 
>> or any other for in… variant working with collections.
> 
> Of course it does. Collection-based for loop can express exactly the same semantics, so why do you need a new construct when you already have a perfectly good one to do the job? 
> 

>> 
>> but, once again - 
>> provided you don’t want to do other operations
>> on the generated collection before iterating -  
>> a collection is used here totally unnecessary, 
>> which puts a burden on performance because the contents 
>> of a collection are unpredictable 
> 
> I find it quite irritating that you keep repeating these untrue facts. Again: both for loops compile to exactly the same code. 
> 
>> It is also tedious to write and (as a matter of my personal taste) downright ugly.
> 
> Right, because 
> 
>  for d in stride(from:10, to: 5, by: 0-.1, tolerance: 0.01) 
> 
> is that much more tedious to write than what you propose
> 
> Best, 
> 
>  Taras
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160331/f2525c8a/attachment.html>