Swift (programming language)

This article is about the Apple programming language. For the parallel scripting language, see Swift (parallel scripting language).
Swift
Paradigm Multi-paradigm (Protocol-oriented programming, object-oriented, functional, imperative, block structured)
Designed by Chris Lattner and Apple Inc.
Developer Apple Inc.
First appeared June 2, 2014 (2014-06-02)[1]
Stable release 2.2.1 [2] / May 3, 2016 (2016-05-03)
Preview release 2.2-branch / April 23, 2016 (2016-04-23)
Typing discipline Static, strong, inferred
OS Darwin, Linux, FreeBSD
License Apache License 2.0 (Swift 2.2 and later)
Proprietary (up to version 2.2)[3][4]
Filename extensions .swift
Website swift.org
Influenced by
C#,[5] CLU,[6] Haskell, Objective-C, Python, Rust, Ruby
Influenced
Ruby,[7] Rust[8]

Swift is a general-purpose, multi-paradigm, compiled programming language created for iOS, OS X, watchOS, tvOS and Linux development by Apple Inc. Swift is designed to work with Apple's Cocoa and Cocoa Touch frameworks and the large body of existing Objective-C code written for Apple products. Swift is intended to be more resilient to erroneous code ("safer") than Objective-C and also more concise. It is built with the LLVM compiler framework included in Xcode 6 and later and uses the Objective-C runtime, which allows C, Objective-C, C++ and Swift code to run within a single program.[9]

Swift supports the core concepts that made Objective-C flexible, notably dynamic dispatch, widespread late binding, extensible programming and similar features. These features also have well known performance and safety trade-offs, which Swift was designed to address. For safety, Swift introduced a system that helps address common programming errors like null pointers, as well as introducing syntactic sugar to avoid the pyramid of doom that can result. For performance issues, Apple has invested considerable effort in aggressive optimization that can flatten out method calls and accessors to eliminate this overhead. More fundamentally, Swift has added the concept of protocol extensibility, an extensibility system that can be applied to types, structs and classes. Apple promotes this as a real change in programming paradigms they refer to as "protocol-oriented programming".[10]

Swift was introduced at Apple's 2014 Worldwide Developers Conference (WWDC).[11] It underwent an upgrade to version 1.2 during 2014 and a more major upgrade to Swift 2 at WWDC 2015. Initially a proprietary language, version 2.2 was made open source and made available under the Apache License 2.0 on December 3, 2015, for Apple's platforms and Linux.[12][13] IBM announced its Swift Sandbox website, which allows developers to write Swift code in one pane and display output in another.[14][15][16]

A second free implementation of Swift that in addition to Cocoa also targets Microsoft's Common Language Infrastructure (a.k.a. .NET) and the Java/Android platform exists as part of the Elements Compiler from RemObjects Software.[17]

History

Development on Swift was begun in July 2010 by Chris Lattner, with the eventual collaboration of many other programmers at Apple. Swift took language ideas "from Objective-C, Rust, Haskell, Ruby, Python, C#, CLU, and far too many others to list".[6] On June 2, 2014, the Worldwide Developers Conference (WWDC) application became the first publicly released app written in Swift.[18] A beta version of the programming language was released to registered Apple developers at the conference, but the company did not promise that the final version of Swift would be source-compatible with the test version. Apple planned to make source code converters available if needed for the full release.[18]

The Swift Programming Language, a free 500-page manual, was also released at WWDC, and is available on the iBooks Store as well as on official website.[19]

Swift reached the 1.0 milestone on September 9, 2014, with the "Gold Master" of Xcode 6.0 for iOS.[20] Swift 1.1 was released on October 22, 2014, alongside the launch of Xcode 6.1.[21] Swift 1.2 was released on April 8, 2015, in conjunction with Xcode 6.3.[22] Swift 2.0 was announced at WWDC 2015, and was made available for publishing apps in the App Store in September 21, 2015.[23] A Swift 3.0 roadmap was announced on the Swift blog on December 3, 2015.[24] However, prior to that an intermediate Swift 2.2 version[25] embracing new syntax and features has been introduced. This also shuns certain outdated components including Tuple splat syntax, C-style for loops and ++ and -- operators.

