└── README.md /README.md: -------------------------------------------------------------------------------- 1 | ## This document is no longer maintained. 2 | 3 | 4 | With Swift [becoming open-source](https://swift.org) - and the [Swift Evolution] (https://github.com/apple/swift-evolution) document being public, this project was made mostly obsolete. However, it still serves as a historical account of Swift's initial evolution. 5 | 6 | ======== 7 | 8 | Swift InFlux 9 | =========== 10 | The community is creating some incredible analyses and writing about Swift. What I keep asking myself whenever learning and reading about Swift is: how likely is this to change soon? 11 | 12 | This document is an attempt to gather the Swift features that are still in flux and likely to change. 13 | 14 | ### Contributing 15 | To contribute: fork this project, add a section below (don't forget to update the Table of Contents!), and create a pull request. 16 | 17 | ### Credits 18 | 19 | Swift InFlux was created by [Karol S. Mazur](https://github.com/ksm) during [SwiftCrunch](http://swiftcrunch.com). It is maintained by the creator, and two great contributors: [Radek Pietruszewski](https://twitter.com/radexp) and [Jan Klausa](https://github.com/jklausa). 20 | 21 | ### Table of Contents 22 | 23 | * [Abstract methods](#abstract-methods) 24 | * [Access control](#limitations-of-current-access-control-design) 25 | * [ABI stability](#abi-stability) 26 | * [Better error handling](#better-error-handling-features-possibly-exceptions) 27 | * [Class variables](#class-variables) 28 | * [C++ support](#c-support) 29 | * [Dynamic dispatch of operators](#dynamic-dispatch-of-operators) 30 | * [Enumerating enum types](#enumerating-enum-types) 31 | * [Expanding scope of imported macros](#expanding-scope-of-imported-macros) 32 | * [Flow-sensitive optional unwrapping](#flow-sensitive-optional-unwrapping) 33 | * [Generic subscripts](#generic-subscripts) 34 | * [Imported constant macros carry explicit type](#imported-constant-macros-carry-explicit-type) 35 | * [Moving functionality from global functions to methods](#moving-functionality-from-global-functions-to-methods) 36 | * [Open source](#open-source) 37 | * [Optionals in imported Objective-C frameworks](#optionals-in-imported-objective-c-frameworks) 38 | * [Optional methods in pure-Swift protocols](#optional-methods-in-pure-swift-protocols) 39 | * [Overriding declarations from extensions](#overriding-declarations-from-extensions) 40 | * [Passing initializers as functions](#passing-initializers-as-functions) 41 | * [Reflection](#reflection) 42 | * [Runtime dynamic libraries](#runtime-dynamic-libraries) 43 | * [Static libraries](#static-libraries) 44 | * [`switch` and `if` as expressions](#switch-and-if-as-expressions) 45 | * [Systems programming features](#systems-programming-features) 46 | 47 | ___ 48 | 49 | * [Changed in Xcode 6.3 Beta 3](#changed-in-xcode-63-beta-3) 50 | 51 | * [Changed in Xcode 6.3 Beta 2](#changed-in-xcode-63-beta-2) 52 | * [Further enhancements to `if let`](#further-enhancements-to-if-let) 53 | 54 | * [Changed in Xcode 6.3 Beta 1](#changed-in-xcode-63-beta-1) 55 | * [Compiler improvements](#compiler-improvements) 56 | * [Nullability annotations in Objective-C](#nullability-annotations-in-objective-c) 57 | * [Enhancements to `if let`](#enhancements-to-if-let) 58 | * [Constants no longer require immediate initialization](#constants-no-longer-require-immediate-initialization) 59 | * [Importing Swift enums into Objective-C](#importing-swift-enums-into-objective-c) 60 | * [First-class `Set` type](#first-class-set-type) 61 | * [Xcode drops Mavericks support](#xcode-drops-mavericks-support) 62 | 63 | ___ 64 | 65 | * [Changed in Xcode 6.2](#changed-in-xcode-62) 66 | 67 | * [Changed in Xcode 6.1.1](#changed-in-xcode-611) 68 | 69 | * [Changed in Xcode 6.1 GM Seed 2 / 6.1](#changed-in-xcode-61-gm-seed-2--61) 70 | 71 | * [Changed in Xcode 6.1 Beta 3 / GM Seed 1](#changed-in-xcode-61-beta-3--gm-seed-1) 72 | * [`LiteralConvertible` protocols use constructor](#literalconvertible-protocols-use-constructor) 73 | * [Other](#other-changes-in-xcode-61-beta-3--gm-seed-1) 74 | 75 | * [Changed in Xcode 6.1 Beta 2](#changed-in-xcode-61-beta-2) 76 | * [Failable initializers in Objective-C frameworks](#failable-initializers-in-objective-c-frameworks) 77 | * [Redefinition of private entities](#redefinition-of-private-entities) 78 | * [Other](#other-changes-in-xcode-61-beta-2) 79 | 80 | * [Changed in Xcode 6.1 Beta 1](#changed-in-xcode-61-beta-1) 81 | * [Failable initializers](#failable-initializers) 82 | * [Other](#other-changes-in-xcode-61-beta-1) 83 | 84 | ___ 85 | 86 | * [Changed in Xcode 6.0 GM / 6.0.1](#changed-in-xcode-60-gm--601) 87 | 88 | * [Changed in Xcode 6.0 Beta 7](#changed-in-xcode-60-beta-7) 89 | 90 | * [Changed in Xcode 6.0 Beta 6](#changed-in-xcode-60-beta-6) 91 | * [Refinements to nil coalescing operator](#refinements-to-nil-coalescing-operator) 92 | * [Optionals in Foundation](#optionals-in-foundation) 93 | * [Boolean semantics of types](#boolean-semantics-of-types) 94 | * [Other](#other-changes-in-xcode-60-beta-6) 95 | 96 | * [Changed in Xcode 6.0 Beta 5](#changed-in-xcode-60-beta-5) 97 | * [`dynamic` keyword](#dynamic-declaration-modifier) 98 | * [Mutable optional value types](#mutable-optional-value-types) 99 | * [Nil coalescing operator](#nil-coalescing-operator) 100 | * [Attributes](#revised-attributes) 101 | * [Boolean semantics of optionals](#boolean-semantics-of-optionals) 102 | * [Ranges](#ranges-intervals-striding) 103 | * [Initializers](#required-and-designated-initializers-in-subclasses) 104 | * [Other](#other-changes) 105 | 106 | * [Changed in Xcode 6.0 Beta 4](#changed-in-xcode-60-beta-4) 107 | * [Access control](#access-control) 108 | * [Unicode string improvements](#unicode-string-improvements) 109 | * [Numerical data type conversion](#numerical-data-type-conversion-eg-cgfloat-and-swift-doubleswift-float) 110 | * [Revised declaration modifiers](#revised-declaration-modifiers) 111 | * [New stride() functions](#new-stride-functions) 112 | * [Set of legal operator characters](#set-of-legal-operator-characters) 113 | * [`@IBOutlet`](#iboutlet) 114 | * [Fixed: Structs with both @lazy and non-lazy properties crashes compiler](#fixed-structs-with-both-lazy-and-non-lazy-properties-crashes-compiler) 115 | * [Other changes to standard library](#other-changes-to-standard-library) 116 | 117 | * [Changed in Xcode 6.0 Beta 3](#changed-in-xcode-60-beta-3) 118 | * [Array and Dictionary type declaration syntax](#array-and-dictionary-type-declaration-syntax) 119 | * [Array value semantics](#array-value-semantics) 120 | * [Modifying constant properties in designated vs. convenience initializers](#modifying-constant-properties-in-designated-vs-convenience-initializers) 121 | * [Range operators](#range-operators) 122 | 123 | --- 124 | 125 | ### Abstract methods 126 | 127 | > FWIW, we already have many bugs tracking the idea of adding abstract methods to swift. We'll consider it in future releases, we understand the value :-) 128 | > 129 | > — Chris Lattner 130 | 131 | Source: https://devforums.apple.com/message/1006592#1006592 132 | 133 | ### Limitations of current access control design 134 | 135 | Swift [added access control](#access-control) in Xcode 6.0 Beta 4, but there are limitations to its design. Entities marked as `internal` (which is the default) are not visible to other build targets, which means that unit tests (which traditionally live in a separate target) can't access them. 136 | 137 | > We're aware that our access control design isn't great for unit testing (and this was in the release notes), we're evaluating the situation to see what we can do. 138 | > 139 | > — Chris Lattner 140 | > 141 | > A limitation of the access control system is that unit tests cannot interact with the classes and methods in an application unless they are marked public. This is because the unit test target is not part of the application module. 142 | > 143 | > — Xcode 6.0 beta 4 release notes 144 | 145 | At the moment, one workaround is to mark all tested entities as public, another is to move tests to the same target as the application code. However, the former ruins the benefits of access control and the latter — of code modularization. 146 | 147 | Sources: https://devforums.apple.com/message/1010766#1010766 [Xcode 6.0 Beta 4 release notes](http://ksm.github.io/SwiftInFlux/docs/beta4.pdf) 148 | 149 | ### ABI stability 150 | 151 | > Swift currently offers no ABI stability for any code and provides no ABI 152 | > non-fragility for framework authors. 153 | > 154 | > — Greg Parker 155 | > 156 | > gparker [Greg Parker] is right, and this is important. 157 | > 158 | > Swift 1.0 is not guaranteed to be binary compatible with "swift 2.0" (or 159 | > whatever). We guarantee that compiled and distributed *apps* and their 160 | > frameworks are binary compatible with the OS and will continue to work well 161 | > into the future, but a Swift framework today will not work in the future. 162 | > 163 | > We expect to lock this down, but not by the final release of swift this Fall. 164 | > This means that all swift code in an app (including frameworks it uses) should 165 | > be built by the same version of Xcode. 166 | > 167 | > — Chris Lattner 168 | 169 | Sources: https://devforums.apple.com/message/986618#986618 https://devforums.apple.com/message/989931#989931 170 | 171 | ### Better error handling features (possibly exceptions) 172 | 173 | >We're aware of the opportunity and also desire better error handling features in Swift, but they didn't make it in time for 1.0. 174 | > 175 | > — Chris Lattner 176 | 177 | Source: https://devforums.apple.com/thread/228324?start=50&tstart=0 178 | 179 | ### Class variables 180 | 181 | At the moment, stored class properties are not supported in Swift. They will come in a later release, but not in 1.0. Possibly, the main reason for this is that Swift largely depends on Objective-C runtime and implementation details, which don't support class variables. 182 | 183 | > Class variables not yet supported. 184 | > 185 | > — Swift compiler error 186 | > 187 | > The feature set for 1.0 is nearly final. 'yet' should not be taken to mean Swift 1.0. 188 | > 189 | > — Chris Lattner 190 | > 191 | > Swift in Xcode 6 will not support class variables. 192 | > 193 | > — Greg Parker 194 | 195 | Sources: https://devforums.apple.com/message/1022374#1022374 https://devforums.apple.com/message/1030167#1030167 196 | 197 | ### C++ support 198 | 199 | >This is another obviously desirable feature, it is just a lot of work and didn't make it in 1.0 either. 200 | > 201 | > — Chris Lattner 202 | 203 | Source: https://devforums.apple.com/thread/228324?start=50&tstart=0 204 | 205 | ### Dynamic dispatch of operators 206 | 207 | > FWIW, we're not happy with this either. Among other things, we've seen confusion where people define something like: 208 | > 209 | func ==(lhs : MyBaseClass, rhs : MyBaseClass) {...} 210 | func ==(lhs : MyDerivedClass, rhs : MyDerivedClass) {...} 211 | > 212 | > ... and are surprised when they don't get dynamic dispatch. 213 | > 214 | > We have not had a chance to fully revisit this, but it is very likely that we'll allow operators to be defined inside of types (i.e. as methods) as well as at global scope (necessary for mixed type operators). When defined as a non-final member of a class, these operators would be dynamically dispatched just like any other method. 215 | > 216 | > — Chris Lattner 217 | 218 | Source: https://devforums.apple.com/message/1074064#1074064 219 | 220 | ### Enumerating enum types 221 | 222 | > > Does anyone else think this would be fundamentally useful? Or is their a good way of apporaoching this in Swift currently that I'm missing? 223 | > 224 | > Yes. All of this would be super useful. We have a large number of radars asking for similar functionality, thanks! 225 | > 226 | > — Chris Lattner 227 | 228 | Source: https://devforums.apple.com/message/1003674#1003674 229 | 230 | ### Expanding scope of imported macros 231 | 232 | Swift currently only imports simple constant-like macros from C and Objective-C. 233 | This leaves many key macros unaccessible to Swift, requiring redefinition. For 234 | example, the `CPU_TYPE` constant type cast macros in `mach/machine.h`. 235 | 236 | ```c 237 | #define CPU_TYPE_X86 ((cpu_type_t) 7) 238 | ``` 239 | 240 | > It's hard to nail Apple down as to what we will or won't do, but I think it's 241 | > safe to say that improving the way that Swift imports C / Objective-C headers 242 | > is an important goal. 243 | > 244 | > — eskimo1 245 | 246 | > Indeed. Improving the experience using imported C/Objective-C APIs is a strong 247 | > goal for ongoing swift evolution. 248 | > 249 | > — Chris Lattner 250 | 251 | Sources: 252 | 253 | - https://devforums.apple.com/message/1122873#1122873 254 | - https://devforums.apple.com/message/1123733#1123733 255 | 256 | ### Flow-sensitive optional unwrapping 257 | 258 | It has been suggested that optional types could be implicitly unwrapped in the context of an if-statement checking if an optional has a value, for example: 259 | 260 | ```swift 261 | let x: Type? 262 | 263 | if exists x { 264 | x.doSomething() // works without ? or ! 265 | } 266 | ``` 267 | 268 | > We're definitely aware of the advantages of control-flow sensitive type refinement for optionals (and also for other subtype relationships). This would be particularly handy in ternary operators, but isn't something on the books for 1.0. We have several radars requesting that and tracking it for consideration in a future release. 269 | > 270 | > — Chris Lattner 271 | > 272 | > Flow-sensitive type refinement like this is something that may happen in a future release of Swift 273 | > 274 | > — CFM 275 | 276 | Source: https://devforums.apple.com/message/1005148#1005148 https://devforums.apple.com/message/1066436#1066436 277 | 278 | ### Generic subscripts 279 | 280 | > Lack of generic subscripts is a known limitation. We'll look at improving this at some point when it bubbles up in the priority list. 281 | > 282 | > — Chris Lattner 283 | 284 | Currently, generic subscripts are allowed only for generic types (e.g. `Array`, `Dictionary`). 285 | 286 | Source: https://devforums.apple.com/message/1100335#1100335 287 | 288 | ### Imported constant macros carry explicit type 289 | 290 | Since Swift does not allow implicit type conversion, imported constant C and 291 | Objective-C macros lose a bit of flexibility in use as they carry an explicit 292 | type (Swift has no preprocessor). For example, `M_PI` from `math.h` is imported 293 | as a double. 294 | 295 | > FWIW, we consider it to be a bug that M_PI (and a variety of other imported constants) get an arbitrary fixed type assigned to them. This affects integer constants just as much as floating point ones. 296 | > 297 | > In principle, there could be a way to provide "typeless named literals" in the language, and constants imported from C macros could be imported like that. I don't know if that's the approach we'll take, but it is one of several different options we'll evaluate down the road to improve this situation. 298 | > 299 | > — Chris Lattner 300 | 301 | Source: https://devforums.apple.com/message/1032523#1032523 302 | 303 | ### Moving functionality from global functions to methods 304 | 305 | > We'll have to evaluate this in more detail when we have time to explore the design space, but here are some thoughts: 306 | > 307 | > We'd prefer to build out the language to allow more things to be methods, instead of more things as global functions. In general, methods are better than global functions because they work better for code completion, and scoped better, and more consistent with other methods. 308 | > 309 | > We currently have limitations in the type system and implementation that force some things (e.g. countElements and many others) to be global functions instead of methods, but we consider this a deficiency, not a feature. 310 | > 311 | > — Chris Lattner 312 | > 313 | > The prevalence of generic free functions is more about current language limitations than an intentional stylistic direction 314 | > 315 | > — CFM 316 | 317 | Source: https://devforums.apple.com/message/1074064#1074064 https://devforums.apple.com/message/1094312#1094312 318 | 319 | ### Open source 320 | 321 | Swift will be going open source late 2015 once Apple has shipped the 2.0 GM 322 | version of the language (Fall). The details that Apple has provided on this so 323 | far are: 324 | 325 | - Source code for the Swift compiler and standard library will be released under 326 | an [OSI](http://opensource.org)-approved permissive license 327 | - Ports for OS X, iOS, and Linux with be provided 328 | - Contributions will be accepted 329 | 330 | > Guys, feel free to make up your own dragons if you want, but your speculation 331 | > is just that: speculation. We literally have not even discussed this yet, 332 | > because we have a ton of work to do to respond to the huge volume of feedback 333 | > we're getting, and have to get a huge number of things (e.g. access control!) 334 | > done before the 1.0 release this fall. You can imagine that many of us want 335 | > it to be open source and part of llvm, but the discussion hasn't happened yet, 336 | > and won't for some time. 337 | > 338 | > Sorry to leave you all hanging, but there is just far too much to deal with 339 | > right now. 340 | > 341 | > — Chris Lattner 342 | 343 | Sources: 344 | 345 | - http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-June/073698.html 346 | - https://developer.apple.com/swift/blog/?id=29 347 | 348 | ### Optionals in imported Objective-C frameworks 349 | 350 | As of Xcode 6.3, relatively few APIs have been audited for optional conformance. There has been considerable progress since early Xcode 6 betas and more improvements are expected to come in the future. 351 | 352 | Since Xcode 6.3, it is possible for users to [annotate nullability](#nullability-annotations-in-objective-c) (optionality) of Objective-C APIs. 353 | 354 | > A large number of AppKit APIs have been audited for optional conformance in addition to WebKit, Foundation, UIKit, CoreData, SceneKit, SpriteKit, and Metal APIs. As a result, a significant number of implicitly unwrapped optionals have been removed from their interfaces. These changes clarify the nullability of properties, arguments, and return values in the APIs. The audit effort is ongoing. 355 | > 356 | > The API changes replace T! with either T? or T depending on whether or not the value can be null, respectively. 357 | > 358 | > — Xcode 6.1 release notes 359 | 360 | Sources: [Xcode 6.1 release notes](https://developer.apple.com/library/ios/releasenotes/DeveloperTools/RN-Xcode/Chapters/xc6_release_notes.html#//apple_ref/doc/uid/TP40001051-CH4-SW1) 361 | 362 | ### Optional methods in pure-Swift protocols 363 | 364 | > Optional methods in protocols are limited to @objc protocols only because we haven't implemented them in native protocols yet. This is something we plan to support. We've gotten a number of requests for abstract/pure virtual classes and methods too. 365 | > 366 | > — Joe Groff 367 | 368 | Source: https://devforums.apple.com/message/1051431#1051431 369 | 370 | ### Overriding declarations from extensions 371 | 372 | At the moment, it's not possible to override entities declared in extension by subclassing, like so: 373 | 374 | ```swift 375 | class Base { } 376 | 377 | extension Base { 378 | var foo: String { return "foo" } 379 | } 380 | 381 | class Sub: Base { 382 | override var foo: String { return "FOO" } // This is an error 383 | } 384 | ``` 385 | 386 | Note: it is possible to override entities from extensions [if they are marked as `@objc`](http://stackoverflow.com/a/27109202/195691), but it's likely to be an accidental side-effect of Objective-C runtime implementation and it might break in the future. 387 | 388 | > Declarations from extensions cannot be overriden yet. 389 | > 390 | > — Swift compiler error 391 | > 392 | > The feature set for 1.0 is nearly final. 'yet' should not be taken to mean Swift 1.0. 393 | > 394 | > — Chris Lattner 395 | 396 | Source: https://devforums.apple.com/message/1022374#1022374 397 | 398 | ### Passing initializers as functions 399 | 400 | > > [Is there any] specific reason why you can't reference initializers like a function? 401 | > 402 | > No particular reason, it's just not implemented. 403 | > 404 | > — Joe Groff 405 | 406 | Referencing initializers to pass as an argument would be useful for [currying](http://www.objc.io/snippets/6.html). 407 | 408 | Source: https://twitter.com/jckarter/status/542032426298392576 409 | 410 | ### Reflection 411 | 412 | At the moment, Swift has only very limited reflection capabilities. In addition to built-in syntax for checking variable types, there's a `reflect()` function that can tell the names an types of object's properties. It is, however, poorly documented. It's unclear whether or not reflection capabilities will be expanded in future releases. 413 | 414 | Further reading: [Simple Reflection in Swift](http://freecake.yayuhh.com/simple-reflection-in-swift/) 415 | 416 | > Though it’s not documented in the Swift Standard Library Reference — and is subject to change, and could disappear entirely — Swift has a reflection API. 417 | > 418 | > — Brent Simmons 419 | 420 | Sources: http://inessential.com/2014/07/13/swift_reflection https://gist.github.com/peebsjs/9288f79322ed3119ece4 421 | 422 | ### Runtime dynamic libraries 423 | 424 | > Products that use Swift need to come with their own copies of the swift 425 | > runtime. This is currently necessary for a variety of reasons. Xcode directly 426 | > supports this for the following scenarios: 427 | > 428 | > - When you build an application that uses Swift, Xcode will automatically 429 | > embeds the swift runtime dynamic libraries inside the app wrapper in the 430 | > Frameworks folder. Application targets should also be automatically 431 | > configured with rpath entries that will locate them there. 432 | > - When you build a command line tool that uses Swift, Xcode will statically 433 | > link the swift runtime into the command line tool's binary 434 | > - When you build other product types (e.g. frameworks or app extensions) that 435 | > use Swift, they are set up to expect to find the swift libraries embedded 436 | > in the application that they are themselves embedded in 437 | > 438 | > — mferris 439 | 440 | This is done for several reasons: 441 | 442 | > Swift's runtime and libraries are not (yet) included in the operating system, 443 | > so must be included in each app. 444 | > 445 | > — CFM 446 | > 447 | > The runtime is bundled with your app in order to prevent incompatible language 448 | > changes from affecting deployed apps. Changes to the language, runtime 449 | > implementation, or how frameworks get imported won't affect your 450 | > already-compiled app — any ABI-level dependencies are between the runtime 451 | > dylibs in your bundle and the main executable. 452 | > 453 | > — Joe Groff 454 | 455 | Given this, you will hit issues if your are creating an OS X command line tool 456 | that uses a framework written in Swift. 457 | 458 | > In your case, the swift standard libraries are being statically linked into 459 | > your command line tool. The problem is that the framework cannot see that, and 460 | > it expects to find them in an app wrapper that it is inside of. Xcode 461 | > currently has no direct support for a standalone framework using swift that is 462 | > not embedded in an application. 463 | > 464 | > — mferris 465 | 466 | Sources: 467 | 468 | - https://devforums.apple.com/message/1038413#1038413 469 | - https://devforums.apple.com/message/1003269#1003269 470 | - https://devforums.apple.com/message/1057293#1057293 471 | 472 | ### Static libraries 473 | 474 | > Xcode does not support building static libraries that include Swift code. 475 | > 476 | > — Xcode 6.0 beta 5 release notes 477 | > 478 | > The current runtime doesn't ship with the OS, so static libs would lead to multiple runtimes in the final executable. A statically linked runtime would be much more difficult to patch for compatibility with newer OS or Swift. 479 | > 480 | > — Joe Groff 481 | 482 | Sources: [Xcode 6.0 Beta 5 release notes](http://ksm.github.io/SwiftInFlux/docs/beta5.pdf) https://twitter.com/jckarter/status/555061575623507969 483 | 484 | ### `switch` and `if` as expressions 485 | 486 | > We're aware that 'switch' and 'if' are commonly expressions in functional languages, and that this brings a lot of convenience. We'll consider expanding this in future releases, but it isn't a short term priority for Swift 1.1. 487 | > 488 | > -Chris 489 | 490 | Source: https://devforums.apple.com/message/1040049#1040049 491 | 492 | ### Systems Programming Features 493 | 494 | > The focus of Swift 1.0 is definitely on improving general app development, but we do expect Swift to grow capabilities (e.g. perhaps even the ability to write inline assembly code) that allow it to fully span the gamut of programming: from writing the lowest level firmware up to the highest level application programming. We prefer to do this carefully and deliberately over time, rather than attempting to solve all the world's problems at once. 495 | > 496 | > — Chris Lattner 497 | 498 | Source: https://devforums.apple.com/message/1007178#1007178 499 | 500 | ___ 501 | 502 | ## Changed in Xcode 6.3 Beta 3 503 | 504 | * [Xcode Release Notes](http://ksm.github.io/SwiftInFlux/docs/6.3-beta3.pdf) 505 | * [SwiftDoc.org post](http://swiftdoc.org/news/2015/03/updated-for-swift-1.2b3/) 506 | * [Swiftlib changes post on Airspeed Velocity](http://airspeedvelocity.net/2015/03/13/changes-to-the-swift-standard-library-in-1-2-betas-2-and-3/) 507 | * [Standard library header diff](https://github.com/radex/swift_stdlib/commit/71e6f580528ee2d7a099e9b9bbed87775560ca5b) 508 | 509 | ## Changed in Xcode 6.3 Beta 2 510 | 511 | * [Xcode Release Notes](http://ksm.github.io/SwiftInFlux/docs/6.3-beta2.pdf) 512 | * [Playgrounds improvements on the official Swift blog](https://developer.apple.com/swift/blog/?id=24) 513 | * [Swiftlib changes post on Airspeed Velocity](http://airspeedvelocity.net/2015/03/13/changes-to-the-swift-standard-library-in-1-2-betas-2-and-3/) 514 | * [Standard library header diff](https://github.com/radex/swift_stdlib/commit/306c91a82982580cea56b2b86d26ee2671125390) 515 | 516 | ### Further enhancements to `if let` 517 | 518 | Following the changes in [Beta 1](#enhancements-to-if-let), the `if let` syntax has been extended to allow a boolean condition preceding a `let` clause. For example: 519 | 520 | ```swift 521 | if loggingEnabled, let samples = getLogSamples() where samples.count > 10 { 522 | sendLogSamples(samples) 523 | } 524 | ``` 525 | 526 | ## Changed in Xcode 6.3 Beta 1 527 | 528 | Xcode 6.3 brings a large number of changes, bug fixes and new features to Swift, which is now version 1.2. 529 | 530 | More information: 531 | * [Post on official Swift Blog](https://developer.apple.com/swift/blog/?id=22) 532 | * [Xcode Release Notes](http://ksm.github.io/SwiftInFlux/docs/6.3-beta1.pdf) 533 | * [Standard library header diff](https://github.com/radex/swift_stdlib/commit/1014c4b251019eabe0056a3d8e90818a9a1b20c3.patch) 534 | * [Changes to Swift Standard Library](http://airspeedvelocity.net/2015/02/11/changes-to-the-swift-standard-library-in-1-2-beta-1/) on Airspeed Velocity 535 | * [SwiftDoc.org post](http://swiftdoc.org/news/2015/02/swift1.2/) 536 | * [Fixed Swift compiler crashes](https://github.com/practicalswift/swift-compiler-crashes/commit/f6da30450923afbc313fbcac16a5367c3f88aec3) 537 | 538 | ### Compiler improvements 539 | 540 | According to the Swift team, the compiler got a lot of under-the-hood improvements, which give us: 541 | 542 | * **Incremental builds** — files that haven't changed won't have to be recompiled every time, speeding up the process 543 | * **Faster executables** — Swift binary code is now better optimized, both in Release and Debug modes. 544 | * **Better diagnostics** — Clearer warning and error messages, as well as new fix-its 545 | * **Stability improvements** — less compilation and SourceKit crashes. 546 | - according to swift-compiler-crashes, 83% of crashing bugs (4200 crashes) [have been fixed](https://github.com/practicalswift/swift-compiler-crashes/commit/f6da30450923afbc313fbcac16a5367c3f88aec3) in this beta 547 | 548 | ### Nullability annotations in Objective-C 549 | 550 | You can now mark method and function parameters, return types, properties and variables in Objective-C as non-nullable (imported to Swift as `T`) or nullable (imported as `T?`). In Objective-C declarations, you can use new `nonnull` and `nullable` qualifiers before the type, for example: 551 | 552 | ```objc 553 | -(nullable UITableViewCell *)cellForRowAtIndexPath:(nonnull NSIndexPath)indexPath; 554 | ``` 555 | 556 | Same keywords can be used with Objective-C property configuration: 557 | 558 | ```objc 559 | @property (nonatomic, readwrite, retain, nullable) UIView *backgroundView; 560 | ``` 561 | 562 | Arbitrary C pointers, block pointers and C++ member pointers can be marked using `__nonnull` and `__nullable`, like so: 563 | 564 | ```c 565 | void enumerateStrings(__nonnull CFStringRef (^ __nullable callback)(void)); 566 | ``` 567 | 568 | This will be imported as: 569 | 570 | ```swift 571 | func enumerateStrings(callback: (() -> CFString)?) 572 | ``` 573 | 574 | ### Enhancements to `if let` 575 | 576 | The `if let` construct can now be used to optionally unwrap multiple optionals at once. You can also add a guarding condition with `where`: 577 | 578 | ```swift 579 | if let a = foo(), b = bar() where a < b, 580 | let c = baz() { 581 | } 582 | ``` 583 | 584 | ### Constants no longer require immediate initialization 585 | 586 | In Xcode 6.2 and before, constants defined using `let` had to be immediately assigned a value. The new rule is that a constant must be initialized before use (and, of course, it must not be reassigned or mutated later). 587 | 588 | This allows patterns like: 589 | 590 | ```swift 591 | let x: SomeThing 592 | if condition { 593 | x = foo() 594 | } else { 595 | x = bar() 596 | } 597 | use(x) 598 | ``` 599 | 600 | In previous versions this would require using `var`, even though no mutation is taking place. 601 | 602 | ### Importing Swift enums into Objective-C 603 | 604 | Simple enums (not using generics or associated values) can now be exported to Objective-C by marking them as `@objc` and setting `Int` as the raw value. For instance: 605 | 606 | ```swift 607 | @objc enum Bear: Int { 608 | case Black, Grizzly, Polar 609 | } 610 | ``` 611 | 612 | imports into Objective-C as: 613 | 614 | ```objc 615 | typedef NS_ENUM(NSInteger, Bear) { 616 | BearBlack, BearGrizzly, BearPolar 617 | }; 618 | ``` 619 | 620 | ### First-class `Set` type 621 | 622 | The Swift standard library now includes a fully generic `Set` type that bridges to `NSSet` and has value semantics. 623 | 624 | ### Xcode drops Mavericks support 625 | 626 | > Xcode 6.3 does require Yosemite, as mentioned in the release notes. This will 627 | > not be changed in a later beta. 628 | > 629 | > — Chris Lattner 630 | 631 | Swift can still target Mavericks (10.9), but Xcode itself will no longer support 632 | it. 633 | 634 | Source: https://devforums.apple.com/message/1101275#1101275 635 | 636 | ___ 637 | 638 | ## Changed in Xcode 6.2 639 | 640 | Xcode 6.2 doesn't include any significant changes to Swift except for [nullability audit](#optionals-in-imported-objective-c-frameworks) of the WatchKit framework. 641 | 642 | > Yeah, 6.2's (almost) all about WatchKit. 643 | > 644 | > — Joe Groff 645 | 646 | Sources: https://devforums.apple.com/message/1074584#1074584 https://devforums.apple.com/message/1082641#1082641 https://twitter.com/jckarter/status/555059438944387072 647 | 648 | ## Changed in Xcode 6.1.1 649 | 650 | Xcode 6.1.1 was a maintenance release with only minor improvements and bug fixes to Swift, including: 651 | 652 | * Passing class objects for pure Swift class to `AnyObject` values no longer causes a crash 653 | * Class methods and initializers that satisfy protocol requirements now properly invoke subclass overrides when called in generic contexts 654 | * Some causes of SourceKit crashes have been fixed 655 | * Minor changes to [nullability](#optionals-in-imported-objective-c-frameworks) in Objective-C frameworks. 656 | 657 | There have been [no changes to the standard library header](https://github.com/radex/swift_stdlib/commit/aa038f863d2ec866c7452ecbf68a4f71f5894eca) and [no significant compiler crash fixes](https://github.com/practicalswift/swift-compiler-crashes/commit/404c6243194383c09585ee64ad2ae2d940c37459). 658 | 659 | There have been [no significant differences](https://devforums.apple.com/message/1079865#1079865) between the 6.1.1 GM seed and the final version. 660 | 661 | Source: [Xcode 6.1.1 Release Notes](https://developer.apple.com/library/ios/releasenotes/DeveloperTools/RN-Xcode/Chapters/Introduction.html#//apple_ref/doc/uid/TP40001051) 662 | 663 | ## Changed in Xcode 6.1 GM Seed 2 / 6.1 664 | 665 | GM Seed 2 doesn't appear to have any developer-facing changes ([no changes to the standard library](https://github.com/radex/swift_stdlib/commit/6350539ae8f8a3712c214258f26180cfe97d6759#commitcomment-8090096)), but it brings a number of bug fixes to the Swift compiler. 666 | 667 | * [Fixed compiler crashes](https://github.com/practicalswift/swift-compiler-crashes/commit/768c5bdfa21e01e286022a75e9586f1df8b7012d) 668 | * [Xcode release notes](http://ksm.github.io/SwiftInFlux/docs/6.1-gm-seed2.pdf) 669 | 670 | The final version of Xcode 6.1 doesn't seem to have any changes in Swift compiler or standard library since GM Seed 2, however there have been minor updates to [optional conformance](#optionals-in-imported-objective-c-frameworks) in iOS and OS X SDKs. 671 | 672 | * [Xcode release notes](https://developer.apple.com/library/ios/releasenotes/DeveloperTools/RN-Xcode/Chapters/xc6_release_notes.html#//apple_ref/doc/uid/TP40001051-CH4-SW1) 673 | 674 | ## Changed in Xcode 6.1 Beta 3 / GM Seed 1 675 | 676 | Beta 3 brought a number of standard library changes and compiler bug fixes, but most importantly, a huge amount of new documentation comments was added to the stdlib header. 677 | 678 | * [Standard library diff](https://github.com/radex/swift_stdlib/commit/41b16dcb61fc8dba15ee6385777dc6c2daadcc51.diff) 679 | * [Fixed compiler crashes](https://github.com/practicalswift/swift-compiler-crashes/commit/c3c374d3ff3c9a6d8864537550529d12d19a4abb) 680 | * [Xcode release notes](http://ksm.github.io/SwiftInFlux/docs/6.1-beta3.pdf) 681 | * [Airspeed Velocity](http://airspeedvelocity.net/2014/10/01/changes-to-the-swift-standard-library-in-1-1-beta-3/) 682 | 683 | Beta 3 was renamed to "GM seed" shortly after release to indicate that the OS X SDK is GM (and you can use it to ship Yosemite apps). It is not the final seed of Xcode 6.1. 684 | 685 | > The nomenclature is admittedly confusing here. I'd recommend that you ignore the label, and work with a functional description: 686 | > 687 | > What you need to know: 688 | > - Xcode 6.1b3 has been renamed on the website to GM Seed, to indicate that you can use it to build and submit apps to the Mac App Store, using the Yosemite SDK. 689 | > - This beta includes the iOS 8.1 beta SDK, but you cannot submit apps to the iOS app store with this Xcode build. 690 | > - Further updates of 6.1 are expected before the "final GM seed" is released on the Mac App Store. 691 | > 692 | > — [Chris Lattner](https://devforums.apple.com/message/1052305#1052305) 693 | 694 | ### `LiteralConvertible` protocols use constructor 695 | 696 | Objects implementing the various `LiteralConvertible` protocols need to implement an `init` method instead of a class method. 697 | 698 | For example: 699 | 700 | ```swift 701 | protocol BooleanLiteralConvertible { 702 | typealias BooleanLiteralType 703 | init(booleanLiteral value: BooleanLiteralType) 704 | } 705 | ``` 706 | 707 | ### Other changes in Xcode 6.1 Beta 3 / GM Seed 1 708 | 709 | * `Any` can now refer to functions. 710 | 711 | ## Changed in Xcode 6.1 Beta 2 712 | 713 | ### Failable initializers in Objective-C frameworks 714 | 715 | Objective-C `init` and factory methods are now imported as [failable initializers](#failable-initializers) to explicitly signal that they might return `nil`. Most initializers are automatically imported as `init!` (subject to [auditing for optional conformance](#optionals-in-imported-objective-c-frameworks) in later releases), however methods that take a `NSError**` parameter are always imported as `init?`. 716 | 717 | For example: 718 | 719 | ```swift 720 | init?(contentsOfFile path: String, encoding: NSStringEncoding, error: NSErrorPointer) 721 | ``` 722 | 723 | Source: [Xcode 6.1 Beta 2 release notes](http://ksm.github.io/SwiftInFlux/docs/6.1-beta2.pdf) 724 | 725 | ### Redefinition of private entities 726 | 727 | It's now possible to redefine private entities (functions, classes, global variables…) with the same name and type in different files. Previously, the compilation would fail because the linker couldn't tell them apart. 728 | 729 | Source: [Xcode 6.1 Beta 2 release notes](http://ksm.github.io/SwiftInFlux/docs/6.1-beta2.pdf) 730 | 731 | ### Other changes in Xcode 6.1 Beta 2 732 | 733 | * Mac apps can now apply `@NSApplicationMain` attribute to their app delegate class to generate an implicit `main` function for the app. (This works like `@UIApplicationMain` on iOS) 734 | * The `fromRaw()` static method in enums that have raw values has been replaced with a failble `init?(rawValue:)` initializer. Also, `toRaw()` method has been replaced with `rawValue` property. 735 | Example: 736 | 737 | ```swift 738 | enum Foo: Int { case A = 0, B = 1, C = 2 } 739 | let foo = Foo(rawValue: 2)! // formerly 'Foo.fromRaw(2)!' 740 | println(foo.rawValue) // formerly 'foo.toRaw()' 741 | ``` 742 | * Nested functions that recursively reference themselves or other functions inside the same outer function will no longer crash the compiler. 743 | 744 | Source: [Xcode 6.1 Beta 2 release notes](http://ksm.github.io/SwiftInFlux/docs/6.1-beta2.pdf) 745 | 746 | 747 | ## Changed in Xcode 6.1 Beta 1 748 | 749 | ### Failable initializers 750 | 751 | Initializers can now fail by returning `nil`. A failable initializer is declared with `init?` to return an 752 | explicit optional or `init!` to return an implicitly unwrapped optional. For example, you could 753 | implement `String.toInt` as a failable initializer of `Int` like this: 754 | 755 | ```swift 756 | extension Int { 757 | init?(fromString: String) { 758 | if let i = fromString.toInt() { 759 | // Initialize 760 | self = i 761 | } else { 762 | // Discard self and return 'nil'. 763 | return nil 764 | } 765 | } 766 | } 767 | ``` 768 | 769 | The result of constructing a value using a failable initializer then becomes optional: 770 | 771 | ```swift 772 | if let twentytwo = Int(fromString: "22") { 773 | println("the number is \(twentytwo)”) 774 | } else { 775 | println("not a number”) 776 | } 777 | ``` 778 | 779 | In the current implementation, `struct` and `enum` initializers can return `nil` at any point inside 780 | the initializer, but class initializers can only return `nil` after all of the stored properties of the 781 | object have been initialized and `self.init` or `super.init` has been called. If `self.init` or 782 | `super.init` is used to delegate to a failable initializer, then the `nil` return is implicitly 783 | propagated through the current initializer if the called initializer fails. 784 | 785 | > FWIW, the most common use-case for failable initializers will be with imported Cocoa APIs (e.g. loading a UIImage that can fail). Beta 1 doesn't import Cocoa APIs to use failable initializers, but that will be addressed "soon" in the next 6.1 beta. 786 | > 787 | > — Chris Lattner 788 | 789 | Source: [Xcode 6.1 Beta 1 release notes](http://ksm.github.io/SwiftInFlux/docs/6.1-beta1.pdf), https://devforums.apple.com/message/1042776#1042776 790 | 791 | 792 | ### Other changes in Xcode 6.1 Beta 1 793 | 794 | Beta 1 has very few developer-facing changes in the standard library: 795 | 796 | * `compare` method on `String` is removed 797 | * `StaticString`'s `start` was renamed to `utf8String`, there's also a new `withUTF8Buffer` method and `unicodeScalar` property 798 | * `StrideTo` and `StrideThrough` are now `Reflectable` 799 | * `AssertString` and `StaticString` are now `Printable` and `DebugPrintable` 800 | * New `unsafeAddressOf` function that can be used to identify objects 801 | 802 | **Further reading**: 803 | 804 | * [Airspeed Velocity](http://airspeedvelocity.net/2014/09/10/changes-to-the-swift-standard-library-in-xcode-6-1/) 805 | * [Xcode release notes](http://ksm.github.io/SwiftInFlux/docs/6.1-beta1.pdf) 806 | 807 | ___ 808 | 809 | ## Changed in Xcode 6.0 GM / 6.0.1 810 | 811 | Xcode 6 GM had no developer-facing Swift changes compared to Beta 7. The golden master was then officially released as 6.0.1 (not 6.0) with no changes to the Swift compiler 812 | 813 | ## Changed in Xcode 6.0 Beta 7 814 | 815 | _This section needs expanding. [Please contribute.](#contribute)_ 816 | 817 | ## Changed in Xcode 6.0 Beta 6 818 | 819 | ### Refinements to nil coalescing operator 820 | 821 | Xcode 6.0 Beta 6 improves on the [nil coalescing operator](#nil-coalescing-operator) introduced last Beta. It's now possible to pass an optional as the righthand side operand — if both sides evaluate to nil, the whole expression evaluates to nil. This makes it possible to chain expressions using nil coalescing, like so: 822 | 823 | ```swift 824 | let a: Int? = nil 825 | let b: Int? = nil 826 | 827 | a ?? b ?? 0 828 | ``` 829 | 830 | In the example above, the first chained expression that doesn't evaluate to `nil` will be used as the value of the entire operation. 831 | 832 | Previously, passing a non-optional value as the second operand to `??` was technically valid, but its semantics were [very confusing](http://airspeedvelocity.net/2014/08/12/yo-dawg/) 833 | 834 | Sources: [Xcode 6.0 Beta 6 release notes](http://ksm.github.io/SwiftInFlux/docs/beta6.pdf), [Airspeed Velocity](http://airspeedvelocity.net/2014/08/12/yo-dawg/) 835 | 836 | ### Optionals in Foundation 837 | 838 | > A large number of Foundation APIs have been audited for optional conformance, removing a significant number of implicitly unwrapped optionals from their interfaces. This clarifies the nullability of their properties and arguments / return values of their methods. This is an ongoing effort since beta 5. 839 | > 840 | > These changes replace T! with either T? or T depending on whether the value can be null (or not) respectively. 841 | 842 | Source: [Xcode 6.0 Beta 6 release notes](http://ksm.github.io/SwiftInFlux/docs/beta6.pdf) 843 | 844 | ### Boolean semantics of types 845 | 846 | Implicitly unwrapped optionals no longer conform to `BooleanType`, which means that they now have to be explicitly compared to `nil` in if statements. (This follows an equivalent change to `Optional` [last beta](#boolean-semantics-of-optionals)) 847 | 848 | Meanwhile, non-optional types may no longer be compared to `nil`. 849 | 850 | Source: [Xcode 6.0 Beta 6 release notes](http://ksm.github.io/SwiftInFlux/docs/beta6.pdf) 851 | 852 | ### Other changes in Xcode 6.0 Beta 6 853 | 854 | * The `+` operator can no longer append a `Character` to `String`, clarifying that `+` is only for concatenation. (This is analogous to appending an element to an array which was [removed in Xcode 6.0 Beta 5](#other-changes)) 855 | * `Optional.hasValue` was removed 856 | * `RawOptionSetType` (used by imported `NS_OPTIONS`) now supports bitwise assignment operators 857 | * One-element tuples can no longer have a label. In practice, that means that an enum case that stores one value cannot have a label ([this will be fixed](#enumeration-case-value-labels)). 858 | * Messages in `assert` calls can now use string interpolation 859 | * New `precondition()` function. It works similarly to `assert()` (takes a condition and stops the program if it's `false`), however unlike `assert`s, `precondition`s aren't disabled in Release mode builds. (They will be stripped, however, if the application is compiled with `-Ounchecked` setting) 860 | * Arbitrary implicit conversions between types using `__conversion() -> T` was removed. It's now only possible to add implicit conversions from value literals [using language-defined protocols](http://nshipster.com/swift-literal-convertible/). 861 | 862 | Further reading: 863 | 864 | * [Xcode 6.0 Beta 6 release notes](http://ksm.github.io/SwiftInFlux/docs/beta6.pdf) 865 | * [Airspeed velocity](http://airspeedvelocity.net) 866 | 867 | ## Changed in Xcode 6.0 Beta 5 868 | 869 | ### `dynamic` declaration modifier 870 | 871 | `dynamic` is a new attribute that can be applied to properties, methods, subscripts and initializers to make all references to them dynamically dispatched (like message passing in Objective-C). This enables KVO, proxying, swizzling and other advanced Cocoa features to work with Swift. 872 | 873 | Before Xcode 6.0 Beta 5, classes marked with `@objc` (or inheriting from `NSObject`) got the benefits of `dynamic` "for free", while non-`@objc` classes couldn't access dynamic dispatch at all. Now the two concepts are separate: 874 | 875 | > This change also clarifies the `@objc` attribute. Now it only makes a declaration visible to Objective-C (for examples, to `objc_msgSend`), instead of conflating exposure to the Objective-C runtime with guaranteed lack of devirtualization. This is a cleaner conceptual semantic model that enables performance improvements for a wide range of `NSObject` subclasses by allowing the compiler to use more efficient dispatch and access techniques for declarations marked `@objc` (which is usually implicit). 876 | > 877 | > Though the feature is independent of the `@objc` attribute, the implementation still currently relies on Objective-C runtime details, so dynamic currently can only be applied to declarations with `@objc`-compatible types. 878 | 879 | Source: [Xcode 6.0 Beta 5 release notes](http://ksm.github.io/SwiftInFlux/docs/beta5.pdf) 880 | 881 | 882 | ### Mutable optional value types 883 | 884 | From [Xcode 6.0 Beta 5 release notes](http://ksm.github.io/SwiftInFlux/docs/beta5.pdf): 885 | 886 | > The optional unwrapping operator x! can now be assigned through. Mutating methods and operators can be applied through it. 887 | ```swift 888 | var x: Int! = 0 889 | x! = 2 890 | x!++ 891 | // Nested dictionaries can now be mutated directly: 892 | var sequences = ["fibonacci": [1, 1, 2, 3, 0]] 893 | sequences["fibonacci"]![4] = 5 894 | sequences["fibonacci"]!.append(8) 895 | ``` 896 | > The ? chaining operator can also be used to conditionally assign through an optional if it has a ! value: 897 | ```swift 898 | sequences["fibonacci"]?.append(0) 899 | sequences["fibonacci"]?[6] = 13 900 | sequences["perfect"]?[0] = 6 // Does nothing because the sequence has no 'perfect' key 901 | ``` 902 | 903 | Previously: 904 | 905 | > The issue here is that optional forcing and binding operators (postfix ! and ?) return an immutable rvalue, even when the operand is a mutable lvalue. This means that you cannot perform mutating operations on the result, which is why optional arrays, dictionaries and other value types are pretty useless right now. 906 | > Unfortunately there isn't a great solution or workaround right now: one approach is to wrap the value in a class and use the optional on the class wrapper: 907 | ``` 908 | class StringArray { 909 | var elts : String[] 910 | } 911 | var myArray: StringArray? 912 | ``` 913 | > We consider this a significant problem and are investigating various solutions to incorporate in a later Beta. 914 | > 915 | > — Chris Lattner 916 | 917 | Sources: https://devforums.apple.com/message/998882#998882 [Xcode 6.0 Beta 5 release notes](http://ksm.github.io/SwiftInFlux/docs/beta5.pdf) 918 | 919 | ### Nil coalescing operator 920 | 921 | A new operator, `??`, has been introduced to help working with optionals. `??` takes an optional as its left operand, and a non-optional value or expression on the right. If the optional has a value, the whole expression evaluates to the value of the optional (the expression on the right is not evaluated). If the optional is `nil`, the right hand side expression is evaluated and passed as the result. You can think of the nil coalescing operator like the short-circuiting `||` operator, but for optionals. 922 | 923 | For example: 924 | 925 | ```swift 926 | var myArray: [Int] = [] 927 | print(myArray.first ?? 0) // produces 0, because myArray.first is nil 928 | myArray.append(22) 929 | print(myArray.first ?? 0) // produces 22, the value of myArray.first 930 | ``` 931 | 932 | Sources: [Xcode 6.0 Beta 5 release notes](http://ksm.github.io/SwiftInFlux/docs/beta5.pdf) 933 | 934 | ### Revised attributes 935 | 936 | Following the [changes in Xcode 6.0 Beta 4](#revised-declaration-modifiers), most of the @-attributes have been changed to declaration modifiers (shedding the `@` prefix) in Xcode 6.0 Beta 5. 937 | 938 | > The `@assignment` attribute has been removed from operator implementations. 939 | > 940 | > The `@prefix`, `@infix`, and `@postfix` attributes have been changed to declaration modifiers, 941 | > so they are no longer spelled with an `@` sign (now, `prefix func (...)`). Operator declarations 942 | > have been rearranged from `operator prefix - {}` to `prefix operator - {}` for consistency. 943 | > 944 | > The `@class_protocol` attribute has been removed; the new syntax for declaring that only protocol conformance is limited to classes is `'protocol P : class { ... }’`. 945 | > 946 | > The @auto_closure attribute has been renamed to @autoclosure. 947 | > 948 | > — Xcode 6.0 Beta 5 release notes 949 | 950 | Source: [Xcode 6.0 Beta 5 release notes](http://ksm.github.io/SwiftInFlux/docs/beta5.pdf) 951 | 952 | ### Boolean semantics of optionals 953 | 954 | Optional values no longer conform to `BooleanType` (formerly `LogicValue`) protocol, which means that: 955 | 956 | > (...) they may no longer be used in place of boolean expressions (they must be explicitly compared with v != nil). 957 | > 958 | > — Xcode 6.0 Beta 5 release notes 959 | 960 | Before this change, the boolean semantics of optionals were confusing when the optional wrapped a value that was a `BooleanType` itself: 961 | 962 | ```swift 963 | var foo: Bool? = false 964 | // This would print bar 965 | if foo { 966 | println("bar") 967 | } 968 | ``` 969 | 970 | Source: [Xcode 6.0 Beta 5 release notes](http://ksm.github.io/SwiftInFlux/docs/beta5.pdf) 971 | 972 | ### Ranges, Intervals, Striding 973 | 974 | Following minor changes to ranges [in Xcode 6.0 Beta 3](#range-operators) and [Xcode 6.0 Beta 4](#new-stride-functions), Xcode 6.0 Beta 5 brings a major rework of the entire area: 975 | 976 | > The idea of a Range has been split into three separate concepts: 977 | > 978 | > * Ranges, which are Collections of consecutive discrete `ForwardIndexType` values. Ranges are used for slicing and iteration. 979 | > * Intervals over `Comparable` values, which can efficiently check for containment. Intervals are used for pattern matching in switch statements and by the `~=` operator. 980 | > * Striding over `Strideable` values, which are `Comparable` and can be advanced an arbitrary distance in O(1). 981 | > 982 | > Some of the types most commonly used with the range operators `..<` and `...` – for example, `Int` — conform to both Comparable and ForwardIndexType. When used in a context that requires pattern matching (such as a switch case), the range operators create _Intervals_. Otherwise they create _Ranges_. Therefore, in a context without type constraint such as `let x = 3..<10`, the result is a _Range_. 983 | > 984 | > It is considered an error to form a _Range_ whose `endIndex` is not reachable from its `startIndex` by incrementation, or an _Interval_ whose end is less than its start. In these cases, _Interval_ formation always traps and _Range_ formation traps when a violation is detectable, that is, when the indices are `Comparable`. 985 | > 986 | > ``` 987 | 1> 1...0 988 | fatal error: Can't form Range with end < start 989 | > ``` 990 | > 991 | > `Intervals` are represented by two generic types, `HalfOpenInterval`, created by the `..<` operator, and `ClosedInterval`, created by the `...` operator: 992 | > ``` 993 | 1> 3.14..<12 994 | $R0: HalfOpenInterval = { 995 | _start = 3.1400000000000001 996 | _end = 12 997 | } 998 | 2> 22...99.1 999 | $R1: ClosedInterval = { 1000 | _start = 22 1001 | _end = 99.099999999999994 1002 | } 1003 | > ``` 1004 | > 1005 | > A _range_ `x.. 1007 | > All _Ranges_ are represented by instances of a single generic type, `Range`, whose representation is always half-open (and thus always print in the REPL and Playgrounds as a half-open range). Currently an inclusive range cannot include the last value in a sequence (for example, `4...Int.max` doesn’t work) unless the context requires an _Interval_ (like a case pattern matching specification). 1008 | 1009 | Source: [Xcode 6.0 Beta 5 release notes](http://ksm.github.io/SwiftInFlux/docs/beta5.pdf) 1010 | 1011 | ### Required and designated initializers in subclasses 1012 | 1013 | Swift compiler now strictly enforces the presence of required initializers in subclasses. If an ancestor of a class conforms to a protocol requiring a specific initializer and the class doesn't inherit that initializer automatically, it must define it by itself. 1014 | 1015 | What it means, most commonly, is that if you subclass a Cocoa class that conforms to `NSCoding` (e.g. `UIView`) and add your own designated initializer, you must also define `init(coder:)`. If you don't want to actually implement it, you can simply make it fail at runtime, like so: 1016 | 1017 | ```swift 1018 | required init(coder: NSCoder) { 1019 | fatalError("Does not implement coding") 1020 | } 1021 | ``` 1022 | 1023 | Also, the compiler now requires overrides of designated initializers to be explicitly marked with `override` and implementations of required initializers — with `required`. 1024 | 1025 | Source: [Xcode 6.0 Beta 5 release notes](http://ksm.github.io/SwiftInFlux/docs/beta5.pdf) 1026 | 1027 | ### Other changes 1028 | 1029 | Xcode 6.0 Beta 5 has seen a lot of symbols being renamed: 1030 | 1031 | * Protocols were renamed so that they all end with `able`, `ible` or `Type`. For example, `Integer` protocol was renamed to `IntegerType` 1032 | * `LogicValue` was renamed to `BooleanType` 1033 | * `getLogicValue()` became a `boolValue` property and `Optional` additionally has a `hasValue` property 1034 | * `UnsafeArray` and `UnsafeMutableArray` were renamed to `UnsafeBufferPointer` and `UnsafeMutableBufferPointer` 1035 | * `UnsafeConstPointer` and `UnsafePointer` were renamed to `UnsafePointer` and `UnsafeMutablePointer` for consistency and to encourage immutability 1036 | * `reinterpretCast()` was renamed to `unsafeBitCast()` 1037 | 1038 | Other changes in the standard library: 1039 | 1040 | * `+=` operator on arrays can no longer append a single item to the array (you have to wrap it into an array) 1041 | * `String` now has a constructor that takes an integer (you can even supply a radix) 1042 | * New `first`, `last` and `isEmpty` functions 1043 | 1044 | Finally: 1045 | 1046 | * Together with improvements in earlier betas, the Swift compiler can now produce far faster, better optimized code (on some benchmarks, Swift went from being two orders of magnitude slower than Objective-C to being an order of magnitude _faster_ than Objective-C) 1047 | * Meanwhile, Xcode can now recompile a single changed file instead of recompiling the whole project. 1048 | * You can now import frameworks in Playgrounds 1049 | * `println()` in Playgrounds now prints next to the line where it's defined (not just printed in the console output) 1050 | 1051 | Further reading: 1052 | * [Airspeed Velocity](http://airspeedvelocity.net/2014/08/04/changes-in-the-swift-standard-library-in-beta-5/) 1053 | * [Russ Bishop](http://www.russbishop.net/swift-beta-5) 1054 | * [Xcode 6.0 Beta 5 release notes](http://ksm.github.io/SwiftInFlux/docs/beta5.pdf) 1055 | * [Apples to apples, Part II](http://www.jessesquires.com/apples-to-apples-part-two/) 1056 | 1057 | ## Changed in Xcode 6.0 Beta 4 1058 | 1059 | ### Access control 1060 | 1061 | Xcode 6.0 Beta 4 adds three levels of access control to user-defined entities: `public` (available anywhere), `internal` (available within the target where they're defined) and `private` (available only within the file where they're defined). 1062 | 1063 | > By default, most entities in a source file have internal access. This allows application developers to largely ignore access control while allowing framework developers full control over a framework's API. 1064 | 1065 | It's also possible to define attributes with public getters but private setters using the `private(set)` syntax. 1066 | 1067 | It has been noted that the current access control design [makes unit testing a bit unwieldy](#limitations-of-current-access-control-design). 1068 | 1069 | Source: [Xcode 6.0 Beta 4 release notes](http://ksm.github.io/SwiftInFlux/docs/beta4.pdf) 1070 | 1071 | ### Unicode string improvements 1072 | 1073 | Character was changed in Xcode 6.0 Beta 4 to hold a full grapheme cluster instead of a single code point. 1074 | 1075 | > Certain accented characters (like é) can be represented either as a single code point or as a sequence of two or more code points (e + ́) 1076 | 1077 | Before Xcode 6.0 Beta 4, é achieved using "e" and a combining mark would be treated as two Character instances. Now, every character is a single Character. The change helps avoid a class of bugs when dealing with complex Unicode strings. 1078 | 1079 | In addition to the above, Xcode 6.0 Beta 4 removes `\x`, `\u` and `\U` escape sequences for Unicode characters and replaces them with a single, less error-prone `\u{1234}` syntax 1080 | 1081 | Sources: http://oleb.net/blog/2014/07/swift-strings/ https://devforums.apple.com/message/1007773#1007773 1082 | 1083 | ### Numerical data type conversion, e.g. CGFloat and Swift Double/Swift Float 1084 | 1085 | From Xcode 6.0 Beta 4 Release Notes: 1086 | >CGFloat is now a distinct floating-point type that wraps either a Float on 32-bit architectures or a Double on 64-bit architectures. 1087 | 1088 | Sources: 1089 | [Xcode 6.0 Beta 4 release notes](http://ksm.github.io/SwiftInFlux/docs/beta4.pdf) 1090 | 1091 | >What is happening here is that CGFloat is a typealias for either Float or Double depending on whether you're building for 32 or 64-bits. This is exactly how Objective-C works, but is problematic in Swift because Swift doesn't allow implicit conversions. 1092 | > 1093 | >We're aware of this problem and consider it to be serious: we are evaluating several different solutions right now and will roll one out in a later beta. As you notice, you can cope with this today by casting to Double. This is inelegant but effective :-) 1094 | > 1095 | > — Chris Lattner 1096 | 1097 | Sources: https://devforums.apple.com/message/998222#998222 1098 | 1099 | ### Revised declaration modifiers 1100 | 1101 | > The @final, @lazy, @optional, and @required attributes have been converted to declaration modifiers, specified without an @ sign. 1102 | 1103 | Source: [Xcode 6.0 Beta 4 release notes](http://ksm.github.io/SwiftInFlux/docs/beta4.pdf) 1104 | 1105 | ### New stride() functions 1106 | 1107 | > The .by() method for ranges has been replaced with general stride() functions. To 1108 | adopt stride(), use stride(from: to: by:) for exclusive ranges and stride(from: through: by:) for inclusive ranges. 1109 | 1110 | For example, you can now do: 1111 | 1112 | ```swift 1113 | stride(from: x, to: y, by: z) // was: (x.. The set of characters is in flux, but yes, most unicode symbol characters in the BMP that are classified as 'symbol' and 'math' are available as operator characters. 1126 | > 1127 | > — Joe Groff 1128 | 1129 | > It's not documented yet, but the set of allowed operator characters includes 'math' and 'symbol' characters in the Unicode BMP, and operator characters can be augmented with combining characters. The full set of supported characters will be documented in one of the following seeds. 1130 | > 1131 | > — Joe Groff 1132 | 1133 | Sources: https://devforums.apple.com/thread/231723?tstart=450 https://devforums.apple.com/message/1000934#1000934 1134 | 1135 | ### `@IBOutlet` 1136 | 1137 | Before Xcode 6.0 Beta 4, marking a property with `@IBOutlet` implicitly made it a weak variable and an implicitly unwrapped optional. Now, the attribute merely makes a property visible to Interface Builder. 1138 | 1139 | Previously: 1140 | 1141 | > In Beta 3 (and earlier) the @IBOutlet attribute implicitly makes the variable weak, and implicitly makes it an implicitly unwrapped optional (unless it's explicitly marked with ?). We added the 'strong' modifier in Beta 3. 1142 | > 1143 | > This is super confusing, too magic, leads to problems (like this) where "retains" are lost for types like arrays because the only reference is weak, and isn't even best practice on iOS where most outlets should be strong. For all of these reasons, in a future Beta, @IBOutlet will become "just" an annotation for IB, without any implicit behavior. 1144 | > 1145 | > — Chris Lattner 1146 | 1147 | Source: https://devforums.apple.com/message/1002722#1002722 1148 | 1149 | ### Fixed: Structs with both @lazy and non-lazy properties crashes compiler 1150 | 1151 | structs with a @lazy property followed by a non-lazy property crashes 1152 | the compiler. 1153 | 1154 | > This is fixed, but didn't make it into Beta 3. Stay tuned for a later Beta, 1155 | > 1156 | > — Chris Lattner 1157 | 1158 | [The code from the Developer Forums](https://devforums.apple.com/message/1000511#1000511) no longer causes a segmentation fault in the compiler in Xcode 6.0 Beta 4. 1159 | 1160 | Source: https://devforums.apple.com/message/1000950#1000950 1161 | 1162 | ### Other changes to standard library 1163 | 1164 | * `uppercaseString` and `lowercaseString` properties were removed from String 1165 | * `insertionSort` and `quickSort` were removed 1166 | * `CString` was removed. `const char *` values are now imported as `ConstUnsafePointer` 1167 | * `modulusWithOverflow` was replaced by `remainderWithOverflow` 1168 | * `Float` and `Double` no longer conform to `RandomAccessIndex`, which means they can no longer be used to index a collection 1169 | * `true` and `false` are now language literals. `Bool` conforms to a new `BooleanLiteralConvertible` protocol that allows user-defined types to support Boolean literals. 1170 | * `ArrayBuffer`, `ArrayBufferType`, `SliceBuffer` and `ContiguousArrayBuffer` were removed (the reason being, those structures were only an implementation detail of corresponding types) 1171 | * `reverse` is no longer lazy and simply returns an Array. New `lazy` functions can be used to lazily reverse, filter and map collections through new `LazyForwardCollection`, `LazyRandomAccessCollection` and `LazySequence` structures 1172 | 1173 | Sources: http://airspeedvelocity.net/2014/07/21/changes-in-the-swift-standard-library-in-beta-4/ [Xcode 6.0 Beta 4 release notes](http://ksm.github.io/SwiftInFlux/docs/beta4.pdf) 1174 | 1175 | ## Changed in Xcode 6.0 Beta 3 1176 | 1177 | ### Array and Dictionary type declaration syntax 1178 | Before Xcode 6.0 Beta 3, the shorthand for an Array type was `Type[]`, and Dictionary types were written `Dictionary`. Array type shorthand was changed to `[Type]` and Dictionaries types now have a shorthand syntax `[KeyType: ValueType]` (e.g. `[String: Bool]`) 1179 | 1180 | ### Array value semantics 1181 | Since Xcode 6.0 Beta 3, Array has full value semantics to match Dictionary, String and other value types. 1182 | 1183 | >Array semantics were in flux at the time of Beta 1, and have been revised to provide full value semantics like Dictionary and String. This will be available in later betas. 1184 | > 1185 | > — Chris Lattner 1186 | 1187 | Sources: https://devforums.apple.com/thread/228695?start=75&tstart= 1188 | 1189 | ### Modifying constant properties in designated vs. convenience initializers 1190 | 1191 | > What is going on here is that initializers have privledged access to 'let' properties while they run: these properties are actually mutable when accessed directly within the initializer. This is very useful when you're configurating an object during its setup, but it is absolutely required when you have an immutable property dependent on some argument to the initializer, e.g.: 1192 | > 1193 | ```swift 1194 | class C { 1195 | let x : Int // immutable property 1196 | init(input : Int) { 1197 | x = input // mutating an immutable property! 1198 | } 1199 | } 1200 | ``` 1201 | > This is an important part of making immutable properties (as opposed to random other immutable variables) useful and functional, but it is dangerous, and potentially allows extensions to a type to violate invariants. 1202 | > 1203 | > Beta 3 fixes this by only allowing mutation within non-convenience initializers. Convenience inits must delegate to some other initializer anyway, so that initializer can take an argument and do the mutation. 1204 | > 1205 | > Long story short, this is a feature, not a bug :-) 1206 | > 1207 | > — Chris Lattner 1208 | 1209 | Source: https://devforums.apple.com/message/1003240#1003240 1210 | 1211 | ### Range operators 1212 | 1213 | The half-open range operator was changed from `..` to `..<`. 1214 | 1215 | > We considered this carefully. As you can see from this thread, small syntactic issues like this are polarizing, subject to personal preferences, and have no one right answer. See also http://en.wikipedia.org/wiki/Bikeshed 1216 | > 1217 | > For what it's worth, this approach is precendented in the groovy language. It optimizes for readability and clarity: you're unlikely to mistake one operator for the other when skimming code, and new people coming to Swift are unlikely to assume that ..< is an inclusive range operator (like most assumed when they saw "0..5") 1218 | > 1219 | > — Chris Lattner 1220 | > 1221 | > I'd really like it if there was only a single range operator, but that isn't possible (AFAIK): 1222 | > 1223 | > - You need to have a half-open range operator to be able to represent an empty range. 1224 | > - You need an inclusive range operator to represent finite enumerated sequences when you want to include the last element (e.g. enums, but also integers that you want to include the largest integer value in).. 1225 | > 1226 | > — Chris Lattner 1227 | 1228 | Sources: https://devforums.apple.com/message/1000100#1000100 https://devforums.apple.com/message/999669#999669 1229 | --------------------------------------------------------------------------------