7 Swift 2 Enhancements iOS Devs Will Love

← Back to Stories (view on slashdot.org)

7 Swift 2 Enhancements iOS Devs Will Love

Posted by timothy on Tuesday February 2, 2016 @02:30AM from the magic-buttons dept.

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

63 of 123 comments (clear)

Min score:

Reason:

Sort:

Next year by 110010001000 · 2016-02-02 02:36 · 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.
1. Re:Next year by Kjella · 2016-02-02 03:18 · Score: 2
  
  I read the first item ("guard" keyword) a couple of times, and I'm still having trouble figuring out what it does that a simple "if" statement doesn't do. It is just syntactic sugar for the if statement, but used to indicate precondition checks? I feel like I'm missing something obvious.
  From what I understand it also unwraps the variable, Swift has int? that can either be an int or nil. If you just use if, you have to force-unwrap it inside the "safe zone" while guard morphs it to a non-nil int type.
  
  --
  Live today, because you never know what tomorrow brings
2. Re:Next year by ashpool7 · 2016-02-02 03:23 · Score: 2
  
  Guard: http://ericcerney.com/swift-gu...
  They've basically said Swift is sorta-beta by not solidifying ABIs until maybe Swift 3. Until then they will make auto-updaters for migrating your code.
3. Re:Next year by NotInHere · 2016-02-02 03:35 · Score: 1
  
  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.
4. Re:Next year by fulldecent · 2016-02-02 03:49 · Score: 2
  
  The only difference between guard and if ! is that guard requires an exit of some form.
  Practically, as a programmer who is maintaining code, it is very expressive to find a guard. You can immediately scroll down to the bottom past the block and you will understand the preconditions of what your eyes are currently looking at.
  I never use code folding, however guards would be an attractive case to use them. Because it is truly: guard precondition and then the rest does not matter.
  
  --
  -- I was raised on the command line, bitch
5. Re: Next year by Applehu+Akbar · 2016-02-02 04:22 · Score: 1
  
  Because all the programming languages were declared frozen for all time after Kernighan & Ritchie. No further innovation will ever occur.
6. Re:Next year by xxxJonBoyxxx · 2016-02-02 04:24 · Score: 1
  
  >> Can someone explain to me why recruiters will demand five years of [brandnewtech]?
  In recruiter speak, "experienced" translates directly into "5 or more year of experience with..." and many recruiters don't know how to describe technologies without including the version number. Certainly very few understand how long a technology has been around (and whether 5 years of experience is realistic). And a lot more gets lost in the translation chain from lead team who needs the resources -> manager -> HR -> recruiter.
7. Re:Next year by Logic+and+Reason · 2016-02-02 04:48 · Score: 1
  There are two differences between guard and if:
  
  Guard requires that you exit the outer scope somehow in its body.
  While an if-let binding only exists in the true branch's scope, a guard-let binding becomes part of the outer scope.
  I haven't used them much myself, but guards aren't just a synonym for if-not.
