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

[T.J. Usiyan]

Please… *please* let this lie.

I understand that it will likely cause some specific cases to become more
difficult but, on balance, it was a simplifying change. The syntax that we
do have is clearer to those unfamiliar with programming idioms from other
languages and people *are* familiar with other programming languages have
the tools to construct whatever functionality they feel is missing from the
provided tools.

TJ

On Fri, Mar 18, 2016 at 5:19 PM, Ted F.A. van Gaalen via swift-evolution <
swift-evolution at swift.org> 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...
>
> 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
>
>
>
>
>
> On 18.03.2016, at 22:04, Patrick Gili <gili.patrick.r at gili-labs.com>
> wrote:
>
> Hi Ted,
>
> I don't think many of us that are active on this mailing list had the
> opportunity to provide feedback on this proposal review. I very much agree
> with you on many points that you bring up below. I have spent a lot of time
> scratching my head wondering why it was so important to remove certain
> syntax from Swift, such as C-style loops, unary increment, and unary
> decrement. Leaving them there increases compatibility of C code with Swift,
> and leaving them there keeps them opt-in. If you don't want to use it, you
> don't have to. However, the changes definitely force developers to use
> newer syntax, which runs contrary to the "opt-in philosophy" that the core
> team has impressed on the community.
>
> I'm going to play devil's advocate though. Will the tools for Swift 3
> automatically make the necessary changes to source to comply with the new
> syntax? If so, is it so bad? I've been using the C language and all of its
> variants for more than 32 years. Hence, it is easier on my eyes and brain
> if there is some compatibility there. Personally, I think leaving this
> syntax in the language eases migration. Although, I've been learning so
> many new languages over the last decade that it seems to matter less with
> time. However, I can't seem for the millions of developers that write code
> for OS X and iOS.
>
> Cheers,
> -Patrick
>
> On Mar 18, 2016, at 4:28 PM, Ted F.A. van Gaalen via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160318/ff66848b/attachment.html>