Hello Chris,
Thank you, I know that and agree with you asking me
to follow the usual path in Swift-evolution, of course.
I am currently working on a proposal for a new for-loop variant:
for v from v1 to v2 [by vstep] [tolerance vtol ] // in [] is optional
here
for numerical values.
As you might have noticed I already wrote something about that > a week a go.
I don’t want the classical for-loop back per se, but simply want to bring
forward
an appropriate equivalent which fits better in the Swift environment.
I will start a new discussion for this topic as you recommend, next week.
The issue that I have with SE-0007 that it is in my opinion not professional,
for reasons I have mentioned in my conclusion at the end.
That is the main reason I brought it forward.
Kind Regards
-TedvG
> On 18.03.2016, at 22:18, Chris Lattner <[email protected]> wrote:
>
> Hi Ted,
>
> I know you are trying to be helpful here, but this proposal has already been
> accepted and implemented. Keep in mind that while the proposal itself is
> germane and important, it is the community discussion around it, and
> ultimately the core team decision that led to its removal.
>
> If you would like to see C style for loops brought back, the proper
> procedural way to do this would be to start a new discussion (which would
> lead to a formal proposal) to add them to swift. This should include clear
> and cogent arguments for why the feature is worth adding to
> swift-that-currently-does-not-have-it, rather than arguing that an accepted
> proposal has issues.
>
> -Chris
>
> On Mar 18, 2016, at 1:28 PM, Ted F.A. van Gaalen <[email protected]
> <mailto:[email protected]>> wrote:
>
>> Yes, I am back because I should not leave because I might be afraid for
>> negative reactions on what I write. I try to write and respond as civilized
>> as
>> possible and never intended as personal, unless it really is. However there
>> was one
>> person taking wat I wrote personally so I wrote back very friendly that it
>> was not.
>> No response, twice. It is not very nice to be ignored when you really make a
>> real effort
>> trying to resolve a misunderstanding. It upset me. that's why I left.
>> Needed time to recover. The problem lies by The Other One, no longer by me.
>> Ok, sorry for overreacting.
>>
>> Please ==snip== the above paragraph (and this line) when responding so that
>> it doesn't propagate through
>> Swift-evolution. It doesn't belong there after this. Thanks.
>>
>> As most colleagues (that's what I think you all are, spanning two
>> generations :o)
>> might have noticed, I am not exactly happy with the removal of the classical
>> for-loop ( for ;; ) but the damage has been done, so I will soon
>> present a proposal for a better alternative. Working on it.
>> I find this matter very important.
>>
>> I do not agree with the for-loop removal proposal authored by Erica Sadun,
>>
>> Important:
>> I would like to emphasize again that what I write is not intended
>> personally.
>>
>> Also I realize that I am a bit late on this subject, but that is because I
>> was not here back then.
>>
>> I wil go through it point by point and try to explain why IMHO I think this
>> is not a good proposal.
>> ---------------------
>>
>> Evaluating proposal SE-0007
>> Remove C-style for-loops with conditions and incrementers
>> • Proposal: • Author(s): Erica Sadun
>>
>>
>>
>> "The C-style for-loop appears to be a mechanical carry-over from C rather
>> than a genuinely Swift-specific construct."
>>
>> Could you explain to me why what, in your view, is
>> - a "genuinely Swift-specific construct” ?
>> - "not very Swift-like" ?
>> - "Swift-typical” ?
>>
>> "It is rarely used and not very Swift-like."
>>
>> This is definitely not true.
>> The classical for loop is one of the most frequently used language
>> constructs in most programming languages.
>>
>>
>> "More Swift-typical construction is already available with for-in statements
>> and stride."
>>
>> Except for collections, these are inconvenient, cumbersome and inefficient
>> "work arounds" as described later in my comments in this email.
>>
>>
>> "Removing for loops would simplify the language."
>> Removing screw drivers from a toolbox would indeed simplify the toolbox.
>> So would removing closures, classes, protocols etc. from Swift.
>> Simplification of a programming language can also have its disadvantages.
>>
>> " And starve the most common use-points for -- and ++, which are already due
>> to be eliminated from the language."
>>
>> "The value of this construct is limited and I believe its removal should be
>> seriously considered"
>>
>> There absolutely is no need to remove the for ; ; and also ++ -- from the
>> language. These can perfectly well co-exist with other language elements of
>> Swift. If you don't want to use them, that's fine, but for most people out
>> there who still want to use the for ;; and ++ -- .
>>
>>
>> "Swift design supported a shallow learning curve using familiar constants
>> and control structures.
>> The for-loop mimics C and limits the effort needed to master this control
>> flow."
>>
>> Yes indeed. It mimics C and also the for-loop or its equivalent in more that
>> 20 other programming languages.
>>
>>
>> "Disadvantages of For Loops
>> 1 Both for-in and stride provide equivalent behavior using
>> Swift-coherent approaches without being tied to legacy terminology”
>>
>> Most language elements in Swift ARE legacy, and that's ok, so one does not
>> have to re-invent the wheel again.
>>
>> "2 There is a distinct expressive disadvantage in using for-loops
>> compared to for-in in succinctness"
>>
>> What makes you think so?
>>
>> "3 for-loop implementations do not lend themselves to use with
>> collections and other core Swift types.”
>>
>> Agreed if it concerns collections. However, they can. Of course, it is
>> much easier and more readable to use e.g. 'for item in items" for
>> collections.
>>
>> Please enlighten me: what "other core-Swift-types" do you refer to?
>>
>> "4 The for-loop encourages use of unary incrementors and
>> decrementors, which will be soon removed from the language."
>> Although the majority of programmers like the ++ and -- operators, I do
>> manage to understand why some do not like it. However ++ and -- are very
>> well suited for classical for-loops, in fact they even make them more
>> readable... Like so:
>>
>> 1. for i = 0; i < iterations; i++ { ...}
>> or
>> 2. for i = 0; i < iterations; i += 1 { ...}
>>
>> It looks like the first example is more readable. But yes, if it were that
>> the ++ -- would have remained in Swift, and also the classical for-loop,
>> using ++ and -- should probably restricted to be used in for-loops only.
>>
>> "5 The semi-colon delimited declaration offers a steep learning
>> curve from users arriving from non C-like languages."
>>
>> IMHO, this is utter nonsense. Even from those coming from other languages as
>> C++, C, if a mere three arguments separated by two semicolons are "a steep
>> learning curve" ? Then what to think about using closures, lambda's,
>> classes, inheritance, functional programming, protocols etc. ?
>>
>> "Impact on existing code
>> A search of the Apple Swift codebase suggests this feature is rarely used."
>>
>> A search of the Apple Swift codebase is not representative, because the
>> scope of this search encompasses only source code made by users of the
>> programming language Swift, which is partly still under further development.
>> Faithfully representative would it be to search in a wider perspective,
>> which should include source code written in variety of programming languages
>> like Objective-C, Java, C#, C++, C, PHP , Ruby, Go, Perl, Javascript, Dart,
>> V. Basic, Pascal, PL/1, Cobol, Rexx. Most of this languages have
>> implemented the for-loop (or equivalent) . Undoubtedly if one would do a
>> search for for-loop in these languages it would become clear that the
>> for-loop is heavily used.
>>
>> 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...
>>
>> How do you arrive at such a conclusion? In this perspective, Erica, I am
>> very much interested to know if you have practical experience with using
>> other programming languages than Objective C and Swift. Have you built solid
>> applications with other systems, IDEs and languages? Also, did you consult
>> programmers working with other well established languages?
>>
>> "Community members of the Swift-Evolution mail list confirm that it does not
>> feature in many pro-level apps and can be worked around for those few times
>> when for-loops do pop up."
>>
>> If one browses through the App Store, one might notice that most apps work
>> with collections (e.g. customers, addresses, shopping items, videos, songs.
>> etc.) For these kind of applications, the for-in-collection statement in
>> Swift is great and well catering for these requirements. The result of this
>> is, that the majority of Swift developers will not be aware and not miss the
>> classical for-loop (or a new Swift equivalent for it at all) simply because
>> they do not need it.
>>
>> However, for those that make scientific, engineering, statistical, technical
>> and game apps, the lack of a simple but versatile iteration statement, which
>> in most cases can be compiled down to a simple and very fast assembler loop
>> is nothing less than a disaster.
>>
>> E.g. For the purpose of performance testing, in an Apple TV SceneKit app I
>> am currently building, I did replace replace the classical for-loop by a
>> "for in x.stride(..." for coordinate calculations. Performance dropped to
>> about 45%, this is unacceptable. The compiler cannot get rid of this.
>> Working with a collection based for-in will nearly always be twice as slow,
>> for the simple reason that the contents of the collection it has to process
>> are by definition unpredictable.
>>
>> In your proposal you offered the following example. I do not know where you
>> found this horrible piece of code. However, in this case it is not the
>> for-loop that is so bad, but the complete function. There are many better
>> and well structured classical for-loops to be found everywhere. I cannot
>> deflect my impression that you might have selected this particularly bad
>> example solely to amplify your proposal's case.
>> "
>> char *blk_xor(char *dst, const char *src, size_t len)
>> {
>> const char *sp = src;
>> for (char *dp = dst; sp - src < len; sp++, dp++)
>> *dp ^= *sp;
>> return dst;
>> }
>> "
>> Again, this is a extremely bad C Example, infested with (at least to me)
>> unclear pointer usage. (Luckily in Swift there are (or should be) no
>> pointers) Somewhere in this messy example, yes, a for-loop can be found.
>> Notice that the for-loop itself is relatively simple and straightforward.
>> Also, the fact that this for-loop deploys two value incrementors instead of
>> one, is in this particular context not really all that bad.
>>
>>
>> In my opinion, the Swift equivalent you offer, does not look much better:
>>
>> "
>> func blk_xor(dst: UnsafeMutablePointer<CChar>, src:
>> UnsafePointer<CChar>, len: Int) -> UnsafeMutablePointer<CChar> {
>> for i in 0..<len {
>> dst[i] ^= src[i]
>> }
>> return dst
>> }
>>
>> A search of github's Swift gists suggests the approach is used primarily by
>> those new to the language with minimal language skills and is abandoned as
>> language mastery is achieved.
>> "
>> Another subjective assumption and almost insulting for those, often with
>> years of experience, who deploy the classical for-loop intensively and
>> really knowing what they are doing.
>>
>> My conclusion:
>> Although the proposal has been accepted. I would like to see it withdrawn
>> because the arguments brought forward are highly subjective,
>> not thoroughly analyzed and in some cases even false.
>> Furthermore, a proposal should be based on facts, not assumptions.
>>
>> Kind Regards
>> TedvG.
>>
>>
>>
>>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
