{"id":13396645,"url":"https://github.com/ksm/SwiftInFlux","last_synced_at":"2025-03-13T23:31:42.562Z","repository":{"id":18340159,"uuid":"21519749","full_name":"ksm/SwiftInFlux","owner":"ksm","description":"An attempt to gather all that is in flux in Swift.","archived":false,"fork":false,"pushed_at":"2015-12-03T22:21:59.000Z","size":2392,"stargazers_count":1864,"open_issues_count":0,"forks_count":81,"subscribers_count":227,"default_branch":"master","last_synced_at":"2024-10-15T12:42:26.014Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/ksm.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2014-07-05T12:39:10.000Z","updated_at":"2024-10-07T04:03:52.000Z","dependencies_parsed_at":"2022-08-25T12:10:39.573Z","dependency_job_id":null,"html_url":"https://github.com/ksm/SwiftInFlux","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ksm%2FSwiftInFlux","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ksm%2FSwiftInFlux/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ksm%2FSwiftInFlux/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ksm%2FSwiftInFlux/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/ksm","download_url":"https://codeload.github.com/ksm/SwiftInFlux/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":221421590,"owners_count":16817837,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-07-30T18:00:58.707Z","updated_at":"2024-10-25T11:31:04.744Z","avatar_url":"https://github.com/ksm.png","language":null,"readme":"## This document is no longer maintained.\n\n\nWith 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.\n\n========\n\nSwift InFlux\n===========\nThe 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?\n\nThis document is an attempt to gather the Swift features that are still in flux and likely to change.\n\n### Contributing\nTo contribute: fork this project, add a section below (don't forget to update the Table of Contents!), and create a pull request.\n\n### Credits\n\nSwift 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).\n\n### Table of Contents\n\n* [Abstract methods](#abstract-methods)\n* [Access control](#limitations-of-current-access-control-design)\n* [ABI stability](#abi-stability)\n* [Better error handling](#better-error-handling-features-possibly-exceptions)\n* [Class variables](#class-variables)\n* [C++ support](#c-support)\n* [Dynamic dispatch of operators](#dynamic-dispatch-of-operators)\n* [Enumerating enum types](#enumerating-enum-types)\n* [Expanding scope of imported macros](#expanding-scope-of-imported-macros)\n* [Flow-sensitive optional unwrapping](#flow-sensitive-optional-unwrapping)\n* [Generic subscripts](#generic-subscripts)\n* [Imported constant macros carry explicit type](#imported-constant-macros-carry-explicit-type)\n* [Moving functionality from global functions to methods](#moving-functionality-from-global-functions-to-methods)\n* [Open source](#open-source)\n* [Optionals in imported Objective-C frameworks](#optionals-in-imported-objective-c-frameworks)\n* [Optional methods in pure-Swift protocols](#optional-methods-in-pure-swift-protocols)\n* [Overriding declarations from extensions](#overriding-declarations-from-extensions)\n* [Passing initializers as functions](#passing-initializers-as-functions)\n* [Reflection](#reflection)\n* [Runtime dynamic libraries](#runtime-dynamic-libraries)\n* [Static libraries](#static-libraries)\n* [`switch` and `if` as expressions](#switch-and-if-as-expressions)\n* [Systems programming features](#systems-programming-features)\n\n___\n\n* [Changed in Xcode 6.3 Beta 3](#changed-in-xcode-63-beta-3)\n\n* [Changed in Xcode 6.3 Beta 2](#changed-in-xcode-63-beta-2)\n  * [Further enhancements to `if let`](#further-enhancements-to-if-let)\n\n* [Changed in Xcode 6.3 Beta 1](#changed-in-xcode-63-beta-1)\n  * [Compiler improvements](#compiler-improvements)\n  * [Nullability annotations in Objective-C](#nullability-annotations-in-objective-c)\n  * [Enhancements to `if let`](#enhancements-to-if-let)\n  * [Constants no longer require immediate initialization](#constants-no-longer-require-immediate-initialization)\n  * [Importing Swift enums into Objective-C](#importing-swift-enums-into-objective-c)\n  * [First-class `Set` type](#first-class-set-type)\n  * [Xcode drops Mavericks support](#xcode-drops-mavericks-support)\n\n___\n\n* [Changed in Xcode 6.2](#changed-in-xcode-62)\n\n* [Changed in Xcode 6.1.1](#changed-in-xcode-611)\n\n* [Changed in Xcode 6.1 GM Seed 2 / 6.1](#changed-in-xcode-61-gm-seed-2--61)\n\n* [Changed in Xcode 6.1 Beta 3 / GM Seed 1](#changed-in-xcode-61-beta-3--gm-seed-1)\n * [`LiteralConvertible` protocols use constructor](#literalconvertible-protocols-use-constructor)\n * [Other](#other-changes-in-xcode-61-beta-3--gm-seed-1)\n\n* [Changed in Xcode 6.1 Beta 2](#changed-in-xcode-61-beta-2)\n * [Failable initializers in Objective-C frameworks](#failable-initializers-in-objective-c-frameworks)\n * [Redefinition of private entities](#redefinition-of-private-entities)\n * [Other](#other-changes-in-xcode-61-beta-2)\n\n* [Changed in Xcode 6.1 Beta 1](#changed-in-xcode-61-beta-1)\n * [Failable initializers](#failable-initializers)\n * [Other](#other-changes-in-xcode-61-beta-1)\n\n___\n\n* [Changed in Xcode 6.0 GM / 6.0.1](#changed-in-xcode-60-gm--601)\n\n* [Changed in Xcode 6.0 Beta 7](#changed-in-xcode-60-beta-7)\n\n* [Changed in Xcode 6.0 Beta 6](#changed-in-xcode-60-beta-6)\n * [Refinements to nil coalescing operator](#refinements-to-nil-coalescing-operator)\n * [Optionals in Foundation](#optionals-in-foundation)\n * [Boolean semantics of types](#boolean-semantics-of-types)\n * [Other](#other-changes-in-xcode-60-beta-6)\n\n* [Changed in Xcode 6.0 Beta 5](#changed-in-xcode-60-beta-5)\n  * [`dynamic` keyword](#dynamic-declaration-modifier)\n  * [Mutable optional value types](#mutable-optional-value-types)\n  * [Nil coalescing operator](#nil-coalescing-operator)\n  * [Attributes](#revised-attributes)\n  * [Boolean semantics of optionals](#boolean-semantics-of-optionals)\n  * [Ranges](#ranges-intervals-striding)\n  * [Initializers](#required-and-designated-initializers-in-subclasses)\n  * [Other](#other-changes)\n\n* [Changed in Xcode 6.0 Beta 4](#changed-in-xcode-60-beta-4)\n  * [Access control](#access-control)\n  * [Unicode string improvements](#unicode-string-improvements)\n  * [Numerical data type conversion](#numerical-data-type-conversion-eg-cgfloat-and-swift-doubleswift-float)\n  * [Revised declaration modifiers](#revised-declaration-modifiers)\n  * [New stride() functions](#new-stride-functions)\n  * [Set of legal operator characters](#set-of-legal-operator-characters)\n  * [`@IBOutlet`](#iboutlet)\n  * [Fixed: Structs with both @lazy and non-lazy properties crashes compiler](#fixed-structs-with-both-lazy-and-non-lazy-properties-crashes-compiler)\n  * [Other changes to standard library](#other-changes-to-standard-library)\n\n* [Changed in Xcode 6.0 Beta 3](#changed-in-xcode-60-beta-3)\n  * [Array and Dictionary type declaration syntax](#array-and-dictionary-type-declaration-syntax)\n  * [Array value semantics](#array-value-semantics)\n  * [Modifying constant properties in designated vs. convenience initializers](#modifying-constant-properties-in-designated-vs-convenience-initializers)\n  * [Range operators](#range-operators)\n\n---\n\n### Abstract methods\n\n\u003e 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 :-)\n\u003e\n\u003e — Chris Lattner\n\nSource: https://devforums.apple.com/message/1006592#1006592\n\n### Limitations of current access control design\n\nSwift [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.\n\n\u003e 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.\n\u003e\n\u003e — Chris Lattner\n\u003e\n\u003e 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.\n\u003e\n\u003e — Xcode 6.0 beta 4 release notes\n\nAt 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.\n\nSources: https://devforums.apple.com/message/1010766#1010766 [Xcode 6.0 Beta 4 release notes](http://ksm.github.io/SwiftInFlux/docs/beta4.pdf)\n\n### ABI stability\n\n\u003e Swift currently offers no ABI stability for any code and provides no ABI\n\u003e non-fragility for framework authors.\n\u003e\n\u003e — Greg Parker\n\u003e\n\u003e gparker [Greg Parker] is right, and this is important.\n\u003e \n\u003e Swift 1.0 is not guaranteed to be binary compatible with \"swift 2.0\" (or\n\u003e whatever). We guarantee that compiled and distributed *apps* and their\n\u003e frameworks are binary compatible with the OS and will continue to work well\n\u003e into the future, but a Swift framework today will not work in the future.\n\u003e \n\u003e We expect to lock this down, but not by the final release of swift this Fall.\n\u003e This means that all swift code in an app (including frameworks it uses) should\n\u003e be built by the same version of Xcode.\n\u003e \n\u003e — Chris Lattner\n\nSources: https://devforums.apple.com/message/986618#986618 https://devforums.apple.com/message/989931#989931\n\n### Better error handling features (possibly exceptions)\n\n\u003eWe'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.\n\u003e\n\u003e — Chris Lattner\n\nSource: https://devforums.apple.com/thread/228324?start=50\u0026tstart=0\n\n### Class variables\n\nAt 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.\n\n\u003e Class variables not yet supported.\n\u003e\n\u003e — Swift compiler error\n\u003e\n\u003e The feature set for 1.0 is nearly final.  'yet' should not be taken to mean Swift 1.0.\n\u003e\n\u003e — Chris Lattner\n\u003e\n\u003e Swift in Xcode 6 will not support class variables.\n\u003e\n\u003e — Greg Parker\n\nSources: https://devforums.apple.com/message/1022374#1022374 https://devforums.apple.com/message/1030167#1030167\n\n### C++ support\n\n\u003eThis is another obviously desirable feature, it is just a lot of work and didn't make it in 1.0 either.\n\u003e\n\u003e — Chris Lattner\n\nSource: https://devforums.apple.com/thread/228324?start=50\u0026tstart=0\n\n### Dynamic dispatch of operators\n\n\u003e FWIW, we're not happy with this either.  Among other things, we've seen confusion where people define something like:\n\u003e\n     func ==(lhs : MyBaseClass, rhs : MyBaseClass) {...}\n     func ==(lhs : MyDerivedClass, rhs : MyDerivedClass) {...}\n\u003e\n\u003e ... and are surprised when they don't get dynamic dispatch.\n\u003e  \n\u003e 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.\n\u003e\n\u003e — Chris Lattner\n\nSource: https://devforums.apple.com/message/1074064#1074064\n\n### Enumerating enum types\n\n\u003e \u003e 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?\n\u003e\n\u003e Yes.  All of this would be super useful.  We have a large number of radars asking for similar functionality, thanks!\n\u003e\n\u003e — Chris Lattner\n\nSource: https://devforums.apple.com/message/1003674#1003674\n\n### Expanding scope of imported macros\n\nSwift currently only imports simple constant-like macros from C and Objective-C.\nThis leaves many key macros unaccessible to Swift, requiring redefinition. For\nexample, the `CPU_TYPE` constant type cast macros in `mach/machine.h`.\n\n```c\n#define CPU_TYPE_X86          ((cpu_type_t) 7)\n```\n\n\u003e It's hard to nail Apple down as to what we will or won't do, but I think it's\n\u003e safe to say that improving the way that Swift imports C / Objective-C headers\n\u003e is an important goal.\n\u003e\n\u003e — eskimo1\n\n\u003e Indeed. Improving the experience using imported C/Objective-C APIs is a strong\n\u003e goal for ongoing swift evolution.\n\u003e\n\u003e — Chris Lattner\n\nSources:\n\n- https://devforums.apple.com/message/1122873#1122873\n- https://devforums.apple.com/message/1123733#1123733\n\n### Flow-sensitive optional unwrapping\n\nIt 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:\n\n```swift\nlet x: Type?\n\nif exists x {\n   x.doSomething() // works without ? or !\n}\n```\n\n\u003e 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.\n\u003e\n\u003e — Chris Lattner\n\u003e\n\u003e Flow-sensitive type refinement like this is something that may happen in a future release of Swift\n\u003e\n\u003e — CFM\n\nSource: https://devforums.apple.com/message/1005148#1005148 https://devforums.apple.com/message/1066436#1066436\n\n### Generic subscripts\n\n\u003e 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.\n\u003e\n\u003e — Chris Lattner\n\nCurrently, generic subscripts are allowed only for generic types (e.g. `Array`, `Dictionary`).\n\nSource: https://devforums.apple.com/message/1100335#1100335\n\n### Imported constant macros carry explicit type\n\nSince Swift does not allow implicit type conversion, imported constant C and\nObjective-C macros lose a bit of flexibility in use as they carry an explicit\ntype (Swift has no preprocessor). For example, `M_PI` from `math.h` is imported\nas a double.\n\n\u003e 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.\n\u003e\n\u003e 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.\n\u003e\n\u003e — Chris Lattner\n\nSource: https://devforums.apple.com/message/1032523#1032523\n\n### Moving functionality from global functions to methods\n\n\u003e We'll have to evaluate this in more detail when we have time to explore the design space, but here are some thoughts:\n\u003e\n\u003e 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.  \n\u003e \n\u003e 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.\n\u003e\n\u003e — Chris Lattner\n\u003e\n\u003e The prevalence of generic free functions is more about current language limitations than an intentional stylistic direction\n\u003e\n\u003e — CFM\n\nSource: https://devforums.apple.com/message/1074064#1074064  https://devforums.apple.com/message/1094312#1094312\n\n### Open source\n\nSwift will be going open source late 2015 once Apple has shipped the 2.0 GM\nversion of the language (Fall). The details that Apple has provided on this so\nfar are:\n\n- Source code for the Swift compiler and standard library will be released under\n  an [OSI](http://opensource.org)-approved permissive license\n- Ports for OS X, iOS, and Linux with be provided\n- Contributions will be accepted\n\n\u003e Guys, feel free to make up your own dragons if you want, but your speculation\n\u003e is just that: speculation.  We literally have not even discussed this yet,\n\u003e because we have a ton of work to do to respond to the huge volume of feedback\n\u003e we're getting, and have to get a huge number of things (e.g. access control!)\n\u003e done before the 1.0 release this fall.  You can imagine that many of us want\n\u003e it to be open source and part of llvm, but the discussion hasn't happened yet,\n\u003e and won't for some time.\n\u003e \n\u003e Sorry to leave you all hanging, but there is just far too much to deal with\n\u003e right now.\n\u003e \n\u003e — Chris Lattner\n\nSources:\n\n- http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-June/073698.html\n- https://developer.apple.com/swift/blog/?id=29\n\n### Optionals in imported Objective-C frameworks\n\nAs 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.\n\nSince Xcode 6.3, it is possible for users to [annotate nullability](#nullability-annotations-in-objective-c) (optionality) of Objective-C APIs.\n\n\u003e 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.\n\u003e\n\u003e The API changes replace T! with either T? or T depending on whether or not the value can be null, respectively.\n\u003e\n\u003e — Xcode 6.1 release notes\n\nSources: [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)\n\n### Optional methods in pure-Swift protocols\n\n\u003e 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.\n\u003e\n\u003e — Joe Groff\n\nSource: https://devforums.apple.com/message/1051431#1051431\n\n### Overriding declarations from extensions\n\nAt the moment, it's not possible to override entities declared in extension by subclassing, like so:\n\n```swift\nclass Base { }\n\nextension Base {\n    var foo: String { return \"foo\" }\n}\n\nclass Sub: Base {\n    override var foo: String { return \"FOO\" } // This is an error\n}\n```\n\nNote: 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.\n\n\u003e Declarations from extensions cannot be overriden yet.\n\u003e\n\u003e — Swift compiler error\n\u003e\n\u003e The feature set for 1.0 is nearly final.  'yet' should not be taken to mean Swift 1.0.\n\u003e\n\u003e — Chris Lattner\n\nSource: https://devforums.apple.com/message/1022374#1022374\n\n### Passing initializers as functions\n\n\u003e \u003e [Is there any] specific reason why you can't reference initializers like a function?\n\u003e\n\u003e No particular reason, it's just not implemented.\n\u003e\n\u003e — Joe Groff\n\nReferencing initializers to pass as an argument would be useful for [currying](http://www.objc.io/snippets/6.html).\n\nSource: https://twitter.com/jckarter/status/542032426298392576\n\n### Reflection\n\nAt 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.\n\nFurther reading: [Simple Reflection in Swift](http://freecake.yayuhh.com/simple-reflection-in-swift/)\n\n\u003e 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.\n\u003e\n\u003e — Brent Simmons\n\nSources: http://inessential.com/2014/07/13/swift_reflection https://gist.github.com/peebsjs/9288f79322ed3119ece4\n\n### Runtime dynamic libraries\n\n\u003e Products that use Swift need to come with their own copies of the swift\n\u003e runtime. This is currently necessary for a variety of reasons. Xcode directly\n\u003e supports this for the following scenarios:\n\u003e \n\u003e - When you build an application that uses Swift, Xcode will automatically\n\u003e   embeds the swift runtime dynamic libraries inside the app wrapper in the\n\u003e   Frameworks folder. Application targets should also be automatically\n\u003e   configured with rpath entries that will locate them there.\n\u003e - When you build a command line tool that uses Swift, Xcode will statically\n\u003e   link the swift runtime into the command line tool's binary\n\u003e - When you build other product types (e.g. frameworks or app extensions) that\n\u003e   use Swift, they are set up to expect to find the swift libraries embedded\n\u003e   in the application that they are themselves embedded in\n\u003e\n\u003e — mferris\n\nThis is done for several reasons:\n\n\u003e Swift's runtime and libraries are not (yet) included in the operating system,\n\u003e so must be included in each app.\n\u003e\n\u003e — CFM\n\u003e\n\u003e The runtime is bundled with your app in order to prevent incompatible language\n\u003e changes from affecting deployed apps. Changes to the language, runtime\n\u003e implementation, or how frameworks get imported won't affect your\n\u003e already-compiled app — any ABI-level dependencies are between the runtime\n\u003e dylibs in your bundle and the main executable.\n\u003e\n\u003e — Joe Groff\n\nGiven this, you will hit issues if your are creating an OS X command line tool\nthat uses a framework written in Swift.\n\n\u003e In your case, the swift standard libraries are being statically linked into\n\u003e your command line tool. The problem is that the framework cannot see that, and\n\u003e it expects to find them in an app wrapper that it is inside of. Xcode\n\u003e currently has no direct support for a standalone framework using swift that is\n\u003e not embedded in an application.\n\u003e\n\u003e — mferris\n\nSources:\n\n- https://devforums.apple.com/message/1038413#1038413\n- https://devforums.apple.com/message/1003269#1003269\n- https://devforums.apple.com/message/1057293#1057293\n\n### Static libraries\n\n\u003e Xcode does not support building static libraries that include Swift code.\n\u003e\n\u003e — Xcode 6.0 beta 5 release notes\n\u003e\n\u003e 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.\n\u003e\n\u003e — Joe Groff\n\nSources: [Xcode 6.0 Beta 5 release notes](http://ksm.github.io/SwiftInFlux/docs/beta5.pdf) https://twitter.com/jckarter/status/555061575623507969\n\n### `switch` and `if` as expressions\n\n\u003e 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.\n\u003e \n\u003e -Chris\n\nSource: https://devforums.apple.com/message/1040049#1040049\n\n### Systems Programming Features\n\n\u003e 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.\n\u003e\n\u003e — Chris Lattner\n\nSource: https://devforums.apple.com/message/1007178#1007178\n\n___\n\n## Changed in Xcode 6.3 Beta 3\n\n* [Xcode Release Notes](http://ksm.github.io/SwiftInFlux/docs/6.3-beta3.pdf)\n* [SwiftDoc.org post](http://swiftdoc.org/news/2015/03/updated-for-swift-1.2b3/)\n* [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/)\n* [Standard library header diff](https://github.com/radex/swift_stdlib/commit/71e6f580528ee2d7a099e9b9bbed87775560ca5b)\n\n## Changed in Xcode 6.3 Beta 2\n\n* [Xcode Release Notes](http://ksm.github.io/SwiftInFlux/docs/6.3-beta2.pdf)\n* [Playgrounds improvements on the official Swift blog](https://developer.apple.com/swift/blog/?id=24)\n* [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/)\n* [Standard library header diff](https://github.com/radex/swift_stdlib/commit/306c91a82982580cea56b2b86d26ee2671125390)\n\n### Further enhancements to `if let`\n\nFollowing 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:\n\n```swift\nif loggingEnabled, let samples = getLogSamples() where samples.count \u003e 10 {\n    sendLogSamples(samples)\n}\n```\n\n## Changed in Xcode 6.3 Beta 1\n\nXcode 6.3 brings a large number of changes, bug fixes and new features to Swift, which is now version 1.2.\n\nMore information:\n* [Post on official Swift Blog](https://developer.apple.com/swift/blog/?id=22)\n* [Xcode Release Notes](http://ksm.github.io/SwiftInFlux/docs/6.3-beta1.pdf)\n* [Standard library header diff](https://github.com/radex/swift_stdlib/commit/1014c4b251019eabe0056a3d8e90818a9a1b20c3.patch)\n* [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\n* [SwiftDoc.org post](http://swiftdoc.org/news/2015/02/swift1.2/)\n* [Fixed Swift compiler crashes](https://github.com/practicalswift/swift-compiler-crashes/commit/f6da30450923afbc313fbcac16a5367c3f88aec3)\n\n### Compiler improvements\n\nAccording to the Swift team, the compiler got a lot of under-the-hood improvements, which give us:\n\n* **Incremental builds** — files that haven't changed won't have to be recompiled every time, speeding up the process\n* **Faster executables** — Swift binary code is now better optimized, both in Release and Debug modes.\n* **Better diagnostics** — Clearer warning and error messages, as well as new fix-its\n* **Stability improvements** — less compilation and SourceKit crashes. \n - 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\n\n### Nullability annotations in Objective-C\n\nYou 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:\n\n```objc\n-(nullable UITableViewCell *)cellForRowAtIndexPath:(nonnull NSIndexPath)indexPath;\n```\n\nSame keywords can be used with Objective-C property configuration:\n\n```objc\n@property (nonatomic, readwrite, retain, nullable) UIView *backgroundView;\n```\n\nArbitrary C pointers, block pointers and C++ member pointers can be marked using `__nonnull` and `__nullable`, like so:\n\n```c\nvoid enumerateStrings(__nonnull CFStringRef (^ __nullable callback)(void));\n```\n\nThis will be imported as:\n\n```swift\nfunc enumerateStrings(callback: (() -\u003e CFString)?)\n```\n\n### Enhancements to `if let`\n\nThe `if let` construct can now be used to optionally unwrap multiple optionals at once. You can also add a guarding condition with `where`:\n\n```swift\nif let a = foo(), b = bar() where a \u003c b,\n    let c = baz() {\n}\n```\n\n### Constants no longer require immediate initialization\n\nIn 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).\n\nThis allows patterns like:\n\n```swift\nlet x: SomeThing\nif condition {\n    x = foo()\n} else {\n    x = bar()\n}\nuse(x)\n```\n\nIn previous versions this would require using `var`, even though no mutation is taking place.\n\n### Importing Swift enums into Objective-C\n\nSimple 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:\n\n```swift\n@objc enum Bear: Int {\n    case Black, Grizzly, Polar\n}\n```\n\nimports into Objective-C as:\n\n```objc\ntypedef NS_ENUM(NSInteger, Bear) {\n    BearBlack, BearGrizzly, BearPolar\n};\n```\n\n### First-class `Set` type\n\nThe Swift standard library now includes a fully generic `Set` type that bridges to `NSSet` and has value semantics.\n\n### Xcode drops Mavericks support\n\n\u003e Xcode 6.3 does require Yosemite, as mentioned in the release notes. This will\n\u003e not be changed in a later beta.\n\u003e\n\u003e — Chris Lattner\n\nSwift can still target Mavericks (10.9), but Xcode itself will no longer support\nit.\n\nSource: https://devforums.apple.com/message/1101275#1101275\n\n___\n\n## Changed in Xcode 6.2\n\nXcode 6.2 doesn't include any significant changes to Swift except for [nullability audit](#optionals-in-imported-objective-c-frameworks) of the WatchKit framework.\n\n\u003e Yeah, 6.2's (almost) all about WatchKit.\n\u003e\n\u003e — Joe Groff\n\nSources: https://devforums.apple.com/message/1074584#1074584 https://devforums.apple.com/message/1082641#1082641 https://twitter.com/jckarter/status/555059438944387072\n\n## Changed in Xcode 6.1.1\n\nXcode 6.1.1 was a maintenance release with only minor improvements and bug fixes to Swift, including:\n\n* Passing class objects for pure Swift class to `AnyObject` values no longer causes a crash\n* Class methods and initializers that satisfy protocol requirements now properly invoke subclass overrides when called in generic contexts\n* Some causes of SourceKit crashes have been fixed\n* Minor changes to [nullability](#optionals-in-imported-objective-c-frameworks) in Objective-C frameworks.\n\nThere 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).\n\nThere have been [no significant differences](https://devforums.apple.com/message/1079865#1079865) between the 6.1.1 GM seed and the final version.\n\nSource: [Xcode 6.1.1 Release Notes](https://developer.apple.com/library/ios/releasenotes/DeveloperTools/RN-Xcode/Chapters/Introduction.html#//apple_ref/doc/uid/TP40001051)\n\n## Changed in Xcode 6.1 GM Seed 2 / 6.1\n\nGM 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.\n\n* [Fixed compiler crashes](https://github.com/practicalswift/swift-compiler-crashes/commit/768c5bdfa21e01e286022a75e9586f1df8b7012d)\n* [Xcode release notes](http://ksm.github.io/SwiftInFlux/docs/6.1-gm-seed2.pdf)\n\nThe 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.\n\n* [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)\n\n## Changed in Xcode 6.1 Beta 3 / GM Seed 1\n\nBeta 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.\n\n* [Standard library diff](https://github.com/radex/swift_stdlib/commit/41b16dcb61fc8dba15ee6385777dc6c2daadcc51.diff)\n* [Fixed compiler crashes](https://github.com/practicalswift/swift-compiler-crashes/commit/c3c374d3ff3c9a6d8864537550529d12d19a4abb)\n* [Xcode release notes](http://ksm.github.io/SwiftInFlux/docs/6.1-beta3.pdf)\n* [Airspeed Velocity](http://airspeedvelocity.net/2014/10/01/changes-to-the-swift-standard-library-in-1-1-beta-3/)\n\nBeta 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.\n\n\u003e The nomenclature is admittedly confusing here.  I'd recommend that you ignore the label, and work with a functional description:\n\u003e\n\u003e What you need to know:\n\u003e  - 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.\n\u003e  - This beta includes the iOS 8.1 beta SDK, but you cannot submit apps to the iOS app store with this Xcode build.\n\u003e  - Further updates of 6.1 are expected before the \"final GM seed\" is released on the Mac App Store.\n\u003e\n\u003e — [Chris Lattner](https://devforums.apple.com/message/1052305#1052305)\n\n### `LiteralConvertible` protocols use constructor\n\nObjects implementing the various `LiteralConvertible` protocols need to implement an `init` method instead of a class method.\n\nFor example:\n\n```swift\nprotocol BooleanLiteralConvertible {\n    typealias BooleanLiteralType\n    init(booleanLiteral value: BooleanLiteralType)\n}\n```\n\n### Other changes in Xcode 6.1 Beta 3 / GM Seed 1\n\n* `Any` can now refer to functions.\n\n## Changed in Xcode 6.1 Beta 2\n\n### Failable initializers in Objective-C frameworks\n\nObjective-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?`.\n\nFor example:\n\n```swift\ninit?(contentsOfFile path: String, encoding: NSStringEncoding, error: NSErrorPointer)\n```\n\nSource: [Xcode 6.1 Beta 2 release notes](http://ksm.github.io/SwiftInFlux/docs/6.1-beta2.pdf)\n\n### Redefinition of private entities\n\nIt'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.\n\nSource: [Xcode 6.1 Beta 2 release notes](http://ksm.github.io/SwiftInFlux/docs/6.1-beta2.pdf)\n\n### Other changes in Xcode 6.1 Beta 2\n\n* 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)\n* 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.\n    Example:\n    \n    ```swift\n    enum Foo: Int { case A = 0, B = 1, C = 2 }\n    let foo = Foo(rawValue: 2)! // formerly 'Foo.fromRaw(2)!'\n    println(foo.rawValue) // formerly 'foo.toRaw()'\n    ```\n* Nested functions that recursively reference themselves or other functions inside the same outer function will no longer crash the compiler.\n\nSource: [Xcode 6.1 Beta 2 release notes](http://ksm.github.io/SwiftInFlux/docs/6.1-beta2.pdf)\n\n\n## Changed in Xcode 6.1 Beta 1\n\n### Failable initializers\n\nInitializers can now fail by returning `nil`. A failable initializer is declared with `init?` to return an \nexplicit optional or `init!` to return an implicitly unwrapped optional. For example, you could \nimplement `String.toInt` as a failable initializer of `Int` like this:\n\n```swift\nextension Int {\n  init?(fromString: String) {\n    if let i = fromString.toInt() {\n      // Initialize \n      self = i \n    } else { \n      // Discard self and return 'nil'. \n      return nil \n    } \n  }\n}\n```\n\nThe result of constructing a value using a failable initializer then becomes optional:\n\n```swift\nif let twentytwo = Int(fromString: \"22\") {\n  println(\"the number is \\(twentytwo)”)\n} else {\n  println(\"not a number”)\n}\n```\n\nIn the current implementation, `struct` and `enum` initializers can return `nil` at any point inside \nthe initializer, but class initializers can only return `nil` after all of the stored properties of the \nobject have been initialized and `self.init` or `super.init` has been called. If `self.init` or \n`super.init` is used to delegate to a failable initializer, then the `nil` return is implicitly \npropagated through the current initializer if the called initializer fails.\n\n\u003e 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.\n\u003e\n\u003e — Chris Lattner\n\nSource: [Xcode 6.1 Beta 1 release notes](http://ksm.github.io/SwiftInFlux/docs/6.1-beta1.pdf), https://devforums.apple.com/message/1042776#1042776\n\n\n### Other changes in Xcode 6.1 Beta 1\n\nBeta 1 has very few developer-facing changes in the standard library:\n\n* `compare` method on `String` is removed\n* `StaticString`'s `start` was renamed to `utf8String`, there's also a new `withUTF8Buffer` method and `unicodeScalar` property\n* `StrideTo` and `StrideThrough` are now `Reflectable`\n* `AssertString` and `StaticString` are now `Printable` and `DebugPrintable`\n* New `unsafeAddressOf` function that can be used to identify objects\n\n**Further reading**:\n\n* [Airspeed Velocity](http://airspeedvelocity.net/2014/09/10/changes-to-the-swift-standard-library-in-xcode-6-1/)\n* [Xcode release notes](http://ksm.github.io/SwiftInFlux/docs/6.1-beta1.pdf)\n\n___\n\n## Changed in Xcode 6.0 GM / 6.0.1\n\nXcode 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\n\n## Changed in Xcode 6.0 Beta 7\n\n_This section needs expanding. [Please contribute.](#contribute)_\n\n## Changed in Xcode 6.0 Beta 6\n\n### Refinements to nil coalescing operator\n\nXcode 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:\n\n```swift\nlet a: Int? = nil\nlet b: Int? = nil\n\na ?? b ?? 0\n```\n\nIn the example above, the first chained expression that doesn't evaluate to `nil` will be used as the value of the entire operation.\n\nPreviously, 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/)\n\nSources: [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/)\n\n### Optionals in Foundation\n\n\u003e 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.\n\u003e\n\u003e These changes replace T! with either T? or T depending on whether the value can be null (or not) respectively.\n\nSource: [Xcode 6.0 Beta 6 release notes](http://ksm.github.io/SwiftInFlux/docs/beta6.pdf)\n\n### Boolean semantics of types\n\nImplicitly 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))\n\nMeanwhile, non-optional types may no longer be compared to `nil`.\n\nSource: [Xcode 6.0 Beta 6 release notes](http://ksm.github.io/SwiftInFlux/docs/beta6.pdf)\n\n### Other changes in Xcode 6.0 Beta 6\n\n* 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))\n* `Optional.hasValue` was removed\n* `RawOptionSetType` (used by imported `NS_OPTIONS`) now supports bitwise assignment operators\n* 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)).\n* Messages in `assert` calls can now use string interpolation\n* 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)\n* Arbitrary implicit conversions between types using `__conversion() -\u003e 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/).\n\nFurther reading:\n\n* [Xcode 6.0 Beta 6 release notes](http://ksm.github.io/SwiftInFlux/docs/beta6.pdf)\n* [Airspeed velocity](http://airspeedvelocity.net)\n\n## Changed in Xcode 6.0 Beta 5\n\n### `dynamic` declaration modifier\n\n`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.\n\nBefore 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:\n\n\u003e 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).\n\u003e\n\u003e 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.\n\nSource: [Xcode 6.0 Beta 5 release notes](http://ksm.github.io/SwiftInFlux/docs/beta5.pdf)\n\n\n### Mutable optional value types\n\nFrom [Xcode 6.0 Beta 5 release notes](http://ksm.github.io/SwiftInFlux/docs/beta5.pdf):\n\n\u003e The optional unwrapping operator x! can now be assigned through. Mutating methods and operators can be applied through it.\n```swift\nvar x: Int! = 0\nx! = 2\nx!++\n// Nested dictionaries can now be mutated directly:\nvar sequences = [\"fibonacci\": [1, 1, 2, 3, 0]]\nsequences[\"fibonacci\"]![4] = 5\nsequences[\"fibonacci\"]!.append(8)\n```\n\u003e The ? chaining operator can also be used to conditionally assign through an optional if it has a ! value:\n```swift\nsequences[\"fibonacci\"]?.append(0)\nsequences[\"fibonacci\"]?[6] = 13\nsequences[\"perfect\"]?[0] = 6 // Does nothing because the sequence has no 'perfect' key\n```\n\nPreviously:\n\n\u003e 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.\n\u003e 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:\n```\nclass StringArray {\n    var elts : String[]\n}\nvar myArray: StringArray?\n```\n\u003e We consider this a significant problem and are investigating various solutions to incorporate in a later Beta.\n\u003e\n\u003e — Chris Lattner\n\nSources: https://devforums.apple.com/message/998882#998882 [Xcode 6.0 Beta 5 release notes](http://ksm.github.io/SwiftInFlux/docs/beta5.pdf)\n\n### Nil coalescing operator\n\nA 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.\n\nFor example:\n\n```swift\nvar myArray: [Int] = []\nprint(myArray.first ?? 0) // produces 0, because myArray.first is nil\nmyArray.append(22)\nprint(myArray.first ?? 0) // produces 22, the value of myArray.first\n```\n\nSources: [Xcode 6.0 Beta 5 release notes](http://ksm.github.io/SwiftInFlux/docs/beta5.pdf)\n\n### Revised attributes\n\nFollowing 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.\n\n\u003e The `@assignment` attribute has been removed from operator implementations.\n\u003e\n\u003e The `@prefix`, `@infix`, and `@postfix` attributes have been changed to declaration modifiers,\n\u003e so they are no longer spelled with an `@` sign (now, `prefix func (...)`). Operator declarations\n\u003e have been rearranged from `operator prefix - {}` to `prefix operator - {}` for consistency.\n\u003e\n\u003e The `@class_protocol` attribute has been removed; the new syntax for declaring that only protocol conformance is limited to classes is `'protocol P : class { ... }’`.\n\u003e\n\u003e The @auto_closure attribute has been renamed to @autoclosure.\n\u003e\n\u003e — Xcode 6.0 Beta 5 release notes\n\nSource: [Xcode 6.0 Beta 5 release notes](http://ksm.github.io/SwiftInFlux/docs/beta5.pdf)\n\n### Boolean semantics of optionals\n\nOptional values no longer conform to `BooleanType` (formerly `LogicValue`) protocol, which means that:\n\n\u003e (...) they may no longer be used in place of boolean expressions (they must be explicitly compared with v != nil).\n\u003e\n\u003e — Xcode 6.0 Beta 5 release notes\n\nBefore this change, the boolean semantics of optionals were confusing when the optional wrapped a value that was a `BooleanType` itself:\n\n```swift\nvar foo: Bool? = false\n// This would print bar\nif foo {\n    println(\"bar\")\n}\n```\n\nSource: [Xcode 6.0 Beta 5 release notes](http://ksm.github.io/SwiftInFlux/docs/beta5.pdf)\n\n### Ranges, Intervals, Striding\n\nFollowing 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:\n\n\u003e The idea of a Range has been split into three separate concepts:\n\u003e\n\u003e * Ranges, which are Collections of consecutive discrete `ForwardIndexType` values. Ranges are used for slicing and iteration.\n\u003e * Intervals over `Comparable` values, which can efficiently check for containment. Intervals are used for pattern matching in switch statements and by the `~=` operator.\n\u003e * Striding over `Strideable` values, which are `Comparable` and can be advanced an arbitrary distance in O(1).\n\u003e\n\u003e Some of the types most commonly used with the range operators `..\u003c` 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..\u003c10`, the result is a _Range_.\n\u003e\n\u003e 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`.\n\u003e\n\u003e ```\n1\u003e 1...0\nfatal error: Can't form Range with end \u003c start\n\u003e ```\n\u003e\n\u003e `Intervals` are represented by two generic types, `HalfOpenInterval\u003cT\u003e`, created by the `..\u003c` operator, and `ClosedInterval\u003cT\u003e`, created by the `...` operator:\n\u003e ```\n1\u003e 3.14..\u003c12\n$R0: HalfOpenInterval\u003cDouble\u003e = {\n  _start = 3.1400000000000001\n  _end = 12\n}\n2\u003e 22...99.1\n$R1: ClosedInterval\u003cDouble\u003e = {\n  _start = 22\n  _end = 99.099999999999994\n}\n\u003e ```\n\u003e\n\u003e A _range_ `x..\u003cy` always has `startIndex == x`. Therefore, `x` is the first valid subscript, and this applies even when the `Index` type is `Int`. In other words, the first valid subscript of `5..\u003c10` is 5, not 0. To prevent surprise, it is a compilation error to subscript a range over an Integer type outside a generic context (for example, expressions like `(5..\u003c10)[0]`).\n\u003e\n\u003e All _Ranges_ are represented by instances of a single generic type, `Range\u003cT\u003e`, 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).\n\nSource: [Xcode 6.0 Beta 5 release notes](http://ksm.github.io/SwiftInFlux/docs/beta5.pdf)\n\n### Required and designated initializers in subclasses\n\nSwift 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.\n\nWhat 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:\n\n```swift\nrequired init(coder: NSCoder) {\n    fatalError(\"Does not implement coding\")\n}\n```\n\nAlso, the compiler now requires overrides of designated initializers to be explicitly marked with `override` and implementations of required initializers — with `required`.\n\nSource: [Xcode 6.0 Beta 5 release notes](http://ksm.github.io/SwiftInFlux/docs/beta5.pdf)\n\n### Other changes\n\nXcode 6.0 Beta 5 has seen a lot of symbols being renamed:\n\n* Protocols were renamed so that they all end with `able`, `ible` or `Type`. For example, `Integer` protocol was renamed to `IntegerType`\n* `LogicValue` was renamed to `BooleanType`\n* `getLogicValue()` became a `boolValue` property and `Optional\u003cT\u003e` additionally has a `hasValue` property\n* `UnsafeArray` and `UnsafeMutableArray` were renamed to `UnsafeBufferPointer` and `UnsafeMutableBufferPointer`\n* `UnsafeConstPointer` and `UnsafePointer` were renamed to `UnsafePointer` and `UnsafeMutablePointer` for consistency and to encourage immutability\n* `reinterpretCast()` was renamed to `unsafeBitCast()`\n\nOther changes in the standard library:\n\n* `+=` operator on arrays can no longer append a single item to the array (you have to wrap it into an array)\n* `String` now has a constructor that takes an integer (you can even supply a radix)\n* New `first`, `last` and `isEmpty` functions\n\nFinally:\n\n* 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)\n* Meanwhile, Xcode can now recompile a single changed file instead of recompiling the whole project.\n* You can now import frameworks in Playgrounds\n* `println()` in Playgrounds now prints next to the line where it's defined (not just printed in the console output)\n\nFurther reading:\n* [Airspeed Velocity](http://airspeedvelocity.net/2014/08/04/changes-in-the-swift-standard-library-in-beta-5/)\n* [Russ Bishop](http://www.russbishop.net/swift-beta-5)\n* [Xcode 6.0 Beta 5 release notes](http://ksm.github.io/SwiftInFlux/docs/beta5.pdf)\n* [Apples to apples, Part II](http://www.jessesquires.com/apples-to-apples-part-two/)\n\n## Changed in Xcode 6.0 Beta 4\n\n### Access control\n\nXcode 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).\n\n\u003e 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.\n\nIt's also possible to define attributes with public getters but private setters using the `private(set)` syntax.\n\nIt has been noted that the current access control design [makes unit testing a bit unwieldy](#limitations-of-current-access-control-design).\n\nSource: [Xcode 6.0 Beta 4 release notes](http://ksm.github.io/SwiftInFlux/docs/beta4.pdf)\n\n### Unicode string improvements\n\nCharacter was changed in Xcode 6.0 Beta 4 to hold a full grapheme cluster instead of a single code point.\n\n\u003e Certain accented characters (like é) can be represented either as a single code point or as a sequence of two or more code points (e + ́)\n\nBefore 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.\n\nIn 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\n\nSources: http://oleb.net/blog/2014/07/swift-strings/ https://devforums.apple.com/message/1007773#1007773\n\n### Numerical data type conversion, e.g. CGFloat and Swift Double/Swift Float\n\nFrom Xcode 6.0 Beta 4 Release Notes:\n\u003eCGFloat is now a distinct floating-point type that wraps either a Float on 32-bit architectures or a Double on 64-bit architectures.\n\nSources:\n[Xcode 6.0 Beta 4 release notes](http://ksm.github.io/SwiftInFlux/docs/beta4.pdf)\n\n\u003eWhat 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.\n\u003e\n\u003eWe'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 :-)\n\u003e\n\u003e — Chris Lattner\n\nSources: https://devforums.apple.com/message/998222#998222\n\n### Revised declaration modifiers\n\n\u003e The @final, @lazy, @optional, and @required attributes have been converted to declaration modifiers, specified without an @ sign.\n\nSource: [Xcode 6.0 Beta 4 release notes](http://ksm.github.io/SwiftInFlux/docs/beta4.pdf)\n\n### New stride() functions\n\n\u003e The .by() method for ranges has been replaced with general stride() functions. To\nadopt stride(), use stride(from: to: by:) for exclusive ranges and stride(from: through: by:) for inclusive ranges.\n\nFor example, you can now do:\n\n```swift\nstride(from: x, to: y, by: z)      // was: (x..\u003cy).by(z)\nstride(from: x, through: y, by: z) // was: (x...y).by(z)\n```\n\nSource: [Xcode 6.0 Beta 4 release notes](http://ksm.github.io/SwiftInFlux/docs/beta4.pdf)\n\n### Set of legal operator characters\n\nWith release of Xcode 6.0 Beta 4, the full grammar of operators was specified.\n\nhttps://developer.apple.com/library/prerelease/mac/documentation/Swift/Conceptual/Swift_Programming_Language/LexicalStructure.html#//apple_ref/doc/uid/TP40014097-CH30-XID_927\n\n\u003e 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.\n\u003e\n\u003e — Joe Groff\n\n\u003e 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.\n\u003e\n\u003e — Joe Groff\n\nSources: https://devforums.apple.com/thread/231723?tstart=450 https://devforums.apple.com/message/1000934#1000934\n\n### `@IBOutlet`\n\nBefore 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.\n\nPreviously:\n\n\u003e 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.\n\u003e\n\u003e 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.\n\u003e\n\u003e — Chris Lattner\n\nSource: https://devforums.apple.com/message/1002722#1002722\n\n### Fixed: Structs with both @lazy and non-lazy properties crashes compiler\n\nstructs with a @lazy property followed by a non-lazy property crashes\nthe compiler.\n\n\u003e This is fixed, but didn't make it into Beta 3. Stay tuned for a later Beta,\n\u003e\n\u003e — Chris Lattner\n\n[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.\n\nSource: https://devforums.apple.com/message/1000950#1000950\n\n### Other changes to standard library\n\n* `uppercaseString` and `lowercaseString` properties were removed from String\n* `insertionSort` and `quickSort` were removed\n* `CString` was removed. `const char *` values are now imported as `ConstUnsafePointer\u003cInt8\u003e`\n* `modulusWithOverflow` was replaced by `remainderWithOverflow`\n* `Float` and `Double` no longer conform to `RandomAccessIndex`, which means they can no longer be used to index a collection\n* `true` and `false` are now language literals. `Bool` conforms to a new `BooleanLiteralConvertible` protocol that allows user-defined types to support Boolean literals.\n* `ArrayBuffer`, `ArrayBufferType`, `SliceBuffer` and `ContiguousArrayBuffer` were removed (the reason being, those structures were only an implementation detail of corresponding types)\n* `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\n\nSources: 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)\n\n## Changed in Xcode 6.0 Beta 3\n\n### Array and Dictionary type declaration syntax\nBefore Xcode 6.0 Beta 3, the shorthand for an Array type was `Type[]`, and Dictionary types were written `Dictionary\u003cKeyType, ValueType\u003e`. Array type shorthand was changed to `[Type]` and Dictionaries types now have a shorthand syntax `[KeyType: ValueType]` (e.g. `[String: Bool]`)\n\n### Array value semantics\nSince Xcode 6.0 Beta 3, Array has full value semantics to match Dictionary, String and other value types.\n\n\u003eArray 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.\n\u003e\n\u003e — Chris Lattner\n\nSources: https://devforums.apple.com/thread/228695?start=75\u0026tstart=\n\n### Modifying constant properties in designated vs. convenience initializers\n\n\u003e 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.:\n\u003e\n```swift\nclass C {\n  let x : Int   // immutable property\n  init(input : Int) {\n    x = input     // mutating an immutable property!\n  }\n}\n```\n\u003e 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.\n\u003e\n\u003e 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.\n\u003e\n\u003e Long story short, this is a feature, not a bug :-)\n\u003e\n\u003e — Chris Lattner\n\nSource: https://devforums.apple.com/message/1003240#1003240\n\n### Range operators\n\nThe half-open range operator was changed from `..` to `..\u003c`.\n\n\u003e 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\n\u003e\n\u003e 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 ..\u003c is an inclusive range operator (like most assumed when they saw \"0..5\")\n\u003e\n\u003e — Chris Lattner\n\u003e\n\u003e I'd really like it if there was only a single range operator, but that isn't possible (AFAIK):\n\u003e\n\u003e - You need to have a half-open range operator to be able to represent an empty range.\n\u003e - 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)..\n\u003e\n\u003e — Chris Lattner\n\nSources: https://devforums.apple.com/message/1000100#1000100 https://devforums.apple.com/message/999669#999669\n","funding_links":[],"categories":["Swift Websites","Guides","Technical","Others"],"sub_categories":["Third party Guides","ramanihiteshc@gmail.com","OS X"],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fksm%2FSwiftInFlux","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fksm%2FSwiftInFlux","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fksm%2FSwiftInFlux/lists"}