Slashdot Mirror
7 Swift 2 Enhancements iOS Devs Will Love
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.'
>> 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.
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]
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
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
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.
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."
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
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.
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
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