Swift won first place for Most Loved Programming Language in the Stack Overflow Developer Survey 2015[26] and second place in 2016.[27]

Google is said to be considering using Swift as a First Class Language in its Android operating system.[28]

Features

Swift is an alternative to the Objective-C language that employs modern programming-language theory concepts and strives to present a simpler syntax. During its introduction, it was described simply as "Objective-C without the C".[29][30]

By default, Swift does not expose pointers and other unsafe accessors, in contrast to Objective-C, which uses pointers pervasively to refer to object instances. Additionally, Objective-C's use of a Smalltalk-like syntax for making method calls has been replaced with a dot-notation style and namespace system more familiar to programmers from other common object-oriented (OO) languages like Java or C#. Swift introduces true named parameters and retains key Objective-C concepts, including protocols, closures and categories, often replacing former syntax with cleaner versions and allowing these concepts to be applied to other language structures, like enums.

Types, variables and scoping

Under the Cocoa and Cocoa Touch environments, many common classes were part of the Foundation Kit library. This included the NSString string library (using Unicode), the NSArray and NSDictionary collection classes, and others. Objective-C provided various bits of syntactic sugar to allow some of these objects to be created on-the-fly within the language, but once created the objects were manipulated with object calls. For instance, concatenating two NSStrings required method calls similar to this:

NSString *str = @"hello,";
str = [str stringByAppendingString:@" world"];

In Swift, many of these basic types have been promoted to the language's core, and can be manipulated directly. For instance, strings are invisibly bridged to NSString (when Foundation is imported) and can now be concatenated with the + operator, allowing greatly simplified syntax; the previous example becoming:[31]

var str = "hello,"
str += " world"

Though they were omitted in the early betas,[32] Swift supports three access control levels for symbols: public, internal, and private. Unlike many object-oriented languages, these access controls ignore inheritance hierarchies: "private" indicates that a symbol is accessible only in the containing source file, "internal" indicates it is accessible within the containing module, and "public" indicates it is accessible from any module.[33] The decision to omit the traditional "protected" scope met with some controversy.[34]

Optionals and chaining

An important new feature in Swift is option types, which allow references or values to operate in a manner similar to the common pattern in C, where a pointer may refer to a value or may be null. This implies that non-optional types cannot result in a null-pointer error; the compiler can ensure this is not possible.

Optional types are created with the Optional mechanism—to make an Integer that is nullable, one would use a declaration similar to var optionalInteger: Optional<Int>. As in C#,[35] Swift also includes syntactic sugar for this, allowing one to indicate a variable is optional by placing a question mark after the type name, var optionalInteger: Int?.[36] Variables or constants that are marked optional either have a value of the underlying type or are nil. Optional types wrap the base type, resulting in a different instance. String and String? are fundamentally different types, the latter has more in common with Int? than String.

To access the value inside, assuming it is not nil, it has to be unwrapped to expose the instance inside. This is accomplished with the ! operator:

    let myValue = anOptionalInstance!.someMethod()

In this case, the ! operator unwraps anOptionalInstance to expose the instance inside, allowing the method call to be made on it. If anOptionalInstance is nil, a null-pointer error occurs. This can be annoying in practice, so Swift also includes the concept of optional chaining to test whether the instance is nil and then unwrap it if it is non-null:

    let myValue = anOptionalInstance?.someMethod()

In this case the runtime only calls someMethod if anOptionalInstance is not nil, suppressing the error. Normally this requires the programmer to test whether myValue is nil before proceeding. The origin of the term chaining comes from the more common case where several method calls/getters are chained together. For instance:

    let aTenant = aBuilding.TenantList[5]
    let theirLease = aTenant.leaseDetails
    let leaseStart = theirLease.startDate

can be reduced to:

   let leaseStart = aBuilding.TenantList[5]?.leaseDetails?.startDate