8. Re:Next year by Megol · 2016-02-02 05:29 · Score: 2
  
  From the perspective of a C# developer, none of this is terribly ground-breaking, and some of it is downright idiotic.
  "guard" appears to be a "not-if". Pointless. If I want not-if, I'll use if(!whatever).
  Then you fail to understand its usefulness: if is a clear indication that it is a guard(!) and it is easier to read. Some languages have a unless statement which makes code easier to read but this is a statement specific for validating arguments.
  
  "defer" is a clunky way of copying the "using" block from C#, but without requiring the code-by-convention IDisposable implementation. Useful, but could've been better. At least it has notable improvements over the status quo.
  It is a statement that have uses but can make code much harder to read if used wrongly. The example in the article illustrates that well.
  
  "repeat/while" is retarded and an unnecessary change away from well-known and accepted language conventions. This is the kind of convention that is actually worth sticking to, and Apple just broke it. "Nice job breaking it, hero."
  Surprise! There are other programming languages than C out there, some of which use repeat ... while constructs. So it isn't breaking anything (well, Swift code but isn't that an Apple standard?).
  
  "do" is a sign that their language parser developers are lazy and bad at their jobs, because they can't handle a set of curly braces as a start-a-new-scope delimiter. Fire these lazy bastards.
  Easier to read...
  
  "error" is a goto label. It also converts "do" into try, and "try" into assert(). I guess you've got to call it something, and if you make it too much like your competitor's language, people will be skilled across both! A travesty! And who's with me in thinking that "catch let error as FooType" is clunky as shit? It's as bad as VB. C# has this one right: catch(FooType error) ... and done.
  Again this is something that makes code more readable. By including the fact that a routine can fail in the declaration a lot of problems can be avoided, the requirement of the try keyword on things that can fail is much better than having it hidden from the programmer. Yes going in the direction of explicit error checking have problems but those are IMHO preferable to the alternative (hidden data passing).
  
  Protocol extensions are nice, and are probably going to be quite useful in keeping your code readable. C# has had extension methods for a while now, and they're quite useful. It's good to see that Apple is adding that sort of thing to Swift, as it can prevent a measure of code rot.
  OptionSetType is the same as .Net's FlagsAttribute. Not special, but, again, a nice addition. It even goes a step further and adds easy bitwise comparison handling for you. Again, good on Apple for taking an existing good idea and making it better.
  What does it do that Pascal's set type doesn't (except being much more verbose)?
  
  And the last item appears to be an improvement to what .Net developers would call "interop". Any improvements are welcome, as interop is universally a pain. It will never be "right", but it may be tolerable.
9. Re:Next year by jader3rd · 2016-02-02 07:16 · Score: 1
  
  I haven't used them much myself, but guards aren't just a synonym for if-not.
  You're right, guard is a synonym for if-not return.
10. Re:Next year by Anonymous Coward · 2016-02-02 08:09 · Score: 1
  
  "guard" is primarily used to unwrap optionals into the current scope, rather than creating a new scope like "if" does. (This is safe/doable because the failure case must return or otherwise exit the current scope.) That means multiple unwrappings don't cause you to descend into nested-if hell.
  guard is probably my favorite addition to Swift so far.
11. Re:Next year by BinBoy · 2016-02-02 11:00 · Score: 1
  
  And recruiters will demand five years of Swift 3 on their mandatory qualifications lists, as they do with Swift 2 right now.
  Can someone explain to me why they do this? I can understand five years of Swift with OpenStack, but not Apple Swift.
  Advertise impossible requirements to Americans. When no American qualifies, you can now legally hire an H1B. https://www.youtube.com/watch?v=TCbFEgFajGU
12. Re:Next year by billDCat · 2016-02-02 19:27 · Score: 1
  
  From what I see in the documentation, the "guard let" combination is sort of the opposite of "if let". Normally you would have something like this which would both assign destinationViewController to a new constant and would check to see if the result of controller is nil:
  if let controller = segue.destinationViewController { // do something with controller
  }
  with guard you can do the opposite:
  guard let controller = segue.destinationViewController else { // handle a controller that contains nil
  return nil
  }
  You can also use it to check a complete expression for errors. The following will check if someController is nil OR someController.bunchOfItems is nil OR someController.bunchOfItems.count == 0
  guard someController.bunchOfItems.count > 0 else {
  throw MyError.OutOfStock
  }
  The guard statement is used for error management, and must transfer control using return, throw, break, or continue from within the block
13. Re:Next year by BasilBrush · 2016-02-02 23:48 · Score: 1
  
  No. The guard statement also allows unwrapping an optional, with scope of the rest of the block AFTER the guard.
  The if statement allows unwrapping with scope of the block IN the if.
14. Re: Next year by BasilBrush · 2016-02-02 23:50 · Score: 1
  
  Blah blah blah hate Apple blah blah.
15. Re:Next year by BasilBrush · 2016-02-02 23:52 · Score: 1
  
  Nope you are still missing the scope of the unwrapping of optionals. This is also different.
