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.'
Next year (Score:1, Insightful)
Re: (Score:1)
I'm also not impressed with "guard". The article claims it makes for simpler and easier to maintain code, but I don't buy it. They say it avoids being if/else trees which, if true, would be a good thing. But you can have *simpler* code than "guard" by using if. For example, the following are equivalent:
guard validate(param) else { printError(); return; }
if not validate(param) { printError(); return; }
The "avoid if/else trees" is just a matter of returning from the function early. Guard in no way enables thi
Re: (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.
Re: (Score:2)
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
Re: (Score:3)
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.
Re: (Score:2)
Guard: http://ericcerney.com/swift-gu... [ericcerney.com]
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.
Re: (Score:3)
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.
Re: (Score:2)
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.
Re: (Score:2)
Because all the programming languages were declared frozen for all time after Kernighan & Ritchie. No further innovation will ever occur.
Re: (Score:2)
Blah blah blah hate Apple blah blah.
Re: (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.
Re: (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?
Re: (Score:2)
There are two differences between guard and if:
I haven't used them much myself, but guards aren't just a synonym for if-not.
Re: (Score:2)
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.
Re: (Score:2)
Nope you are still missing the scope of the unwrapping of optionals. This is also different.
Re: (Score:3)
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 bre
Guard is much more useful than you are thinking (Score:4, 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...
Re: (Score:2)
In fact you are right. From the swift-evolution repo [github.com]:
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.
That's been true all along (Score:2)
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.
Re: (Score:2)
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
Re: (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.
No actually it's not (Score:2)
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
Re: (Score:2)
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 an
Re: (Score:2)
>> 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 -
Re: (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 [youtube.com]
Introducing iSwift! (Score:2)
Re: (Score:2)
Yes, that horrible, horrible Apple. How dare they make their code BETTER!
WTF is "guard"? (Score:2)
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").
IF is an ugly word. (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.
Re: (Score:3)
Quite true. While "if" is an awful, tinny word, "guard" is nice and woody. You can't beat wood.
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
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 a
Re: (Score:2)
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.
Re: (Score:2)
I was going to say, it's sort of like an NSAssert.
Re: (Score:2)
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 (Score:3)
>> 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.
Re: (Score:2)
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
Re:This looks intentionally proprietary, Apple (Score:4, 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.
Re: This looks intentionally proprietary, Apple (Score:2)
1 title slashdoters will hate (Score:4)
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]
Re: (Score:2)
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.
Re: (Score:3)
7 most painful ways in which the editors should go fuck themselves.
Re: (Score:2)
I might click on that.
Re: (Score:3)
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?
Re: (Score:2)
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.
Re: (Score:2)
They also have automatic migration tools to fix these things for you. In practice, it is not a problem.
Re: (Score:2)
Re: (Score:2)
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.
Comment removed (Score:5, Insightful)
Re: (Score:1)
True, swift had been heavily influenced by Objective-C. Swift now serves the same goals Objective-C served, namely adding lock-in. It basically ports the improvements rust brings to the C++ world over to the Objective-C world.
Re: (Score:2)
not to mention it was their developers themselves who came up with Swift and pushed for its usage...not some CEO decree.
Re: (Score:2)
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.
Re: (Score:2)
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.
Dear Slashdot Admins (Score:1)
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.
Re: (Score:2)
Re: (Score:2)
Every language that is indexing into Unicode string is not handling composed characters correctly.
Open source doesn't mean much in this case (Score:2)
News for nerds? (Score:2)
"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...
More like hidden bug introducer (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
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"
Re: (Score:2)
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 [gobyexample.com]. I think it has its use -- in a language that doesn't support RAII. But I prefer the latter.
7 Headlines Click-Seekers Will Love! (Score:2)