The ? syntax allows the pyramid of doom to be avoided.

Swift 2 introduced the new guard keyword for cases in which code should not continue executing if a certain condition is not met:

    guard let leaseStart = aBuilding.TenantList[5]?.leaseDetails?.startDate else {
        //handle the error case where anything in the chain is nil
        //else scope must exit the current method or loop
    }
    //continue on, knowing that leaseStart is not nil

Using guard has three benefits. While the syntax can act as an if statement, its primary benefit is inferring non-nullability. Where an if statement requires a case, guard assumes the case based on the condition provided. Additionally, since guard contains no scope, with exception of the else closure, leaseStart is presented as an unwrapped optional to the guard's super-scope. Lastly, if the guard statement's test fails, Swift requires the else to exit the current method or loop, ensuring leaseStart never is accessed when nil. This is accomplished with the return, continue, or break keywords.

ObjC was weakly typed, and allowed any method to be called on any object at any time. If the method call failed, there was a default handler in the runtime that returned nil. That meant that no unwrapping or testing was needed, the equivalent statement in ObjC:

    leaseStart = [[[aBuilding tenantList:5] leaseDetails] startDate]

would return nil and this could be tested. However, this also demanded that all method calls be dynamic, which introduces significant overhead. Swift's use of optionals provides a similar mechanism for testing and dealing with nils, but does so in a fashion that allows the compiler to use static dispatch because the unwrapping action is called on a defined instance (the wrapper), as opposed to taking place in the runtime dispatch system.

Value types

In many object-oriented languages, objects are represented internally in two parts; the object itself is stored as a block of data placed on the heap, while the name (or "handle") to that object is represented by a pointer. Objects are passed between methods by copying the value of the pointer, allowing the same underlying data on the heap to be accessed by anyone with a copy. In contrast, basic types like integers and floating point values are represented directly, the handle contains the data, not a pointer to it, and that data is passed directly to methods by copying. The two styles of access are known as pass-by-reference in the case of objects, and pass-by-value for basic types.

The two concepts both have their advantages and disadvantages. Objects are useful when the data is large, like the description of a window or the contents of a document. In these cases, access to that data is provided by copying a 32- or 64-bit value, as opposed to the entire data structure. However, smaller values like integers are the same size as pointers (typically both are a single word), so there is no advantage to passing a pointer as opposed to the value itself. Additionally, pass-by-reference inherently requires a dereferencing operation, which can produce noticeable overhead in certain operations, typically those used with these basic value types, like mathematics.

Similarly to C# and in contrast to most other OO languages, Swift offers built-in support for objects using either pass-by-reference or pass-by-value semantics, the former using the class declaration and the latter using struct. Structs in Swift have almost all the same features as classes; methods, implementing protocols, and using the extension mechanisms. For this reason, Apple refers to all data generically as instances as opposed to objects or values. Structs do not support inheritance, however.[37]

The programmer is free to choose which semantics are more appropriate for each data structure in the application. Larger structures like windows would be defined as classes, allowing them to be passed around as pointers. Smaller structures, like a 2D point, can be defined as structs, which will be pass-by-value and allow direct access to their internal data without a dereference. The performance improvement inherent to the pass-by-value concept is such that Swift uses these types for almost all common data types, including Int and Double, as well as types normally represented by objects, like String and Array.[37] Using value types can result in significant performance improvements in user applications as well.[38]

To ensure that even the largest structs do not cause a performance penalty when they are handed off, Swift uses copy on write so that the objects are only copied if and when the program attempts to change a value in them. This means that the various accessors actually have what is in effect a pointer to the same data storage, but this takes place far below the level of the language, in the computer's memory management unit (MMU). So while the data is physically stored as a single instance in memory, at the level of the application these values are completely separate, and physical separation is enforced by copy on write only if needed.[39]

Protocol-oriented programming