16. Re:Next year by Goaway · 2016-02-03 02:40 · Score: 1
  
  Yes, that horrible, horrible Apple. How dare they make their code BETTER!
17. Re: Next year by macs4all · 2016-02-03 04:47 · Score: 1
  
  I agree re figuring this basic stuff out before v1. Actually I wish Apple would save us all the hassle of sharing their experience of "learning how to make a programming language". Buy MS already and take C#, a mature and generally well-regarded language. C# 1 was usable and they didn't make weird fundamental changes constantly afterwards as Apple is with Swift. Making programming languages is kind of a well understood domain, but Swift smells like hipsters fresh out of uni to me, learning from their mistakes as they go.
  There's a simple solution: Don't use Swift, or STFU.
  
  And how many full-blown programming languages have you written?
18. Re: Next year by macs4all · 2016-02-03 04:48 · Score: 1
  
  Swift is not a good example of an innovative language. Apple just wants something that is different enough to assist developer lock-in. That's what they used to love about Obj-C: it was resistent to being ported, thanks to its incredibly weird method-calling syntax.
  Right. That's why they Open Sourced Swift. Lock in, that's it.
WTF is "guard"? by xxxJonBoyxxx · 2016-02-02 02:45 · Score: 1

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").
1. Re:WTF is "guard"? by DahGhostfacedFiddlah · 2016-02-02 05:36 · Score: 1
  
  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.
  (http://stackoverflow.com/questions/30791488/swift-2-guard-keyword).
  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 assign-and-check for Optionals.
  
  --
  Last post!
2. Re:WTF is "guard"? by ecotax · 2016-02-02 07:23 · Score: 1
  
  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.
  
  --
  "Money is a sign of poverty." - Iain Banks
3. Re:WTF is "guard"? by R3d+M3rcury · 2016-02-02 08:35 · Score: 1
  
  I was going to say, it's sort of like an NSAssert.
4. Re:WTF is "guard"? by Goaway · 2016-02-03 02:41 · Score: 1
  
  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.
This looks intentionally proprietary, Apple by xxxJonBoyxxx · 2016-02-02 02:50 · Score: 2

>> The do/while loop is now the repeat/while loop...it 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.
1. Re:This looks intentionally proprietary, Apple by thoromyr · 2016-02-02 03:24 · Score: 1
  
  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 article *supporting* swift's syntax? Acknowledge that its different? Sure. But phrased the way those comments are, positioned in the article how those comments are, it comes across as hostile. Wow.
2. Re:This looks intentionally proprietary, Apple by Megol · 2016-02-02 05:33 · Score: 3, Insightful
  
  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.
3. Re: This looks intentionally proprietary, Apple by hondo77 · 2016-02-02 08:01 · Score: 1
  
  Any programmer that can't port because of the "do" keyword should probably go back to writing PHP.
  
  --
  I live ze unknown. I love ze unknown. I am ze unknown.
1 title slashdoters will hate by pesho · 2016-02-02 02:52 · Score: 3

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]
1. Re:1 title slashdoters will hate by halivar · 2016-02-02 03:25 · Score: 1
  
  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.
2. Re:1 title slashdoters will hate by mwvdlee · 2016-02-02 03:41 · Score: 2
  
  7 most painful ways in which the editors should go fuck themselves.
  
  --
  Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
3. Re:1 title slashdoters will hate by Anubis+IV · 2016-02-02 04:03 · Score: 2
  
  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?
4. Re:1 title slashdoters will hate by xxxJonBoyxxx · 2016-02-02 04:26 · Score: 1
  
  I might click on that.
5. Re:1 title slashdoters will hate by godrik · 2016-02-02 04:26 · Score: 1
  
  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.
IF is an ugly word. by denzacar · 2016-02-02 03:09 · Score: 5, Funny

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.

--
Mit der Dummheit kämpfen Götter selbst vergebens
1. Re:IF is an ugly word. by MagicM · 2016-02-02 03:51 · Score: 2
  
  Quite true. While "if" is an awful, tinny word, "guard" is nice and woody. You can't beat wood.
