If you haven’t looked at the Swift evolution proposals, I encourage you to head on over and take a look-see. At this time, there are four accepted proposals for Swift 3 and one for Swift 2.2, some of which may make you go “hmmmm”.
Of these, the most exciting are the API translation enhancements that aim to do away with ObjC-style verbosity, trimming calls down to slim, readable Swift.
Looks like we’ll be saying goodbye to direct func currying declarations although the same features will be available in-language without the shortcut syntax. It’s something I can live with but not something that makes me happy — but there seem to be compelling reasons to reduce language complexity.
The ++ and — (that is, minus-minus, not an em-dash, thanks lizamarley) operators are also on the chopping block, originally introduced for C-consistency but whose result values are not universally examined. For most devs, it’s not exactly hard to replace these with += and -=.
Finally, it looks like var function parameters will be removed as they create a confusing layer that abstracts away from the actual copy and modify steps in their implementation. I tend to think it’s not a huge loss as you’d just need to declare an in-func var assignment to replace this.
Interestingly enough, apart from the ++/– changes, nearly all of these ended up as special topics that I had covered in the cookbook.
The accepted Swift 2.2 proposal allows you to avoid backticking keywords used as argument labels, letting you now declare
func touchesMatching(phase: NSTouchPhase, in view: NSView?) -> Set<NSTouch>
Swift 3.0 promises ABI stability: “Successful ABI stabilization means that applications and libraries compiled with future versions of Swift can interact at a binary level with applications and libraries compiled with Swift 3.0, even if the source language changes.”
The dev team will take advantage of the opportunity to provide a type system cleanup, overall language refinement, and “complete” generic system. Migrators will move projects from 2.x into 3.x. Code bases are more or less guaranteed to break with this major update.
Guiding principles for the final API design are published here. (update: link fixed. Apple moved the guidelines.)
3 Comments
Appreciate how promptly you’re posting. Still processing the main content.
Minor copyedit: The minus-minus operator seems to be getting turned into an em-dash.
[…] Anyway, here’s the article. […]
I think that ++ and — should stay and MUST be implemented as faster operations than += and -=.They have very specific job after all and that is the general understanding. If you fail to implement them as faster operators that will really look as major weakness of SWIFT development team. Swift is still too slow – try working with Arrays so having these faster operators that are very commonly used will be a plus. Another plus will be that you will not break tons of existing code. Breaking existing code is always considered as an architecture weakness and always have a negative impact on the whole developers community – take a look at Microsoft for example they often do that mistake…. Android on the other hand is till that moment always building over the old (however they make other mistakes 😉