A key feature of ObjC is its support for categories, methods that can be added to existing classes at runtime. Categories allow programmers to extend classes in-place to add new functionality without having to subclass or even have access to the original source code. An example might be to add spell checking support to the base NSString class, which means all instances of NSString in the application gain spell checking. The system is also widely used as an organizational technique, allowing related code to be gathered into library-like extensions. Swift continues to support this concept, although they are now known as extensions and declared with the extension keyword. Unlike ObjC, Swift can also add new properties, types and enums to existing instances.

Another key feature of ObjC is its use of protocols, known in most modern languages as interfaces. Protocols promise that a particular class implements a set of methods, meaning that other objects in the system can call those methods on any object supporting that protocol. This is often used in modern OO languages as a substitute for multiple inheritance, although the feature sets are not entirely similar. A common example of a protocol in Cocoa is the NSCopying protocol, which defines a single method, copyWithZone, that implements deep copying on objects.[40]

In ObjC, and most other languages implementing the protocol concept, it is up to the programmer to ensure that the required methods are implemented in each class.[41] Swift adds the ability to add these methods using extensions, and to use generics to implement them. Combined, these allow protocols to be written once and support a wide variety of instances. Additionally, the extension mechanism can be used to add protocol conformance to an object that does not list that protocol in its definition.[40]

For example, one might declare a protocol called SupportsToString which ensures that instances that conform to the protocol implement a toString method that returns a String. In Swift, this can be declared with code like this:

protocol SupportsToString {
    func toString() -> String
}

This protocol can now be added to String, without access to the base class's source:

extension String: SupportsToString {
    func toString() -> String {
        return self
    }
}

In Swift, like many modern languages supporting interfaces, protocols can be used as types, which means variables and methods can be defined by protocol instead of their specific type:

var someSortOfPrintableObject: SupportsToString
...
print(someSortOfPrintableObject.toString())

It does not matter what sort of instance someSortOfPrintableObject is, the compiler will ensure that it conforms to the protocol and thus this code is safe. This syntax also means that collections can be based on protocols as well, like let printableArray = [SupportsToString]. Methods can also be limited to ensure only conforming instances are passed in:[40]

func PrintOneIfEqual(one: protocol<SupportsToString, Equatable>, two: protocol<Equatable>) {
    if one == two {
        print(one.toString)
    }
}

In this case, the function will accept any two instances as long as the first conforms to both SupportsToString and Equatable, and the second conforms to Equatable. This might be used, for instance, in the case when the first object is a CelsiusTemperature that includes conversion functions and toString, while the second might be a Double value, which Temperature allows to be compared to its internal Celsius value; PrintOneIfEqual(theTemperature, 45.0) This concept can be used to build protocol conformance onto a wide variety of objects with a single extension method, without the need to define separate extensions for each type.[40]

As Swift treats structs and classes as similar concepts, both extensions and protocols are extensively used in Swift's runtime to provide a rich API based on structs. For instance, Swift uses an extension to add the Equatable protocol to many of their basic types, like Strings and Arrays, allowing them to be compared with the == operator. A concrete example of how all of these features interact can be seen in the concept of default protocol implementations:

func !=<T : Equatable>(lhs: T, rhs: T) -> Bool

This function defines a method that works on any instance conforming to Equatable, providing a "not equals" function. Any instance, class or struct, automatically gains this implementation simply by conforming to Equatable. As many instances gain Equatable through their base implementations or other generic extensions, most basic objects in the runtime gain equals and not equals without any code.[42]

This combination of protocols, defaults, protocol inheritance, and extensions allows much of the functionality normally associated with classes and inheritance to be implemented on value types.[40] Properly used, this can lead to dramatic performance improvements without suffering significant limitations in terms of API. This concept is so widely used within Swift that Apple has begun referring to it as a protocol-oriented programming language. They suggest addressing many of the problem domains normally solved though classes and inheritance using protocols and structs instead.

Libraries, runtime and development

Swift uses the same runtime as the existing Objective-C system but requires iOS 7 / OS X 10.9 or higher.[43] Swift and Objective-C code can be used in a single program, and by extension, C and C++ as well. In contrast to C however, C++ code cannot be used directly from Swift. It is necessary to create an Objective-C or C wrapper between Swift and C++.[44] In the case of Objective-C, Swift has considerable access to the object model, and can be used to subclass, extend and use Objective-C code to provide protocol support.[45] The converse is not true: a Swift class cannot be subclassed in Objective-C.[46]