2. Re:IF is an ugly word. by s122604 · 2016-02-02 05:31 · Score: 1
  
  Guard has warmth and complexity, IF is digital and antiseptic
3. Re:IF is an ugly word. by david_thornley · 2016-02-03 11:09 · Score: 1
  
  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.
  
  --
  "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Re:Swift is making Rust obsolete already! by jcr · 2016-02-02 03:14 · Score: 1

Woah, we have an Apple shill day today.
Why would an Apple shill care about Rust? The only impact it has on Swift is the occasional question that comes up on the swift-evolution mailing list, like "should we add this feature that Rust has?"
-jcr

--
The only title of honor that a tyrant can grant is "Enemy of the State."
Re:Swift is making Rust obsolete already! by NotInHere · 2016-02-02 03:22 · Score: 1

I don't believe that apple will want swift to grow outside of the apple walled garden.
The main reason for using swift is that apple wants their developers to be locked in, on a language level. Their applications should be re-written from scratch if they want them to run on android or other plaftorms. They always went a different path to ensure this kind of lock-in. And they even found imitators, Google basically did this when they introduced java based apps.
Re:Swift is making Rust obsolete already! by jcr · 2016-02-02 03:27 · Score: 4, Insightful

The main reason for using swift is that apple wants their developers to be locked in, on a language level.
Oh, for crying out loud.
The reason for Swift is that Apple is highly aware of where they spend their engineering time, and Swift makes the most common Obj-C mistakes difficult or impossible to write at all. It's not some kind of Machiavellian plot.
-jcr

--
The only title of honor that a tyrant can grant is "Enemy of the State."
Open source doesn't mean much in this case by DrXym · 2016-02-02 04:20 · Score: 1

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.
Re:Swift is making Rust obsolete already! by schlachter · 2016-02-02 05:07 · Score: 1

not to mention it was their developers themselves who came up with Swift and pushed for its usage...not some CEO decree.

--
My God can beat up your God. Just kidding...don't take offense. I know there's no God.
Re:Swift is making Rust obsolete already! by Trailer+Trash · 2016-02-02 05:35 · Score: 1

I don't believe that apple will want swift to grow outside of the apple walled garden.
The main reason for using swift is that apple wants their developers to be locked in, on a language level. Their applications should be re-written from scratch if they want them to run on android or other plaftorms. They always went a different path to ensure this kind of lock-in. And they even found imitators, Google basically did this when they introduced java based apps.
Right. And open-sourcing swift is just part of this nefarious plot that you've uncovered.
How, I don't know.

--
Do you have ESP?
Introducing iSwift! by mlw4428 · 2016-02-02 05:43 · Score: 1

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!
News for nerds? by johannesg · 2016-02-02 05:54 · Score: 1

"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's been true all along by SuperKendall · 2016-02-02 05:59 · Score: 1

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.

--
"There is more worth loving than we have strength to love." - Brian Jay Stanley
1. Re:That's been true all along by Dutch+Gun · 2016-02-02 06:41 · Score: 1
  
  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 different developers and different projects value different things in their programming languages.
  
  --
  Irony: Agile development has too much intertia to be abandoned now.
2. Re:That's been true all along by Anonymous Coward · 2016-02-02 07:50 · Score: 1
  
  ... 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.
3. Re:That's been true all along by Dutch+Gun · 2016-02-02 14:32 · Score: 1
  
  Fair enough. If they warned everyone ahead of time that they'd be making breaking changes to the language, then that's not quite so bad (I must have missed the memo). And of course, the inclusion of migration tools certainly helps to mitigate whatever minor pain is involved. It's just that I tend to view those sorts of changes as the hallmark of a beta product - one still below the 1.0 release threshold. I guess that's what happens when version numbers don't mean what they've historically represented anymore. It confuses old-timers like me.
  I recently began porting my project to OS X (and will eventually do iOS as well), so I had to pick up Objective-C. Swift looked interesting, but didn't work for me because it couldn't as easily interop with my native C++ libraries. So, yeah, of course... there's no way that Apple can abandon Objective-C anytime in the near future either (as some have speculated), because again, a lot of people have a very substantial investment in Objective-C code as well.
  
  --
  Irony: Agile development has too much intertia to be abandoned now.
