Upgrade to Pro — share decks privately, control downloads, hide ads and more …

swift.next()

 swift.next()

Presented at the inaugural X/UP in London.

With a fantastic new language, unprecedented transparency from Apple, and a vibrant development community, it's never been more exciting to be coding for Apple platforms. But things are moving quickly. This talk will get you up to speed on the future of Swift—including the big breaking changes coming in v3—and the architectural patterns that will be shaping our apps for years to come.

94fc7b58c03a0650fe1e8d78140bd451?s=128

Dan Cutting

May 12, 2016
Tweet

Transcript

  1. swift.next() Dan Cutting @dcutting cutting.io

  2. None
  3. None
  4. None
  5. None
  6. – Steve Jobs, WWDC 2010 Keynote “We're going to the

    standards bodies starting tomorrow, and we're gonna make FaceTime an open industry standard.”
  7. • SE-0007: Remove C-style for-loops with conditions and incrementers •

    SE-0016: Adding initializers to Int and UInt to convert from UnsafePointer and UnsafeMutablePointer • SE-0019: Swift Testing • SE-0023: API Design Guidelines • SE-0028: Modernizing Swift's Debugging Identifiers (__FILE__, etc) • SE-0029: Remove implicit tuple splat behavior from function applications • SE-0031: Adjusting inout Declarations for Type Decoration • SE-0034: Disambiguating Line Control Statements from Debugging Identifiers • SE-0037: Clarify interaction between comments & operators • SE-0039: Modernizing Playground Literals • SE-0040: Replacing Equal Signs with Colons For Attribute Arguments • SE-0043: Declare variables in 'case' labels with multiple patterns • SE-0046: Establish consistent label behavior across all parameters including first labels • SE-0049: Move @noescape and @autoclosure to be type attributes • SE-0053: Remove explicit use of let from Function Parameters • SE-0054: Abolish ImplicitlyUnwrappedOptional type • SE-0055: Make unsafe pointer nullability explicit using Optional • SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly • SE-0061: Add Generic Result and Error Handling to autoreleasepool() • SE-0065: A New Model For Collections and Indices • SE-0069: Mutability and Foundation Value Types • SE-0070: Make Optional Requirements Objective-C-only • SE-0071: Allow (most) keywords in member references • SE-0072: Fully eliminate implicit bridging conversions from Swift • SE-0025: Scoped Access Level • SE-0032: Add find method to SequenceType • SE-0033: Import Objective-C Constants as Swift Types • SE-0035: Limiting inout capture to @noescape contexts • SE-0036: Requiring Leading Dot Prefixes for Enum Instance Member Impleme • SE-0038: Package Manager C Language Target Support • SE-0042: Flattening the function type of unapplied method references • SE-0044: Import as Member • SE-0045: Add scan, prefix(while:), drop(while:), and iterate to the stdlib • SE-0047: Defaulting non-Void functions so they warn on unused results • SE-0048: Generic Type Aliases • SE-0052: Change IteratorType post-nil guarantee • SE-0057: Importing Objective-C Lightweight Generics • SE-0062: Referencing Objective-C key-paths • SE-0063: SwiftPM System Module Search Paths • SE-0064: Referencing the Objective-C selector of property getters and setters • SE-0066: Standardize function type argument syntax to require parentheses • SE-0067: Enhanced Floating Point Protocols • SE-0068: Expanding Swift Self to class members and value types
  8. consistent stable portable

  9. stable

  10. None
  11. None
  12. consistent stable portable

  13. consistent

  14. “Clarity at the point of use”

  15. Write proper-like, innit x.insert(y, position: z) x.subViews(color: y) x.nounCapitalize() x.insert(y,

    at: z) x.subViews(havingColor: y) x.capitalizingNouns()
  16. // Sorts x in-place x.sort() // Returns a sorted copy

    of x let z = x.sorted() // Appends y directly onto x x.append(y) // Returns a copy of x with y appended let z = x.appending(y)
  17. let doubled = [1, 2, 3].map { $0 * 2

    } let doubled = [1, 2, 3].mapped { $0 * 2 }
  18. “Stick to the established meaning if you do use a

    term of art”
  19. “Better Translation of Objective-C APIs Into Swift”

  20. let content = listItemView.text.stringByTrimmingCharactersInSet( NSCharacterSet.whitespaceAndNewlineCharacterSet()) let content = listItemView.text.trimming(.whitespaceAndNewlines)

  21. Mutability and Foundation Value Types let var

  22. None
  23. [swift-evolution] [Manifesto] Completing Generics Douglas Gregor dgregor at apple.com Wed

    Mar 2 19:22:57 CST 2016 • Previous message: [swift-evolution] Proposal: conversion protocol naming conventions • Next message: [swift-evolution] [Manifesto] Completing Generics • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] beginarticle Hi all, Introduction The “Complete Generics” goal for Swift 3 has been fairly ill-defined thus fair, with just this short blurb in the list of goals: Complete generics: Generics are used pervasively in a number of Swift libraries, especially the standard library. However, there are a number of generics features the standard library requires to fully realize its vision, including recursive protocol constraints, the ability to make a constrained extension conform to a new protocol (i.e., an array of Equatable elements is Equatable), and so on. Swift 3.0 should provide those generics features needed by the standard library, because they affect the standard library's ABI. This message expands upon the notion of “completing generics”. It is not a plan for Swift 3, nor an official core team communication, but it collects the results of numerous discussions among the core team and Swift developers, both of the compiler and the standard library. I hope to achieve several things: Communicate a vision for Swift generics, building on the original generics design document <https://github.com/apple/ swift/blob/master/docs/Generics.rst>, so we have something concrete and comprehensive to discuss. Establish some terminology that the Swift developers have been using for these features, so our discussions can be more productive (“oh, you’re proposing what we refer to as ‘conditional conformances’; go look over at this thread”). Engage more of the community in discussions of specific generics features, so we can coalesce around designs for public review. And maybe even get some of them implemented. A message like this can easily turn into a centithread <http://www.urbandictionary.com/define.php?term=centithread>. To separate concerns in our discussion, I ask that replies to this specific thread be limited to discussions of the vision as a whole: how the pieces fit together, what pieces are missing, whether this is the right long-term vision for Swift, and so on. For discussions of specific language features, e.g., to work out the syntax and semantics of conditional conformances or discuss the implementation in compiler or use in the standard library, please start a new thread based on the feature names I’m using. This message covers a lot of ground; I’ve attempted a rough categorization of the various features, and kept the descriptions brief to limit the overall length. Most of these aren’t my ideas, and any syntax I’m providing is simply a way to express these ideas in code and is subject to change. Not all of these features will happen, either soon or ever, but they are intended to be a fairly complete whole that should mesh together. I’ve put a * next to features that I think are important in the nearer term vs. being interesting “some day”. Mostly, the *’s reflect features that will have a significant impact on the Swift standard library’s design and implementation. Enough with the disclaimers; it’s time to talk features. Removing unnecessary restrictions There are a number of restrictions to the use of generics that fall out of the implementation in the Swift compiler. Removal of these restrictions is a matter of implementation only; one need not introduce new syntax or semantics to realize them. I’m listing them for two reasons: first, it’s an acknowledgment that these features are intended to exist in the model we have today, and, second, we’d love help with the implementation of these features. *Recursive protocol constraints Currently, an associated type cannot be required to conform to its enclosing protocol (or any protocol that inherits that protocol). For example, in the standard library SubSequence type of a Sequence should itself be a Sequence: protocol Sequence { associatedtype Iterator : IteratorProtocol Generic constants let constants could be allowed to have generic parameters, such that they produce differently-typed values depending on how they are used. For example, this is particularly useful for named literal values, e.g., let π<T : FloatLiteralConvertible>: T = 3.141592653589793238462643383279502884197169399 The Clang importer could make particularly good use of this when importing macros. Parameterized extensions Extensions themselves could be parameterized, which would allow some structural pattern matching on types. For example, this would permit one to extend an array of optional values, e.g., extension<T> Array where Element == T? { var someValues: [T] { var result = [T]() for opt in self { if let value = opt { result.append(value) } } return result } } We can generalize this to a protocol extensions: extension<T> Sequence where Element == T? { var someValues: [T] { var result = [T]() for opt in self { if let value = opt { result.append(value) } } return result } } Note that when one is extending nominal types, we could simplify the syntax somewhat to make the same-type constraint implicit in the syntax: extension<T> Array<T?> { var someValues: [T] { var result = [T]() for opt in self { if let value = opt { result.append(value) } } return result } } When we’re working with concrete types, we can use that syntax to improve the extension of concrete versions of generic types (per “Concrete same-type requirements”, above), e.g., extension Array<String> { func makeSentence() -> String { // uppercase first string, concatenate with spaces, add a period, whatever } } Minor extensions There are a number of minor extensions we can make to the generics system that don’t fundamentally change what one can express in Swift, but which can improve its expressivity. *Arbitrary requirements in protocols
  24. Generic type aliases typealias BirdGuide = Dictionary<String, Bird> let birdGuide

    = BirdGuide() typealias Guide<T> = Dictionary<String, T> let birdGuide = Guide<Bird>() let dinoGuide = Guide<Dinosaur>()
  25. typealias ComparableGuide<T where T: Comparable> = Dictionary<String, T> Associated types

    may not have a generic parameter list
  26. Recursive protocol constraints protocol Sequence { associatedtype Iterator: IteratorProtocol associatedtype

    SubSequence: Sequence where SubSequence.Iterator.Element == Iterator.Element }
  27. None
  28. Protocol “Garment” can only be used as a generic constraint

    because it has Self or associated type requirements protocol Garment { associatedtype Material func knit(material: Material) } struct Truffula {} struct Thneed: Garment { func knit(material: Truffula) {…} } let garment: Garment = Thneed()
  29. Cannot specialize non-generic type “Garment” protocol Garment { associatedtype Material

    func knit(material: Material) } struct Truffula {} struct Thneed: Garment { func knit(material: Truffula) {…} } let garment: Garment<Truffula> = Thneed()
  30. Type erasure struct AnyGarment<Material>: Garment { let _knit: (Material) ->

    Void init<G: Garment where G.Material == Material>(_ garment: G) { _knit = garment.knit } func knit(material: Material) { _knit(material) } } http://robnapier.net/erasure let garment: AnyGarment = AnyGarment(Thneed()) garment.knit(material: Truffula())
  31. None
  32. for loops! for (var i = 0; i < 10;

    i++) { print(i) } for i in (0..<10) { print(i) }
  33. Currying syntax func add(a: Int)(_ b: Int) -> Int {

    return a + b } let inc = add(1) inc(6) // 7
  34. var parameters func printSuccessor(var a: Int) { a += 1

    print(a) }
  35. tuple splats func foo(a : Int, b : Int) {}

    let x = (1, b: 2) foo(x)
  36. ++i --i i++ i--

  37. consistent stable portable

  38. portable

  39. None
  40. None
  41. None
  42. Swift Package Manager import PackageDescription let package = Package( name:

    "Dealer", dependencies: [ .Package(url: "https://github.com/apple/deckofplayingcards.git", majorVersion: 1) ] ) $ swift build Compile Swift Module 'PlayingCard' (3 sources) Compile Swift Module 'FisherYates' (2 sources) Compile Swift Module 'DeckOfPlayingCards' (1 sources) Compile Swift Module 'Dealer' (1 sources) Linking .build/debug/Dealer $ .build/debug/Dealer
  43. https://swiftpkgs.ng.bluemix.net

  44. Patience… #define

  45. Patience… of a saint

  46. do { try Swift3 } • https://swift.org/blog/swift-3-0-release-process/ • First developer

    preview released today! • Or master snapshots • Get at swift.org
  47. @dcutting