<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hello John</div><div class="">I subscribe completely to this point(s) of view!</div><div class="">TedvG</div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><blockquote type="cite" class="">Date: Sun, 3 Apr 2016 19:25:09 +0000<br class="">From: John Heerema <<a href="mailto:jheerema@ucalgary.ca" class="">jheerema@ucalgary.ca</a>><br class="">To: "<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>" <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>><br class="">Subject: Re: [swift-evolution] Revisiting 0004,<span class="Apple-tab-span" style="white-space: pre;"> </span>0007 etc. - Swift<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>deprecations<br class="">Message-ID: <D326CA33.B1738%<a href="mailto:jheerema@ucalgary.ca" class="">jheerema@ucalgary.ca</a>><br class="">Content-Type: text/plain; charset="windows-1252"<br class=""><br class="">Thanks to all those who thoughtfully responded to this post! The folks who responded provided kind thoughts and advice.<br class=""><br class="">Ross O’Brian asked if I was familiar with the original discussion for 0004 and 0007.<br class=""><br class="">To answer: Yes, I read the discussions several times over a period of a few weeks before writing anything myself. Unless the repo is somehow missing an awful lot of discussion, I would say that both of these proposals received startlingly little discussion at the time. These are very early proposals (numbers 4 and 7), and were conducted before a lot of people (including me) had any idea that feedback was being solicited.<br class=""><br class="">My thoughts on these deprecations are aimed more at the human side of how developers actually behave, than on the strict “desirability" of the deprecated features.<br class=""><br class="">Let’s take proposal 0004 – to deprecate the ++ and — operators.<br class=""><br class="">A few years ago, I’ve have chimed in to say “sure, let’s deprecate those things. += is more general and obvious”. But that’s how those of us who think about orthogonality think.<br class=""><br class="">On the human side, what do the human being who write code actually do?<br class="">Human beings notoriously do not act in the way we think they “should”.<br class=""><br class="">Lots of languages, like C, C++, C#, Objective C, Java, etc., already have both the prefix and suffix versions of ++ and --.<br class="">All of those language also allow developers to use += 1. So, each and every one of the millions of people who use those languages already have a choice of using any of:<br class="">a = a + 1<br class="">a += 1, or<br class="">a++<br class=""><br class="">So an enormous social experiment has already been done, and we can benefit from it, if we are willing. Given that millions of people have already been given the choice of using any of the three forms shown above, what do they actually prefer to use? There are many, many millions of lines of extant code that can be parsed to determine what developers actually use when they are given the choice.<br class=""><br class="">I’m pretty sure that everyone on this list already knows the answer, and it’s not the choice we might think that all those millions of developers “should” have made. Given a free choice, developers overwhelmingly chose to use ++ and —. They predominately use the suffix version, but the prefix version is also common. If you don’t believe me, it’s easy to find out for yourself. Actually, I would encourage you not to believe me. Please conduct your own experiment if you have access to a significant body of code. At a more personal level, did you have to refactor your own code to eliminate them? Of course it's easy to do, but why didn’t you make the “right” choice in the first place?<br class=""><br class="">So, why would we deprecate the option that developers overwhelmingly choose to use?<br class="">Is it “for their own good”? Let’s remember that most people resent being told to do something “for their own good”.<br class=""><br class="">There’s something inside most people’s brains that wants to make other people do something “for their own good”. I’d argue that this applies in spades to language designers. We want to make Swift even better than it already is (and I think that it’s already pretty darn good). So it’s really tempting to have the compiler enforce doing the right thing.<br class=""><br class="">But we also want other developers to make a voluntary choice to use Swift, when they could just as easily stick with Objective C, C, Java, or whatever they are using right now. At least, I hope that’s what everyone on this list wants.<br class=""><br class="">Or do we want just Swift to be the cool language that those of us in the “in” club use, without necessarily wanting other people to join our exclusive little club? The answer to that question affects the discussion.<br class=""><br class="">Taras Zakharko suggests that Swift isn’t trying to appeal to everyone. Perhaps not, but I hope that it does. We are long overdue for a modern general purpose language that compiles to, and is interoperable with native code. I think that Swift is great enough to be that language.<br class=""><br class="">If we have already made a particular choice, and we’re used to defending our choice as being the right one, it’s really hard for us to even imagine that we might have made a decision that doesn’t further our eventual goal. So, what’s the goal for Swift? Is it to be the language that finally takes over from C’s popularity? Or is it to be a specialized niche language?<br class=""><br class="">The answer to that question affects the question of C-style For loops too, I suspect.<br class=""><br class="">Andrew Bennett illustrated a neat way to generate an iterator using “defer”. It’s quite nice, but I would argue that it doesn’t jump out as being the perfect solution that’s so insanely great that people will give up C so that they can use it.<br class=""><br class="">Taras Zakharko kindly pointed out that the Swift compiler implements enumerable collections as lazy iterators. I was aware of that (and the way it’s done is pretty cool), but it seems dangerous to me to assume that the compiler will always be smart enough to avoid creating large enumerable collections. I think that looping is so common that it deserves its own flexible syntax.<br class=""><br class="">Xiaodi Wu says "It seemed a little irksome at first to refactor, but that was about it”. I think it’s fair to say that the folks on this mailing list represent a more technically astute segment of the computing community. Several people have mentioned having to refactor their code. But if other options are really better, why didn’t each of us use them right away, instead of reaching for the familiar For loop?<br class=""><br class="">My thought is that it’s better to attract than to dictate. How many potential Swift users are there? I think that the answer could be “an awful lot”.<br class=""><br class="">Even if the C-style For loop doesn’t appeal to everyone, I don’t see is as being so terrible that it needs to be removed in order to mitigate its horrible effects. I don’t see the Java community clambering for it’s removal. Nor do I see C# users being advised to avoid the For loop because of it’s horrible dangers. But maybe I’m missing something. The older I get, the more I realize I don’t know. Are there horrible dangers associated with its use that I’m unaware of?<br class=""><br class="">So, I’d ask “why is it so terrible that we’re going to remove it, even though it presents an obstacle to developers coming over to Swift?” Maybe there’s a really good answer to that, but if there is, I haven’t seen it in the discussion thus far. Did I miss something really important in the 0007 discussion?<br class=""><br class="">Thanks,<br class="">Dr. J. Heerema</blockquote></body></html>