Slashdot Mirror


Apple Releases Swift 3.0, 'Not Source-Compatibile With Swift 2.3' (infoworld.com)

An anonymous Slashdot reader quotes InfoWorld: "Move fast and break things," the saying goes. Apple does both with the 3.0 version of its Swift programming language...its first full point revision since it became an open source project... In a blog post detailing the full body of changes for Swift 3.0, Apple singled out the two biggest breaking changes. The first is better translation of Objective-C APIs into Swift, meaning that code imported from Objective-C and translated into Swift will be more readable and Swift-like. The bad news is any code previously imported from Objective-C into Swift will not work in Swift 3; it will need to be re-imported.

The other major change... Most every item referenced in the standard library has been renamed to be less wordy. But again, this brings bad news for anyone with an existing Swift codebase: Apple says "the proposed changes are massively source-breaking for Swift code, and will require a migrator to translate Swift 2 code into Swift 3 code."

Apple will provide migration tools in version 8.0 of their XCode IDE, "but such tools go only so far," notes the article, questioning what will happen to the Linux and Windows ports of Swift.

94 of 148 comments (clear)

  1. better now by goombah99 · · Score: 5, Insightful

    than later when there's a huge code base.

    --
    Some drink at the fountain of knowledge. Others just gargle.
    1. Re:better now by hcs_$reboot · · Score: 1

      Maybe, but they had enough time until 2.3 to get things right, to ensure compatibility, at least.

      --
      Slashdot, fix the reply notifications... You won't get away with it...
    2. Re:better now by PingSpike · · Score: 1

      That's the attitude behind the last 12 different Microsoft phone platform reboots!

  2. Breathes new life into old APIs by SuperKendall · · Score: 4, Informative

    I have a pretty decent amount of Swift and the change between this version and previous versions is a lot more to absorb than it has been in the past... the migrator tool does help though it seems like it doesn't do as much as it could (that may have changed from earlier betas though).

    However, whatever brief pain this brings upon us, is more than made up by the improvements Swift3 brings to the Cocoa API...

    Have you ever worked on an Api for a long time, and thought "if I could do this again I'd rename all this stuff, and structure this one thing differently..."

    Well that's one thing Swift3 did for Cocoa - there's basically a whole new name mapping overlay for Cocoa that makes lots and lots of calls much clearer, and also extensions that offer more Swift friendly API calls in some cases.

    And the nice thing is some of the mappings are algorithmic, so your own ObjectiveC code you call from Swift benefits from name tidying or simplification, which works out well because of naming conventions Cocoa has long had and almost all Cocoa programmers follow.

    There are also specially tweaked mappings to some parts where special cases made the automatic mapping not make sense, so it's like the whole API has had an overview and some re-thought applied.

    It is sad that Swift3 could not yet bring ABI stabilization (so you could ship binaries of libraries to other developers and have them work in future Swift updates). But hey, the upside there is that people that want to ship Swift libraries have to give you source - who doesn't want that!

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
  3. One word: Courage. by PhrostyMcByte · · Score: 5, Funny

    The courage to move on, to do something new that betters all of us.

    The Swift 2.0 language is more than 12 months old. It has its last big innovation about 6 months ago. You know what that was? They deprecated prefix and postfix operations, they made it smaller. It hasn't been touched since then. It's a dinosaur. It's time to move on.

    1. Re:One word: Courage. by tgetzoya · · Score: 1

      I wish I had mod points...

    2. Re:One word: Courage. by hcs_$reboot · · Score: 2

      The courage to prepare for the right job interview "you're swift 3? sorry we're looking for 2.3 people"

      --
      Slashdot, fix the reply notifications... You won't get away with it...
    3. Re:One word: Courage. by JustBoo · · Score: 1

      > "you're swift 3? sorry we're looking for 2.3 people"

      That's paranoia. New features+Breaking language updates [bla... bla... bla.]

      You've clearly never dealt with a software companies HR department. Clearly.

    4. Re:One word: Courage. by SuperKendall · · Score: 1

      Except that in reality no-one says "Swift 2.3.45.6.7." on a resume, they say "Swift", and MAYBE it comes up in an interview which version they are currently working with... Swift 3 is not that different, it's more a matter of conversions needing to be done than people re-learning a new language.

      --
      "There is more worth loving than we have strength to love." - Brian Jay Stanley
  4. Lol by Anonymous Coward · · Score: 1

    Apple being Apple

    1. Re:Lol by bug_hunter · · Score: 3, Insightful

      And thank goodness they do that.
      Otherwise we'd be on OS 9x on PowerPC.

      --
      It's turtles all the way down.
  5. Fork You Apple! by williamyf · · Score: 1, Insightful

    If anyone is anoyed by this "Breaking of source" change, feel free to fork the hell out of the project (is open source after all).

    Me? I do not speak Swift yet, and for the looks of it, will wait until version 8 or so to start learning.

    --
    *** Suerte a todos y Feliz dia!
    1. Re:Fork You Apple! by Anonymous Coward · · Score: 1

      I do not often code, but when I do, I prefer multi-platform languages. It takes courage to use what works, instead of what the cool kid company is pushing with their headphone-less phone.

    2. Re:Fork You Apple! by Thanatiel · · Score: 1

      Why ? It will be hugely different from version 9 (or so).

      --
      Irrelevant news and morons using moderation to mod down what they disagree on. 2018 resolution: so long.
  6. welcome to python by nimbius · · Score: 4, Insightful

    where we have 5 versions, 3 syntax distinctions, and flipping through them like a rolodex while muttering "what in the name of god does this code need to run" is a time honoured tradition.

    --
    Good people go to bed earlier.
    1. Re:welcome to python by Anonymous Coward · · Score: 1

      Meanwhile, us trusting fools who hitched our wagons to Microsoft can still run C# from the .Net 1.x era (circa 2002) in the very latest runtime and not get burned as long as we didn't do something extremely outlandish with it. (Though if you have VB from the pre-.Net era, you're a fucked dinosaur.)

    2. Re:welcome to python by 93+Escort+Wagon · · Score: 1

      Yeah, I was wondering when someone would point out that swift is hardly the only language to follow this model...

      --
      #DeleteChrome
    3. Re:welcome to python by MSG · · Score: 3, Informative

      Python was initially released in January 1994, almost 23 years ago. Since then, some libraries have been deprecated, first producing warnings, and later being removed. That process gave users and developers time to update the code without completely breaking following an upgrade. Backward compatibility was reasonably well maintained until 3.0, which was released in parallel with 2.6. Python 2 is still maintained while developers port code to Python 3.

      That's a big contrast from Swift, which was initially released almost exactly 2 years ago, and made significant backward-incompatible changes without an interim version that retained compatibility. Python's not perfectly backward compatible, but it's a whole lot better than this.

    4. Re:welcome to python by h33t+l4x0r · · Score: 4, Insightful

      Python 2 is still maintained while developers port code to Python 3.

      That's one way to put it. Another way to put it would be:

      Python 2 is still maintained because developers aren't porting their code to Python 3.

      It's 9 years later, at some point Python is going to have to give up on Python 3 and move on to a Python 4 that is backwards compatible with Python 2.

    5. Re:welcome to python by Anonymous Coward · · Score: 3, Informative

      Python 2 is still maintained because the installed base of useful Python 2 code is extremely big. People are porting to 3, but it takes time.

      And the actual changes are much smaller in Python 3, here the new Swift is completely changing a lot of APIs without notice nor deprecated phase.

    6. Re:welcome to python by SuperDre · · Score: 1

      Nah, VB6 still runs perfectly on Windows 10 (and will for quite a while) (but I certainly would not recommend starting a new project in VB6)..

    7. Re:welcome to python by brantondaveperson · · Score: 1

      We have quite a large amount of code written in Python 2. It will never, ever, be ported to Python 3.

    8. Re: welcome to python by luis_a_espinal · · Score: 1

      Whereas i still use c++ code from 1990. Admittedly it uses printf rather than that fancy new std::cout...

      Well, cout has been there forever, and std:cout is almost 20 years old. I do get your point, though, printf and their ilk are eternal.

    9. Re:welcome to python by west · · Score: 1

      To me this makes it crystal clear that *now* is the only time to make significant changes lest you suffer Python's fate of essentially forking the user base.

      Making breaking changes over 22 years is a disaster. Making them over 2-3 is survivable.

    10. Re:welcome to python by ssam · · Score: 1

      If you wrote a python program any time in the past 15 (maybe longer) years that worked in the current version of the time, it will still work in a supported version today. Though you might get some deprecation warnings, and you should probably start thinking about migrating to 3.x.

    11. Re:welcome to python by spitzak · · Score: 1

      Honestly the changes in Python 3 should not be any obstacle to porting code. Most of it winds up being a find and replace. The major difference is the use of unicode, and if your package really depends heavily on strings not being unicode, you probably did it wrong. The problem is that if one package that lots of people depend on has devs that just say, "I don't wanna," everything breaks down. And more than one package has devs like that.

      At this point, if the Python community could make "porting" as simple as adding a header to a .py file, there would still be people that would refuse to do it.

      The problem with Python 3 "unicode" is not that text is not Unicode. The problem is that *random binary data* is not Unicode, but when you read data from an unknown source, you MUST assume it is "random binary data". Trusting it to follow some pattern is by far the stupidest thing you can do.

      In Python 2 you could put random binary data into a "string" and then write it to disk without any change, and no errors would be produced. Only if you tried to *display* the string would you get an exception. In Python 3 it will immediately throw an exception, at a completely useless point in your program (ie when you are reading data in, not when you are processing it). Changing every "string" to a "bytes" will "fix" it, but then you have to change the type of every single function that is called from "string" to "bytes", and so on, eventually replacing every single "string" in your program with "bytes". And you are out of luck if one of those api's is from a library that you don't control.

      Python 3 will NEVER get accepted unless you can put totally arbitrary patterns of 8-bit data into a "string" and get them back out unchanged. All exceptions must be deferred until something actually tries to split the data into Unicode code points. Even then they should be providing a more useful iterator based api that returns an object that says "the code point is this" or "there is a UTF-8 parsing error here and the first byte is this".

    12. Re:welcome to python by Carewolf · · Score: 1

      The problem is more that unicode support was so broken in python 2 that a great deal of the invested time in python2 code bases are weird magic that no one understands that makes python2 not soil itself. In theory you could could rit of all that, but no one really dare touch it.

    13. Re:welcome to python by tuffy · · Score: 1

      Unicode support in Python 2 is basically the same as in Python 3. If you want to translate from binary strings to Unicode, you're going to need to specify a codec since the language doesn't just assume everything is UTF-8. The difference is that things like paths and command-line arguments are Unicode in Python 3 but plain binary strings in Python 2, so you wind up with this third "class" of strings that might be one or the other depending on which version of the language you're using.

      But with a bit of care it's not hard to get a nontrivial amount of Python code to work unmodified in both versions by specifying import fallbacks and so on.

      --

      Ita erat quando hic adveni.

    14. Re:welcome to python by A+Big+Gnu+Thrush · · Score: 1

      Do a new install of most Linux distributions or OS X, then type python --version. It's 2.7

      If you replace the default python with 3, shit will break. Fuck python. Fuck python forever. It's been 9 years and these fycjtards can't figure this out. Fuck them.

    15. Re:welcome to python by Carewolf · · Score: 1

      In Python2 when I used it, you couldn't specify a codec, there was no such thing, it just assumed that strings would turn into UTF16 by magic, and would throw up if it didn't and certainly wouldn't allow you to do format conversions unless you said a small magic incartation and sacrificed a code monkey.

  7. The only breaking change worth having by jader3rd · · Score: 1

    The only breaking change worth having in a released language is a compilation error if a space character is surrounded by white space characters. The space character exists in writing to break up words (ie, a series of non-white space characters), and the same should be true for programming. I'd be so happy if that were made a compiler breaking change in all of the major languages. I'd push so hard to upgrade to the latest version for all of them.

    1. Re:The only breaking change worth having by dgatwood · · Score: 1

      So... what you're saying is that you want a language where indentation is illegal? Sort of the anti-Python?

      --

      Check out my sci-fi/humor trilogy at PatriotsBooks.

    2. Re:The only breaking change worth having by drinkypoo · · Score: 1

      So... what you're saying is that you want a language where indentation is illegal? Sort of the anti-Python?

      I think they're saying they want spaced indentation to be illegal, and force you to use tabs. Not sure why that would help anything.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    3. Re:The only breaking change worth having by brantondaveperson · · Score: 2

      Using whitespace to express indentation is completely retarded in any case. Editors should be smart enough to display code using whatever indentation style you prefer, and should save files with minimal whitespace inserted. Thus people get to look at their code however they prefer, and no-one ever has to worry about merging whitespace-only changes, because there would be no such thing. Quite how we've got this far, without anyone ever bothering to do this, is quite beyond me.

    4. Re:The only breaking change worth having by luis_a_espinal · · Score: 2

      Using tabs enables the viewer to view the code indentation with as much spacing as they see fit. That means on my X character wide ultra high res terminal, i can ensure that there is a noticable level of identation. People who don't get that tabs can be redefined to make formatting more legible for the person reading your code are assholes.

      Or you could say that in projects with a lot of people, it pays to force an indentation standard based on a universal number of spaces, a constant retained from revision to revision. Then when you, the generic you, do a diff in any tool, it will look exactly the same regardless of a user's editor setup.

      I'm sure there are people who will disagree and will put valid counter-arguments. I can only say that after doing this for a while and having to deal with disparate formatting of the same file in the same bloody branch (making diffs almost impossible to discern without some serious massage), then a standard spacing becomes a lifesaver.

      See, programmers are very talented, but also extremely opinionated. Sorry, most cannot do shit without having someone forcing some rules upon them. The amount of ego is just staggering, and almost everyone, when left to her devices reformats and shuffle shit on a file to fit her own needs without ever thinking "gee, I wonder if the next person who has to maintain this piece of code will be able to effectively discern logical/structural changes from formatting ones without involving file-massaging heroics.".

    5. Re:The only breaking change worth having by drinkypoo · · Score: 1

      Editors should be smart enough to display code using whatever indentation style you prefer, and should save files with minimal whitespace inserted.

      Having it happen automagically without asking would be bad. But having the feature available at a click would be great...

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    6. Re: The only breaking change worth having by Entrope · · Score: 1

      It hasn't happened because people occasionally view code using tools besides editors -- dead trees, web browsers, plain text editors, and so forth -- so it's important that code looks good even if you don't have a fancy IDE that you extensively customized to make the latest fad language look decent.

    7. Re: The only breaking change worth having by brantondaveperson · · Score: 1

      I guess you're technically correct, but even those examples of 'simple' editors are actually extremely complex pieces of technology that perform a great deal of cleverness with the underlying data before they display it on the screen. Adding another layer that automatically creates the indenting that you prefer to see, before saving away in some standard format, wouldn't prevent any of those existing things working properly.

    8. Re:The only breaking change worth having by jader3rd · · Score: 1

      So... what you're saying is that you want a language where indentation is illegal? Sort of the anti-Python?

      No, I want the character whose soul purpose is indentation, to be used for indentation (ie tabs); and the character which exists for separating non-whitespace characters to not be used for indentation (ie spaces).

    9. Re:The only breaking change worth having by jader3rd · · Score: 1

      I think they're saying they want spaced indentation to be illegal, and force you to use tabs. Not sure why that would help anything.

      When moving around lines in a file, or moving them in and out of some scope, I find that it's less annoying when dealing with tabs than compared to a file with spaces. It's easier to get the indentation correct in those cases.

  8. Embrace, Extend, Extinguish, Apple version. by sethstorm · · Score: 1

    Now Apple gets to join in on the fun of deliberately breaking things, especially non-blessed ports.

    --
    Twitter supports and protects racists - by smearing their critics with the "Hate Speech" label.
  9. Re:Garbage by lucm · · Score: 3, Insightful

    Nobody gets raises for being a cunt. Come up with a plan to fix this in a cost-effective manner, and maybe next time they'll pay attention.

    --
    lucm, indeed.
  10. Re:Swift is always doing non compat updates by pushing-robot · · Score: 5, Interesting

    The language just turned two years old, and they've been saying for a while that the language wouldn't be 'stable' until version 3.0.

    Nothing is perfect on day one, after all, and Swift borrowed a lot of terribly ugly library methods from Obj-C to make the transition easier. Cleaning all that up for 3.0 will cause some short-term headaches but make future code a lot less cumbersome.

    Hopefully from here on the changes will be relatively minor.

    --
    How can I believe you when you tell me what I don't want to hear?
  11. Re:Garbage by bug_hunter · · Score: 1

    And if it takes them under a day to migrate to Swift 3 will you ask for a pay cut?

    --
    It's turtles all the way down.
  12. Re:Swift is always doing non compat updates by dynamo · · Score: 2

    Lol I have seen many projects waste so much time because of swift's BS incompatible updates to do critical things like making the ++ operator a compile error.

  13. Almost like a new standard by TimMD909 · · Score: 1

    If you change enough, then it's almost like a new standard

  14. bad saying by phantomfive · · Score: 1

    "Move fast and break things,"

    It's such a bad saying that even Facebook has discarded it.

    --
    "First they came for the slanderers and i said nothing."
    1. Re:bad saying by Etcetera · · Score: 1

      "Move fast and break things,"

      It's such a bad saying that even Facebook has discarded it.

      Everyone does, as they grow up.

  15. Then use Swift by SuperKendall · · Score: 1

    Since Swift is open source, it's already been ported to many platforms. It's on Linux (which Apple officially supported) and Windows and even Android now...

    If you are ignoring Swift because of your irrational hatred of Apple, you are only hurting yourself and your future employability. But I do thank you for making it even easier for me to find work.

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
    1. Re:Then use Swift by goose-incarnated · · Score: 3, Interesting

      Since Swift is open source, it's already been ported to many platforms. It's on Linux (which Apple officially supported) and Windows and even Android now...

      So is DOSBox. Doesn't mean much. The reason it hasn't been forked is because there simply isn't enough interest in it from people with the technical ability to fork it.

      If you are ignoring Swift because of your irrational hatred of Apple, you are only hurting yourself and your future employability.

      I dunno hey - I soundly ignored iOS, Obj-C and all Apple development and it hasn't done anything to my employability at all. I expect similar by soundly ignoring Swift.

      But I do thank you for making it even easier for me to find work.

      Personally I'm not in competition with you - I do (and have done) s/ware development on more than a single manufacturers products. I'm flexible. The amount of non-Apple development work out there dwarfs the Apple-only development work. Hell, the Apple-only work being offered is so tiny I doubt it even makes a margin-of-error difference? Maybe four orders of magnitude difference? Less?

      --
      I'm a minority race. Save your vitriol for white people.
    2. Re: Then use Swift by goose-incarnated · · Score: 2

      I have no doubt that you could still get a job writing in COBOL if you wanted to.

      I ignore COBOL for the same reason I ignored iOS-dev: there is no lack of opportunity without them. Lacking iOS (or COBOL) doesn't change my employability enough for me to even notice.

      --
      I'm a minority race. Save your vitriol for white people.
    3. Re: Then use Swift by BasilBrush · · Score: 2

      Yes, there's plenty of choices of languages for which there is lots of employment opportunities. So it comes down to what you enjoy doing.

      For me, I've done C & C++ and I certainly don't miss having seperate header files to maintain and include.

      Java? Who wants all that verbosity, and endlessly nesting braces.

      Swift is a breath of fresh air. It's rather like a statically typed Python, without the strange idioms and indent based blocks. And everything designed with the objective of limiting the likelyhood of creating bugs.

      It makes programming a pleasure again.

    4. Re:Then use Swift by SuperKendall · · Score: 1

      The reason it hasn't been forked is because there simply isn't enough interest in it from people with the technical ability to fork it.

      Or, just maybe, everyone else would wait for ABI stability before trying a port?

      You are going to look SO silly when Android adopts Swift (or forks it)...

      Personally I'm not in competition with you - I do (and have done) s/ware development on more than a single manufacturers products. I'm flexible

      I can't help but laugh at a curmudgeon who ignores a widely used programming language and operating system describe themselves as "flexible".

      I guess then I'm even MORE flexible than you are, since I have worked with scads of non-Apple systems and platforms also...

      --
      "There is more worth loving than we have strength to love." - Brian Jay Stanley
    5. Re:Then use Swift by goose-incarnated · · Score: 1

      The reason it hasn't been forked is because there simply isn't enough interest in it from people with the technical ability to fork it.

      Or, just maybe, everyone else would wait for ABI stability before trying a port?

      You are going to look SO silly when Android adopts Swift (or forks it)...

      Why would I look silly? I hardly ever develop for Android either

      Personally I'm not in competition with you - I do (and have done) s/ware development on more than a single manufacturers products. I'm flexible

      I can't help but laugh at a curmudgeon who ignores a widely used programming language

      Whoa there cowboy - you're getting a little ahead of yourself. Swift is "widely used"? Maybe in mobile development (and even that is probably debatable), but in the Aerospace, Military, Healthcare, Finance, Agriculture, Automotive, Manufacturing, Retail, Mathematic, Web, Modeling, Design, Embedded and Desktop industries/environments the usage is too small to even be accurately counted.

      and operating system describe themselves as "flexible".

      I guess then I'm even MORE flexible than you are, since I have worked with scads of non-Apple systems and platforms also...

      Sure you have. And I'm the King of England (tip: the actual experts and experienced folk almost are rarely blind yes-men for big corps).

      --
      I'm a minority race. Save your vitriol for white people.
  16. Courage was the right world in the end by SuperKendall · · Score: 1

    Look at Slashdot Nerd Rage reactions to the headphone jack being axed and tell me that Apple is not being strong in the face of pain and grief...

    Courage was the right word, the world just didn't realize it until the heated reactions all became public and prolific.

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
    1. Re:Courage was the right world in the end by Anonymous Coward · · Score: 1

      Bloody hell. Get some perspective. Courage is a Syrian girl going to school, or a trans woman going into the women's bathroom in the US. It certainly doesn't describe a company with the highest market value in the world finding another way to fleece their locked-in phone user-base for $150 a pop.

    2. Re:Courage was the right world in the end by MachineShedFred · · Score: 1

      What's funny is that I could go buy an iPhone 7 right now, and I wouldn't need to get "fleeced" for $150. Because it comes with a way to use wired headphones. And Bluetooth still exists, both in this phone, and in my headphones I already have.

      I'm not going to buy an iPhone 7 right now, and maybe not ever; acting like the only way to get audio out is with Apple headphones is a straight fucking lie, and you know it.

      Stop spreading FUD.

      --
      Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
    3. Re:Courage was the right world in the end by JustBoo · · Score: 1

      Look at Slashdot Nerd Rage reactions to the headphone jack being axed and tell me that Apple is not being strong in the face of pain and grief...

      Courage was the right word, the world just didn't realize it until the heated reactions all became public and prolific.

      How is your Apple stock doing? Oh, bad enough for you to shill for them I guess? Imagine that.

    4. Re:Courage was the right world in the end by SuperKendall · · Score: 2

      That's just one example, the entire tech press has lost its shit over the jack being gone. Yes it takes a lot of courage to do something that the press hates En Masse (which they knew would happen) and in turn may drive away some customers - which brings us back around to Slashdot where a number of people said they wouldn't consider a device without a headphone jack.

      Making a change you think is better in he long run that may cost you customers today does take courage, you will never admit that but you know it is true which is why you are so fiercely denying it.

      --
      "There is more worth loving than we have strength to love." - Brian Jay Stanley
    5. Re:Courage was the right world in the end by Jeremi · · Score: 1

      How is your Apple stock doing? Oh, bad enough for you to shill for them I guess? Imagine that.

      Right, because there's nothing that moves markets like comments on Slashdot. Wall Street is hanging on our every word!

      --


      I don't care if it's 90,000 hectares. That lake was not my doing.
  17. Re:Garbage by Anonymous Coward · · Score: 1

    Why would he? you don't have this problem with many other languages.

    If I want to migrate a C# project from 1.0 all the way to 6.0 it takes me exactly zero seconds of effort.

    So it's still a net cost stemming from bad language design, even if only a day. It's not like Swift has anything over C#, in fact, in many ways it's just a clone as most of the features are copied from C# and there's nothing particularly better about Apple's implementation despite being second to market.

  18. Re:Garbage by stealth_finger · · Score: 4, Funny

    Nobody gets raises for being a cunt.

    Then how do the higher ups get their jobs?

    --
    Wanna buy a shirt?
    https://www.redbubble.com/people/stealthfinger/shop?asc=u
  19. Re:Swift is always doing non compat updates by Buchenskjoll · · Score: 4, Funny

    Nothing is perfect on day one, after all

    I was.

    --
    -- Make America hate again!
  20. It can join python 3, vb.net, and perl 6 by Billly+Gates · · Score: 1, Insightful

    Now it won't ever be implemented. Shoot we would still be having an IE 6 internet too if it were not for MS forcing corps to stop using it. People hate change and it is impossible unless you kill the original but good luck as Swift is open source

  21. Re:Swift is always doing non compat updates by Anonymous Coward · · Score: 3, Funny

    And it all went downhill from there

  22. Re:Swift is always doing non compat updates by uohcicds · · Score: 3, Insightful

    Yes. It's not like people weren't warned about this. The Swift 3 announcement at WWDC back in June made this very very explicit indeed, as indeed did swift.org from even earlier.

    --
    It's not you: I'm just this horrifically socially awkward with everybody.
  23. Meanwhile, back in C land... by Viol8 · · Score: 2

    ... my Stevens unix systems programming book (which applies t to OS/X too) from the mid 90s is still mostly relevant today.

    1. Re:Meanwhile, back in C land... by grumbel5969 · · Score: 1

      While C remains backward compatible, C99 and C10 have added quite a lot of stuff to C. But due to Microsoft's refusal to support newer C standards in Visual Studio and the problems that mixing new C with new C++ brings, they aren't in widespread use.

    2. Re:Meanwhile, back in C land... by west · · Score: 4, Insightful

      Well, C was created in 1972, so that did give them some 20+ years before stability...

    3. Re:Meanwhile, back in C land... by Viol8 · · Score: 1

      Yes, but its not so much the language, more than the core Unix API has remained pretty stable now for going on 30 years.

  24. Re:Swift is always doing non compat updates by DavidRawling · · Score: 2

    Ah yes because

    DoSomething(i);
    i = i + 1;

    is so much better.

    ProTip: This is sarcasm.

  25. This thread is full of anti-Apple haters by Anonymous Coward · · Score: 4, Informative

    Everybody whining here clearly hasn't written any Swift code and is only interested in bashing Apple. Maybe you should be asking what actual people using Swift think of this.

    Well, I'll tell you as one.

    - The Swift syntax changes are annoying to spend time on, but minor.
    - Apple's migration tool is helpful and makes fixing go fast.
    - It was no surprise or secret that the syntax was going to change. They said all this upfront and we all knew this was coming.
    - Swift on Linux and other platforms only started working less than a year ago. There is not as much code to transition.

  26. Re:Swift is always doing non compat updates by Entrope · · Score: 1

    Did Chris Lattner lie about stability being pushed back until Swift 4.0, or did he not speak for "they"? How many earlier, missed, binary-compatibility goals have they missed?

  27. Re:Swift is always doing non compat updates by luis_a_espinal · · Score: 1

    And it all went downhill from there

    LOL, best retort ever :)

  28. Re:Garbage by Feral+Nerd · · Score: 3, Funny

    Nobody gets raises for being a cunt.

    Then how do the higher ups get their jobs?

    They ingratiate themselves to the cunts by being dildos.

  29. Re:Garbage by luis_a_espinal · · Score: 1

    Nobody gets raises for being a cunt. Come up with a plan to fix this in a cost-effective manner, and maybe next time they'll pay attention.

    Hahahahaha, been living under a rock, haven't you?

  30. Re:Garbage by JustBoo · · Score: 1

    Nobody gets raises for being a cunt. Come up with a plan to fix this in a cost-effective manner, and maybe next time they'll pay attention.

    You've clearly never worked in a Fortune 500 company. Clearly. (Wow, so many neophytes in this thread. Oh wait, this is an Apple thread... got it.)

  31. And Thus the Reason for Swift 2.3 by rsmith-mac · · Score: 4, Informative

    What TFS doesn't do a good job of explaining is that with Swift 3, Apple has essentially forked the project into two parts. Besides the newer version 3, Apple is also continuing to develop/support Swift 2.x. The already-released Swift 2.3 is Swift 3's counterpart for developers who would like to stick with Swift 2.x code.

    Swift 2.3 is a minor update from Swift 2.2.1. The primary difference between Swift 2.2.1 and Swift 2.3 is that it is intended to be paired with Apple's macOS 10.12, iOS 10, watchOS 3, and tvOS 10 SDKs. It also updates the underlying LLVM and Clang versions to match with those in the Swift 3 compiler.

    I don't imagine Apple will support Swift 2.x forever. But for the time being, Swift 3 is only as source-breaking as you want it to be. Developers who need Swift 2 compatibility can roll on with 2.3.

    1. Re:And Thus the Reason for Swift 2.3 by OzPeter · · Score: 3, Funny

      What TFS doesn't do a good job of explaining is that with Swift 3, Apple has essentially forked the project into two parts.

      Stop confounding us with facts! I was halfway through sharpening my pitchfork when I saw your comment and now I'll also have to cancel that Amazon order for my torch oil.

      --
      I am Slashdot. Are you Slashdot as well?
    2. Re: And Thus the Reason for Swift 2.3 by Entrope · · Score: 1

      Swift 3 is as compatibility-breaking as people made it out to be. But hey, you can choose to stick with Swift 2.3 if you want to suffer even more compatibility breakage when Swift 4 comes along.

      Apple apologists should just admit that Apple can't decide how to design either a library or a language.

    3. Re:And Thus the Reason for Swift 2.3 by A+Big+Gnu+Thrush · · Score: 1

      At some point, Apple will not allow apps using Swift 2.3 into the App Store. I don't think this split will exist for very long. Apple has the advantage of controlling both sides of the ecosystem.

  32. Bottes Timberland Pas Cher France by chenzunxin · · Score: 1

    timberland pas cher it's ok to wipe it with wet rag. But when it comes to imitated furs such as the black upper of air Jordan, you should pay attention to the dampness of rag. Otherwise it will get worse. But this method can not be employed into shoes with cloth upper such as Nike air Garnett III. Since such uppers find no ways to clean. Then, it would be better to unfasten the ties and wash it, which will make your cleaned shoes more attractive. Last but not the least; you should wear your shoes under natural conditions, say not in rainy day, snow day. Besides, you should change you shoes at regular bases to avoid over-used. In a word, the maintenance of shoes needs care and is worthwhile. Summery: Sports shoes are so popular that almost everyone owns one pair. Some are durable and dear while others are cheap and fragile. But if we maintain them properly, its life can be extended more or less. Based on above, this article chose the maintenance of sports shoes as its objective. The article not only offers some practical cleaning methods but also some tips for attention in the course of maintaining your shoes. copyright by air jordans.

  33. Mission Accomplished by RoscoeChicken · · Score: 1

    I've always seen Swift as a way of keeping application model logic off of competing mobile platforms/languages, specifically C++ (which Apple supports extremely well on iOS BTW). I view it as the new PowerBuilder --- remember those "LEARN POWERBUILDER OR LOSE YOUR JOB" ads?

    How much money did Corporate America p*ss away on PowerBuilder? ... but I digress ...

    The company open sourced Swift once it was clear Windows Phone was dead, but now that the app market is in decline, they need to squelch the experiments of the Swift 2.x compilers targeting Android for easy cross platform development.

  34. No! by edxwelch · · Score: 1

    No. Better never make code breaking changes. You have all the time in the world to make API changes before it becomes public, then it remains fixed.
    Paticularly, trivial name changes are bad. It doesn't really matter if the function is called "sort" or "sorted" if you are breaking old code that's bad.

    1. Re:No! by shmlco · · Score: 1

      Then I guess it's okay, because the name changes are certainly not trivial....

      --
      Any sect, cult, or religion will legislate its creed into law if it acquires the political power to do so.
    2. Re:No! by edxwelch · · Score: 1

      Name changes are always trivial

  35. Re:Swift is always doing non compat updates by Brett+Diamond · · Score: 4, Informative
    The ++ operator is not the same as += 1 operation. For example,

    var a = 3
    let b = a++ * 3

    Now, I expect this type of code is the justification Apple is using to remove the operator; although there is no ambiguity, the line which sets b also sets a.

    I argue that prefix and postfix ++ and -- should have remained in Swift. Not only are they well defined, but they are a standard operator in almost all new languages and therefore convey their meaning to the application developer significantly better than += 1 or -= 1 ever could.

    For example, when reading code, ++i requires significantly less reading and parsing by the developer than i += 1 to convey the same idea.

  36. If you think this is bad... by __aaclcg7560 · · Score: 1, Insightful

    A non-programming friend downloaded Swift Playgrounds app on his iPad to learn Swift programming. Not sure why it introduced him to nested functions right off the bat. Anyway, he's frustrated because his code doesn't work and he wants someone else — probably me — to figure out why. I told him if he wanted to be a real programmer he needed to debug his own code before asking someone for help.

  37. Re:One word: meme by istartedi · · Score: 1

    Can we have the word "COURAGE" back please

    No you can't. Courage ran off with Smart and had a bastard child named Hero.

    --
    For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
  38. Re:Swift is always doing non compat updates by shmlco · · Score: 1

    There's a difference between stabilizing the language (3.0) and the ABI (4.0).

    --
    Any sect, cult, or religion will legislate its creed into law if it acquires the political power to do so.
  39. Modules by fulldecent · · Score: 1

    For anyone that is writing Swift 3 modules (that other people will use in their projects):

    You may be interested in this template and recipe that explains how exactly to set up your project and Xcode settings properly.

    It is at: https://github.com/fulldecent/... /selfpromo

    Hopefully Swift 4 and other updates will not require every developer to redo everything each time.

    --

    -- I was raised on the command line, bitch

  40. Re: Swift is always doing non compat updates by Entrope · · Score: 1

    No, there really isn't. With no alternative implementation of the language, the ABI is inherently part of the language definition. You can't carve out bits and pieces of Swift 3.0 and declare that it's going to be forward-compatible when it won't be.

    On top of that, Apple has promised compatibility before, and changed their minds when it was convenient.

  41. Re:Garbage by bug_hunter · · Score: 1

    Because this wasn't a surprise Apple just dumped on people, this was a well established by the open Swift community.

    The core language itself has only really had minor tweaks, how the standard Apple libraries are referenced is what's caused the major change (e.g. not so much the language was horrible in v2 but awkward naming conventions from bridging the Objective-C way of doing things) as well as some naming changes for Swift standard libraries.
    Presumably if they went with Swift it was for an iOS/OSX project where Objective-C was the alternative. I find I'm much more productive in Swift than Obj-C, and time spent migrating Swift 2 to 3 for me is dwarfed by the time I saved using Swift.

    So to answer your question: If the upgrade doesn't take long he should take a pay cut because: this wasn't a surprise that jumped on them, this was a well known and documented set of upcoming changes that shouldn't take much time to implement - especially given the (not always perfect) migration tools provided.
    If the OP wants to say that everyone else is wrong all the time and get a pay raise when he's proven right then he should get a pay cut if he's proven wrong.

    --
    It's turtles all the way down.
  42. Very easy transition by cerberusss · · Score: 2

    I'm working on a small mixed Objective-C/Swift project. The API was provided, and is in Objective-C so no changes there. The UI code (i.e. all view controllers) are all in Swift, and consist of about ~30 classes. Moving from Swift 2.3 to 3 was quite easy with the migration tool, and took me about two hours.

    --
    8 of 13 people found this answer helpful. Did you?