To aid development of such programs, and the re-use of existing code, Xcode 6 offers a semi-automated system that builds and maintains a "bridging header" to expose Objective-C code to Swift. This takes the form of an additional header file that simply defines or imports all of the Objective-C symbols that are needed by the project's Swift code. At that point, Swift can refer to the types, functions, and variables declared in those imports as though they were written in Swift. Objective-C code can also use Swift code directly, by importing an automatically maintained header file with Objective-C declarations the project's Swift symbols. For instance, an Objective-C file in a mixed project called "MyApp" could access Swift classes or functions with the code #import "MyApp-Swift.h". Not all symbols are available through this mechanism, however—use of Swift-specific features like generic types, non-object optional types, sophisticated enums, or even Unicode identifiers may render a symbol inaccessible from Objective-C.[47]

Swift also has limited support for attributes, metadata that is read by the development environment, and is not necessarily part of the compiled code. Like Objective-C, attributes use the @ syntax, but the currently available set is small. One example is the @IBOutlet attribute, which marks a given value in the code as an "outlet", available for use within Interface Builder (IB). An "outlet" is a device that binds the value of the on-screen display to an object in code.

Memory management

Swift uses Automatic Reference Counting (ARC) to manage memory. Apple used to require manual memory management in Objective-C, but introduced ARC in 2011 to allow for easier memory allocation and deallocation.[48] One problem with ARC is the possibility of creating a strong reference cycle, where instances of two different classes each include a reference to the other, causing them to become leaked into memory as they are never released. Swift provides the weak and unowned keywords that allow the programmer to prevent strong reference cycles from occurring. Typically a parent-child relationship would use a strong reference while a child-parent would use either weak reference, where parents and children can be unrelated, or unowned where a child always has a parent, but parent may not have a child. Weak references must be optional variables, since they can change and become nil.[49]

A closure within a class can also create a strong reference cycle by capturing self references. The programmer can indicate which self references should be treated as weak or unowned using a capture list.

Debugging and other elements

A key element of the Swift system is its ability to be cleanly debugged and run within the development environment, using a read–eval–print loop (REPL), giving it interactive properties more in common with the scripting capabilities of Python than traditional systems programming languages. The REPL is further enhanced with the new 'playgrounds' concept; 'playgrounds' are interactive views running within the Xcode environment that respond to code or debugger changes on-the-fly.[50] If the code in question changes over time or with regard to some other ranged input value, the view can be used with the Timeline Assistant to demonstrate the output in an animated fashion. Apple claims that Swift "is the first industrial-quality systems programming language that is as expressive and enjoyable as a scripting language".[51]

Similarities to C

Similarities to Objective-C

Differences from Objective-C

Example code

// this is a single line comment using two slashes.

/* this is also a comment,
   but written over multiple lines */

/* multiline comments
   /* can be nested! */
   Therefore you can block out code containing multiline
   comments
*/

// Swift variables are declared with "var"
// this is followed by a name, a type, and a value
var explicitDouble: Double = 70

// If the type is omitted, Swift will infer it from
// the variable's initial value
var implicitInteger = 70
var implicitDouble = 70.0
var  = "美國"

// Swift constants are declared with "let"
// followed by a name, a type, and a value
let numberOfBananas: Int = 10

// Like variables, if the type of a constant is omitted,
// Swift will infer it from the constant's value
let numberOfApples = 3
let numberOfOranges = 5

// Values of variables and constants can both be
// interpolated in strings as follows
let appleSummary = "I have \(numberOfApples) apples."
let fruitSummary = "I have \(numberOfApples + numberOfOranges) pieces of fruit."

// In "playgrounds", code can be placed in the global scope
print("Hello, world")

// This is an array variable
var fruits = ["mango", "kiwi", "avocado"]

