Check out what’s new in Swift 3 - Swift’s first major release as an open source project.
This is a companion discussion topic for the original entry at https://www.raywenderlich.com/1094-what-s-new-in-swift-3
This is a companion discussion topic for the original entry at https://www.raywenderlich.com/1094-what-s-new-in-swift-3
I’m the most excited about new name “Swift 3”
Is it just me not being happy by SE-0046? That convention naming for functions was purely inherited by Obj-C, and I understand that Swift is moving forward, but that was the historical explanation whereby you in Swift and not in other C-like languages, had to put name labels when writing functions… Like
// Swift 2.2
SKAction.rotateByAngle(CGFloat(M_PI_2), duration: 10)
It’s inherited from Objective-C ([SKAction rotateByAngle:(CGFloat)M_PI_2 duration: 10];) where a function’s name and parameters are kinda mixed. After the name there may be eventually a parameter, and then other parameters, which are part of the global function name, and that’s why you can’t have 2 functions named same by name and parameters.
Now I find this more confusing
// Swift 3
SKAction.rotate(byAngle: CGFloat(M_PI_2), duration: 10)
It’s not anymore Objective-C compliant, at least not by itself. Also I was used to have only constructors have first explicit parameter, so when I had to type that I instantly knew it was a constructor, now instead the same syntax applies to normal functions.
Also, opinions apart, I don’t find this actually be improving the language in any way, it’s just a different convention.
What do you think?
@r0gerblack Including the first parameter name in a call makes the language easier to learn. In Swift 2.2, as a beginner, it adds cognitive overhead to understand why the first parameter is treated differently than the others.
Yeah but it was more compliant to all previous syntax specially Objective-C… Furtherly the more versions of Swift come, the more older Swift articles tend to give an uncompilable syntax
@r0gerblack That’s true, but the compiler is actually pretty awesome at offering Fix-Its for old API calls. So if you copy and paste some code, the compiler should offer to update it automatically.
Never happened to me when I pasted in old swift code. But if I got it good, it will be always be possible to use Swift 2.3 in Xcode 8 after iOS 10 GM/Official release or it can be used now just till Xcode 8 is beta?
@benmorrow Do you remember which session announced the following?
“By moving objects from the heap to the stack there was a 24x speedup (in some cases)”
I thought it was 24 times more likely for a class to sit in the heap, rather than 24 times faster.
Thanks!
Just want to point out:
GCD .asynchronously {} are updated to .async {}
@dazchong You’re correct! On [SE-0088] it looks like it is still .asynchronously {}. However, the change is referenced on the “accepted with revisions” mailing list message:
Rename the DispatchQueue.[a]synchronously methods to ".async” and ".sync”, to follow the term of art.
Also, you get a warning in Xcode 8 that you should use .async {} rather than .asynchronously {}. I changed the code in the article to reflect this.
1 Like
@kelvin_lau It’s at the end of What’s New in Swift. It seems like she is talking about a speed up for each change, but I might be mistaken. “We added stack promotion for class instances, array literals. Where we promote from the heap which is really expensive to the stack. And we see some really nice improvements when our tests take advantage of that.”
@benmorrow Yeah, But I’d learned that via my way to Swift 3 in XCode and didn’t check on the proposal yet.
What about the things that are being taken out of Swift? I saw the slide in the talk on Swift 3, but I wasn’t able to get a vary good look at it.
Sorry if this is a silly question, but it’s safe to assume that swift 3 will only be compatible with the new iteration of os’s? (Ios10 for example)
@calebkleveter This is the slide you mentioned here from the What’s New in Swift WWDC video. The ++ and C-Style for loops were deprecated in Swift 2.2. Since we had covered them back then, we left them out of this article.
@cmarti1138 The runtime is packaged with the app. So, yes, Swift 3 code will work on older operating systems back to iOS 7. However, you have to be careful with the API calls. An older version of iOS wouldn’t support the new APIs like SiriKit and iMessage Apps. Also, the Swift compiler in Xcode may no longer accept deprecated APIs from older iOS versions, which makes it hard to back port code to work with older iOS versions.
In general, agree with @r0gerblack’s comment on the “cognitive continuity” readability aspect, especially for those [many] of us still working in a mixed Obj-C/Swift domain. However, the “_” aka “forget the first parameter” option while somewhat of a pain provides us a means of preserving the original syntactic construct after some editing.
I agree with you! However I like the named first parameter. I would prefer a combination of the two where the name is descriptive and the first parameter is also named. Although wasteful, I find it very easily readable.:
// My Preferred Style SKAction.rotateByAngle(angle: CGFloat(M_PI_2), duration: 10)
This way the name of the function clearly indicated what you’re doing and the parameter name is reflective of the actual data stored in it.
angle is much more clear than a parameter named byAngle. Why should we name the angle byAngle?
That style is redundant… What I’d prefer most, would be the directly Obj-C style…
SKAction.rotateByAngle(CGFloat(M_PI_2), duration: 10)
As said, the new style is going to confuse me for a while since I was used to have a first explicit parameter only in constructors… now this is going to make harder distinguish constructor from a static function directly.
I’m trying this in Playground in Xcode 8 beta but
Self throws a compilation error as unresolved identifier.
struct CustomStruct {
static func staticMethod() {
print("static method...")
}
func instanceMethod() {
print("instance method...")
Self.staticMethod() // -- > unresolved identifier `Self`
}
}