More like hidden bug introducer by jader3rd · 2016-02-02 06:15 · Score: 1

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.
1. Re:More like hidden bug introducer by rasmusbr · 2016-02-02 07:26 · Score: 1
  
  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.
2. Re:More like hidden bug introducer by jader3rd · 2016-02-02 09:45 · Score: 1
  
  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.
3. Re:More like hidden bug introducer by rasmusbr · 2016-02-02 11:01 · Score: 1
  
  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.
4. Re:More like hidden bug introducer by rasmusbr · 2016-02-02 11:27 · Score: 1
  
  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"
  return
  defer {
  someString = "newerValue"
  }
  }
  deferTest()
  someString
5. Re:More like hidden bug introducer by mandolin · 2016-02-02 12:20 · Score: 1
  
  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.
Re: And then there's stribgs by jcr · 2016-02-02 07:37 · Score: 1

Swift doesn't limit its strings to ASCII characters, and moving from one character to the next in a unicode string isn't as simple as ++.
-jcr

--
The only title of honor that a tyrant can grant is "Enemy of the State."
No actually it's not by SuperKendall · 2016-02-02 07:51 · Score: 1

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 would have been more but I don't think it would have been a huge amount more. After all, we have a lot of modern tools for dealing with changing text in batch across a large codebase.
Languages forever have treated syntax as something they simply cannot change, compounding mistake after mistake of initial design because they are too afraid to break existing code. I'm here to say that fear is overblown, and more languages should not be afraid to re-work terrible syntax to make the language better.
I suppose if you're banging out the latest iOS app in six or twelve months
The app i"m on currently has been around for about five years, so no.
I've worked for many large companies with many large and very old codebases so I'm acutely aware of the need to worry about maintainable code. It's just that it turns out worries about language changes are mostly unfounded in terms of being an undue amount of work.

--
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Guard is much more useful than you are thinking by SuperKendall · 2016-02-02 08:36 · Score: 3, Informative

Guard has the nice side effect of turning an optional into a non-optional, so that you can use a value through a whole method without having to unwrap (or worse, force unwrap) it.
without requiring the code-by-convention Disposable implementation
Frankly that sounds a lot clunkier to me than just having a nice defer block.
"repeat/while" is retarded and an unnecessary change away from well-known and accepted language conventions.
I don't know how long you've been programming but over the years I have run across times where I wanted to run through a loop at least once before checking the end condition, and had to contort a variety of things to accommodate a check at the top of the loop... I hardly think such a useful tool is retarded, when is serves so well in a specific niche.
Protocol extensions are nice, and are probably going to be quite useful in keeping your code readable. C# has had extension methods for a while now
They aren't really the same as extension methods you are talking about, because protocol extensions allow for default implementations that get overridden... both Swift and ObjC have had extensions on classes forever.
Swift protocol extensions are more like C# Abstract Classes. But you can have a class declare conformance to multiple protocols and so gain all of the methods from each, and furthermore you can in an extension on a class make any class implement a protocol and thus gain default protocol implementations...

--
"There is more worth loving than we have strength to love." - Brian Jay Stanley
7 Headlines Click-Seekers Will Love! by scratchy_king · 2016-02-02 10:39 · Score: 2

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
Re:Such a terrible article by Goaway · 2016-02-03 02:43 · Score: 1

They also have automatic migration tools to fix these things for you. In practice, it is not a problem.
Re:Swift is making Rust obsolete already! by Goaway · 2016-02-03 02:44 · Score: 1

I don't believe that apple will want swift to grow outside of the apple walled garden.
Yes, this is why they are porting it to Linux. Because they don't want people using it on Linux. This makes perfect sense.
Re: And then there's stribgs by BasilBrush · 2016-02-06 15:41 · Score: 1

Every language that is indexing into Unicode string is not handling composed characters correctly.