[swift-evolution] Revisiting 0004, 0007 etc. - Swift deprecations

[David Waite]

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

<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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160403/f06a99b7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160403/f06a99b7/attachment.sig>