// Example of an if statement; .isEmpty, .count
if fruits.isEmpty {
    print("No fruits in my array.")
} else {
    print("There are \(fruits.count) items in my array")
}

// Define a dictionary with four items:
// Each item has a person's name and age
let people = ["Anna": 67, "Beto": 8, "Jack": 33, "Sam": 25]

// Now we use Swift's flexible enumerator system
// to extract both values in a single loop
for (name, age) in people {
    print("\(name) is \(age) years old.")
}

// Functions and methods are both declared with the
// "func" syntax, and the return type is specified with ->
func sayHello(personName: String) -> String {
    let greeting = "Hello, \(personName)!"
    return greeting
}

// prints "Hello, Dilan!"
print(sayHello("Dilan"))

// Parameter names can be made external and required
// for calling.
// The external name can be the same as the parameter
// name by prefixing with an octothorpe (#)
// - or it can be defined separately.

func sayAge(personName personName: String, personAge age: Int) -> String {
    let result = "\(personName) is \(age) years old."
    return result
}

// We can also specify the name of the parameter

print(sayAge(personName: "Dilan", personAge: 42))

See also

References

  1. "Swift Has Reached 1.0". Apple. September 9, 2014. Retrieved March 8, 2015.
  2. https://swift.org/download/#releases
  3. "Swift, Objectively". Swift is proprietary and closed: It is entirely controlled by Apple and there is no open source implementation.
  4. Lattner, Chris (June 11, 2014). "Re: [LLVMdev] [cfe-dev] [ADVERTISEMENT] open positions in Apple's Swift compiler team". Retrieved June 12, 2014. You can imagine that many of us want it to be open source and part of llvm, but the discussion hasn't happened yet, and won't for some time.
  5. Lattner, Chris (2014-06-03). "Chris Lattner's Homepage". Chris Lattner. Retrieved 2014-06-03. The Swift language is the product of tireless effort from a team of language experts, documentation gurus, compiler optimization ninjas, and an incredibly important internal dogfooding group who provided feedback to help refine and battle-test ideas. Of course, it also greatly benefited from the experiences hard-won by many other languages in the field, drawing ideas from Objective-C, Rust, Haskell, Ruby, Python, C#, CLU, and far too many others to list.
  6. 1 2 Lattner, Chris (June 3, 2014). "Chris Lattner's Homepage". Chris Lattner. Retrieved June 3, 2014. I started work on the Swift Programming Language in July of 2010. I implemented much of the basic language structure, with only a few people knowing of its existence. A few other (amazing) people started contributing in earnest late in 2011, and it became a major focus for the Apple Developer Tools group in July 2013 [...] drawing ideas from Objective-C, Rust, Haskell, Ruby, Python, C#, CLU, and far too many others to list.
  7. "Ruby 2.3 on Heroku with Matz". Retrieved January 31, 2016. I’m excited about the safe navigation operator, or “lonely operator.” It’s similar to what we see in other programming languages like Swift and Groovy— it makes it simple to handle exceptions.
  8. "RFC for `if let` expression". Retrieved December 4, 2014. The 'if let' construct is based on the precedent set by Swift, which introduced its own 'if let' statement.
  9. Timmer, John (June 5, 2014). "A fast look at Swift, Apple's new programming language". Ars Technica. Condé Nast. Retrieved June 6, 2014.
  10. Protocol-oriented Programming in Swift. Apple Inc. (YouTube).
  11. Williams, Owen (June 2, 2014). "Tim Berners-Lee's sixtieth birthday Apple announces Swift, a new programming language for iOS". The Next Web. Retrieved June 2, 2014.
  12. "Apple's new programming language Swift is now open source". The Verge. Retrieved 2015-12-05.
  13. "Apple Open Sources Swift in Latest Pitch to the Enterprise". CIO Journal. The Wall Street Journal Blogs. 2015-12-03. Retrieved 2015-12-05. (registration required (help)).
  14. "Introducing the IBM Swift Sandbox - Swift". Swift. Retrieved 2015-12-05.
  15. Mayo, Benjamin. "Write Swift code in a web browser with the IBM Swift Sandbox". 9to5Mac. Retrieved 2015-12-05.
  16. "After Apple open sources it, IBM puts Swift programming in the cloud | ZDNet". ZDNet. Retrieved 2015-12-05.
  17. "RemObjects Elements Compiler". Retrieved 2016-01-17.
  18. 1 2 Platforms State of the Union, Session 102, Apple Worldwide Developers Conference, June 2, 2014
  19. The Swift Programming Language. Apple. June 2, 2014. Retrieved June 2, 2014. Lay summary.
  20. "Swift Has Reached 1.0". September 9, 2014. Retrieved September 10, 2014.
  21. "Xcode 6.1 Release Notes". October 22, 2014. Retrieved January 23, 2015.
  22. "Xcode 6.3 Release Notes". April 8, 2015. Retrieved April 8, 2015.
  23. "Swift 2 Apps in the App Store - Swift Blog". developer.apple.com. Retrieved 2016-03-13.
  24. http://thenextweb.com/apple/2015/12/03/apple-has-big-plans-for-swift-3-0-and-beyond-including-api-changes-and-working-with-c/
  25. https://swift.org/blog/swift-2-2-new-features/
  26. "Stack Overflow Developer Survey Results 2015".
  27. "Stack Overflow Developer Survey Results 2016".
  28. "Google is said to be considering Swift as a ‘first class’ language for Android".
  29. Metz, Rachel (June 3, 2014). "Apple Seeks a Swift Way to Lure More Developers". Technology Review.
  30. Weber, Harrison (June 2, 2014). "Apple announces 'Swift,' a new programming language for OS X & iOS". VentureBeat.
  31. "Strings and Characters". developer.apple.com. Apple Inc. Retrieved July 16, 2014.
  32. Parker, Greg (June 2, 2014). "Access modifiers in Swift (private, protected, public)". devforums.apple.com. Retrieved July 16, 2014. (registration required (help)). We don't usually promise anything for the future, but in this case we are making an exception. Swift will have access control mechanism
  33. "Access Control". developer.apple.com. Apple Inc. Retrieved July 22, 2014.
  34. "No protected access modifier?". devforums.apple.com. July 21, 2014. Retrieved July 28, 2014. (registration required (help)).
  35. "Nullable Types", C# Programming Guide, Microsoft.
  36. "Types". developer.apple.com. Apple Inc. Retrieved July 16, 2014.
  37. 1 2 "Classes and Structures". Apple.com.
  38. Guhit, Fiel. "Performance Case Study on Swift 1.1, Swift 1.2, and Objective-C".
  39. Building Better Apps with Value Types. Apple.
  40. 1 2 3 4 5 "NSCopying Protocol Reference". Apple.
  41. "Working with Protocols". Apple.
  42. Thompson, Mattt (September 2, 2014). "Swift Default Protocol Implementations". NSHipster.
  43. "Do Swift-based apps work on OS X 10.9/iOS 7 and lower?", StackOverflow
  44. "Using Swift with Cocoa and Objective-C: Basic Setup". apple.com. January 6, 2015.
  45. "Writing Swift Classes with Objective-C Behavior", Apple Inc.
  46. "Migrating Your Objective-C Code to Swift".
  47. "Swift and Objective-C in the Same Project", Apple Inc.
  48. "Automatic Reference Counting", Apple Inc.
  49. Lanier, Brian; Groff, Joe. "Intermediate Swift". Apple. Retrieved July 3, 2014.
  50. Metz, Cade. "Why Coders Are Going Nuts Over Apple's New Programming Language". Wired. Retrieved July 16, 2014.
  51. About Swift, Apple Inc.
  52. "Error-Handling in Swift-Language". stackoverflow.com.
  53. "apple/swift-evolution". GitHub. Retrieved 2016-04-04.
  54. "apple/swift-evolution". GitHub. Retrieved 2016-04-04.

External links

This article is issued from Wikipedia - version of the Friday, May 06, 2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.