Revisiting 0004, 0007 etc. - Swift deprecations


(John Heerema) #1

Thanks to all those who thoughtfully responded to this post! The folks who responded provided kind thoughts and advice.

Ross O’Brian asked if I was familiar with the original discussion for 0004 and 0007.

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.

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.

Let’s take proposal 0004 – to deprecate the ++ and — operators.

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.

On the human side, what do the human being who write code actually do?
Human beings notoriously do not act in the way we think they “should”.

Lots of languages, like C, C++, C#, Objective C, Java, etc., already have both the prefix and suffix versions of ++ and --.
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:
a = a + 1
a += 1, or
a++

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.

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?

So, why would we deprecate the option that developers overwhelmingly choose to use?
Is it “for their own good”? Let’s remember that most people resent being told to do something “for their own good”.

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.

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.

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.

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.

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?

The answer to that question affects the question of C-style For loops too, I suspect.

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.

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.

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?

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”.

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?

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?

Thanks,
Dr. J. Heerema


(David Waite) #2

<snip most of mail>

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?

0004 and 0007 were approved, implemented, and now with Swift 2.2 have been shipped as deprecation warnings, and will no longer be valid syntax in 3.0. That ship has sailed.

You will likely have far better results both engaging in discussion and possibly evoking change if your argument approached new reasons why it would be worth *adding* these syntaxes to the swift language as if they had never existed.

I admit this is a hard argument to make. For instance,I did not recognize any points in the email I’m replying to that had not already come up in the previous discussion while 0004 and 0007 were being reviewed. I would expect that a proposal to add either one of these features would almost certainly fail without genuinely new arguments backing them. However, I also suspect that it would be an equal barrier to add either of these had Swift never had them - at least, that would be the measure by which I would evaluate said proposal(s).

It is not often that features are removed from programming languages after their 1.0 release, and these two features were modeled after mechanisms people are accustomed to in other languages. Your voice has been heard by sympathetic ears. But neither of those points alone would form the basis of a proposal for their inclusion in a future swift release.

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?

As you deferred in providing statistics:

With regards to reviewing code for usage, pre/post increment/decrement operators were found by reviewers to be almost entirely used within the per-loop statement of the C-style for loop.

With regards to reviewing code for ease of migration, most C-style for loops were found to be easily refactorable into the for…in syntax, usually with favorable increases to readability. More complex examples covered contrary include navigation of items containing a linked list, traversing a range in reverse or by a stride, and mutating the index within the body of the loop.

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?

I do not believe that not having pre/post increment/decrement operators or C-style for loops makes something a ‘niche language’. Ruby for instance has neither.

Swift also has the benefit of built-in access to C/C++ and in some environments Objective-C code and libraries. This means it does not have to strive to either replace or to have universal coverage of features in these languages.

For example, I cite pointers in Swift: while UnsafePointer exists, one would be hard-pressed to choose to use it for code involving significant pointer manipulation over the equivalent C code - the C code is much more terse, and in the domain of unsafe pointer juggling the C that terseness actually can make the code more understandable. We have the benefit of letting C be good at what C was made for, and having that C code talk to Swift. The language doesn't need “Pure Swift” in the way a cross-platform distribution language like Java needs “Pure Java”.

-DW

···

On Apr 3, 2016, at 1:25 PM, John Heerema via swift-evolution <swift-evolution@swift.org> wrote:


(Charles Srstka) #3

Keep in mind that this is only (fully) true on Apple platforms; it’s my understanding that the open-source version of Swift does not include the Objective-C bridge, with its bridging headers and all that jazz. Therefore, interop with C code is probably limited to calling things from libraries.

Charles

···

On Apr 3, 2016, at 8:51 PM, David Waite via swift-evolution <swift-evolution@swift.org> wrote:

Swift also has the benefit of built-in access to C/C++ and in some environments Objective-C code and libraries. This means it does not have to strive to either replace or to have universal coverage of features in these languages.

For example, I cite pointers in Swift: while UnsafePointer exists, one would be hard-pressed to choose to use it for code involving significant pointer manipulation over the equivalent C code - the C code is much more terse, and in the domain of unsafe pointer juggling the C that terseness actually can make the code more understandable. We have the benefit of letting C be good at what C was made for, and having that C code talk to Swift. The language doesn't need “Pure Swift” in the way a cross-platform distribution language like Java needs “Pure Java”.