Follow Slashdot stories on Twitter


Forgot your password?
IOS Open Source Programming Apple

7 Swift 2 Enhancements iOS Devs Will Love 123

snydeq writes: InfoWorld's Paul Solt outlines how Apple has made good on Swift's emphasis on performance, approachability, and ease in its latest update, offering up seven worthwhile enhancements to Swift 2, along with code samples. 'Many of the enhancements to Swift, through both the Swift 2.0 update and subsequent Swift 2.1 update, have made the language more explicit and intentional, and in turns, Swift 2 code will be safer and easier to maintain for years to come (especially now that Swift is open source). New language constructs (keywords) in Swift 2 improve the readability of control flow — the order in which lines of code are executed. Thanks to these new keywords, collaborating on Swift code will be much more productive and efficient.'
This discussion has been archived. No new comments can be posted.

7 Swift 2 Enhancements iOS Devs Will Love

Comments Filter:
  • Next year (Score:1, Insightful)

    Next year the headline will be "Swift 3 Introduced by Apple". Swift 3 is more intentional and safer than ever allowing iOS developers to do more, faster. Swift 3 addresses all the problems with Swift 2 and will be completely incompatible with Swift 2 and the syntax has completely changed. Swift 2 support is dropped as it is now obsolete.
    • In fact you are right. From the swift-evolution repo []:

      Swift 3.0 will not provide full source compatibility. Rather, it can and will introduce source-breaking changes needed to support the main goals of Swift 3.0.

      • Swift has had source-breaking changes with nearly every version change...

        What Swift ALSO has, is a migration tool built into Xcode to upgrade to new versions - so when you feel like Swift has moved into production, you run the migration tool and spend perhaps an hour or so fixing any other issues you find.

        Swift has shown that languages of the past have been WAY too afraid of messing with syntax as the language changes, because it's not nearly as big a deal as it would seem.

        • Language stability is a very big deal if you've got a sizable body of code, say a few hundred billion lines or so that have been written, bugfixed, and hardened over the past few decades. It's something that people with very large investments in very large code bases that are maintained for a long time tend to care about.

          I suppose if you're banging out the latest iOS app in six or twelve months the stability of the language isn't as big of a deal. Nothing wrong with that, but you have to remember that dif

          • by Anonymous Coward

            ... if you've got a sizable body of code, say a few hundred billion lines or so that have been written, bugfixed, and hardened over the past few decades.

            If you have written a few hundred billion lines of high quality Swift code over the past few decades, you have just the experience my employer is looking for.

          • Language stability is a very big deal if you've got a sizable body of code

            That's my point though; it's really not.

            I'm working for a client who moved to Swift at release. At this point we have a LOT of production code in Swift, and this is all heavy database and UI code (for an enterprise app). This is not simple stuff, nor simple code...

            But the language migration has caused as most a handful of hours of work over the last year or so. Much of that is because of the migration tool, without that it probably

    • Swift 3 is having a name change: it's now iSwift. Do more, faster with iSwift. Code! iSwift. It's magical, iSwift! Bring magic and buzzwords to end uers with iSwift! iSwift can do it all! Faster! Sleek! iSwift! Magical! User friendly! No more text interfaces for coding! iSwift! intelligent! iSwift secure! Do more, iSwift! Now supporting Retina! iSwift! Brushed Aluminium! Unibody iSwift!
    • by Goaway ( 82658 )

      Yes, that horrible, horrible Apple. How dare they make their code BETTER!

  • In the code example, the dude's using something called "guard" like an if statement (e.g., "if argument is shit, return null now, mofos" is written as "GUARD argument is shit, return NIL now, mofos").

    • by denzacar ( 181829 ) on Tuesday February 02, 2016 @11:09AM (#51421031) Journal

      Letters I and F have sharp and thus ugly corners, making the word IF ugly.

      G and D on the other hand are rounded and smooth on the outside, making the word GUARD beautiful and stylish.
      In the next iteration all words will have round corners and will be white.

      • by MagicM ( 85041 )

        Quite true. While "if" is an awful, tinny word, "guard" is nice and woody. You can't beat wood.

      • Rats. I was going to say that you can already program with white characters, but the official site for the Whitespace language is not responding. I don't know if it's been taken down or if there's a temporary problem.

    • Came here to ask this. Glad to see it asked, disappointed that there's no answer. The article does a terrible job of explaining guard, making it look like an alias for "if", but it seems there are real benefits.


      It still looks like it provides some benefits, but I don't know Swift that well, so it could be that all the alternatives that come to mind aren't possible or are more cumbersome than I expect. The primary benefit I see is quick a

    • by ecotax ( 303198 )
      As NSHipser [] describes it:

      guard is a new conditional statement that requires execution to exit the current block if the condition isn’t met.

      You can exit the current block from an if-statement, of course. But it doesn't force you to. Also, having a separate keyword for things like preconditions can make code more readable, because you can express your intent.

    • by Goaway ( 82658 )

      Guard forces you to exit the function in the else branch, and "guard let" introduces a symbol in the containing scope rather than the contained scope.

  • by xxxJonBoyxxx ( 565205 ) on Tuesday February 02, 2016 @10:50AM (#51420919)

    >> The do/while loop is now the repeat/while goes against the convention of established languages like Objective-C, JavaScript, C++, and Java.
    >> The do keyword has been repurposed to create new scope, unlike every other popular language that uses it for loops.

    The only rational reason I can see for these kinds of hostile changes would be to DECREASE the ability of programmers to port code between Apple and non-Apple platforms.

    • Holy cow. Those are actually comments from the article pimping this? \me checks. Crap, he's right.

      Now, in Apple's defense, I think their use of "do" reads well and is a nice way to introduce a scope block. I mean, you could just use the curly braces (like C), but I can kinda see the point of putting a keyword there. And repeat/while similarly makes sense. And I don't think the argument that "everyone else does it this way" automatically outweighs other concerns.

      But, damn, to put statements like those in an

    • by Megol ( 3135005 ) on Tuesday February 02, 2016 @01:33PM (#51422077)

      I wouldn't run code from a programmer who'd have a problem porting code for that reason! He/she wouldn't be worthy of being called a programmer at all in fact.

    • Any programmer that can't port because of the "do" keyword should probably go back to writing PHP.
  • by pesho ( 843750 ) on Tuesday February 02, 2016 @10:52AM (#51420937)

    How far the mighty have fallen. Now we are plucking click-bait titles from the yellowest pages of the web. Did the new managment fire all human staf and program the bots to spit out random stuff that fits a particular template:

    Who wants to read about [N, where N is less than 10] [insert a noun here] that [insert a reference to a group that the reader would identify with] would [love/hate/be shocked with/never new about/should have known about/must read]

    • by halivar ( 535827 )

      How far the mighty have fallen. Now we are plucking click-bait titles from the yellowest pages of the web.

      Hardly a new development. Dicevertisements were pure click-bait.

    • by mwvdlee ( 775178 )

      7 most painful ways in which the editors should go fuck themselves.

    • Thinking the same thing. We already deal with enough clickbait here, but if we've sunk to the point that we're re-posting those sorts of headlines verbatim, we've hit a new low. Is this what we should expect going forward?

    • by godrik ( 1287354 )

      In particular I hate that title because it is completely unclear because it has two numerals in the first three words. "7 pictures of dogs you will love" is fine. But "7 Swift 2 features are amazing" is hard to parse. "Seven Swift 2 features are amazing" is MUCH easier to parse.

      It always amazes me that many people write without thinking of how the text will be read.

  • When posting a story about some obscure software that nobody has heard of, how about a short description of what the heck it is? Readers should not need to break out Google to understand what you're talking about. This was covered this in Journalism 101.

  • Apple have tossed out a compiler and a very rudimentary stdlib. I'm sure it ticks a box but it's not a practical language that people can use for much.
  • "control flow — the order in which lines of code are executed"

    Well, thanks for explaining control flow to us. Who knows, maybe there is someone here who cares about programming languages and reads news about iOS devs, and yet somehow has no clue about control flow.

    Actually that would probably be a prolog programmer, come to think of it. But even then...

  • That defer keyword looks like the mother of all hidden bugs. If you end up finishing a statement, not in the way you intended, and all of a sudden resources are getting cleaned up before you used them. I'd stay away from that one.

    I get introducing repeat to replace do, but at the same time giving do a different meaning than the rest of the languages! There will be no end to confusion over that.

    • I guess defer is only every useful in a function that creates a resource R, uses R itself and does not share R with any code that can run at a later time.

      That last requirement might be a little tricky to check for at compile time.

      • It's not even that. The way it looks to me is that if you currently have two statements which are immediately after each other, and now you interject a defer, it'll work. But it's easy to break up how immediately statements follow each other when maintaining code. So one little misstep, and BAM, all of a sudden resources are getting cleaned up unexpectedly.
        • I think the defer block will always run as the last thing that happens before its containing scope finishes. So as long as you're just writing a function that opens a resource and does not hand that resource over to anything else you should get a very predictable behaviour regardless of what you do inside that function.

          The placement of the defer block itself probably doesn't matter. I suppose it would give you a compile time error if you place it before the resource is declared.

          • Actually, I just gave it a try, and there is a problem with where you place your defer block.

            The following program compiles and the value of the string at the end of execution is "newValue", not "newerValue" as the programmer probably intended.

            var someString = "oldValue"
            func deferTest() {
            someString = "newValue"
            defer {
            someString = "newerValue"

    • by mandolin ( 7248 )

      That defer keyword looks like the mother of all hidden bugs.

      At first glance it looks to me like Apple ripped defer straight from Go []. I think it has its use -- in a language that doesn't support RAII. But I prefer the latter.

  • Honestly, Slashdot, this is is the type of headline that I'd expect to see on my Facebook feed... PS. secretly hoping the use was ironic

grep me no patterns and I'll tell you no lines.