The Week Of Monday 25 January 2016 Archives by date

• Messages sorted by: [ thread ] [ subject ] [ author ]
• More info on this list...

Starting: Mon Jan 25 00:12:02 CST 2016
Ending: Sun Jan 31 23:29:44 CST 2016
Messages: 968

• [swift-evolution] SE-0023 API Design Guidelines: Mutating vs Functional   T.J. Usiyan
• [swift-evolution] [Review] SE-0023 API Design Guidelines   Dave Abrahams
• [swift-evolution] [Review] SE-0023 API Design Guidelines   Chris Lattner
• [swift-evolution] [Review] SE-0023 API Design Guidelines   Charles Kissinger
• [swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching   Howard Lovatt
• [swift-evolution] named parameters - why hidden first?/proposal interest   Howard Lovatt
• [swift-evolution] access control   Ondrej Barina
• [swift-evolution] Proposal: Allow `[strong self]` capture in closures and remove the `self` requirement therein   Howard Lovatt
• [swift-evolution] For... else   Howard Lovatt
• [swift-evolution] SE-0023 API Design Guidelines: Mutating vs Functional   Haravikk
• [swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching   Quinn "The Eskimo!"
• [swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching   Taras Zakharko
• [swift-evolution] [Update] SE-0023 API Design Guidelines   Andrey Tarantsov
• [swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching   Charles Srstka
• [swift-evolution] [Review] SE-0023 API Design Guidelines   David Hart
• [swift-evolution] access control   Ilya Belenkiy
• [swift-evolution] access control   Ilya Belenkiy
• [swift-evolution] access control   Taras Zakharko
• [swift-evolution] access control   Ilya Belenkiy
• [swift-evolution] For... else   Matthew Johnson
• [swift-evolution] access control   Taras Zakharko
• [swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching   Taras Zakharko
• [swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift   Radosław Pietruszewski
• [swift-evolution] access control   Ilya Belenkiy
• [swift-evolution] access control   Taras Zakharko
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Radosław Pietruszewski
• [swift-evolution] [Review] SE-0023 API Design Guidelines   Radosław Pietruszewski
• [swift-evolution] access control   David Owens II
• [swift-evolution] [Review] SE-0023 API Design Guidelines   Radosław Pietruszewski
• [swift-evolution] [swift-evolution-announce] [Review] SE-0023 API Design Guidelines   David Owens II
• [swift-evolution] [Review] SE-0023 API Design Guidelines   Radosław Pietruszewski
• [swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching   David Farler
• [swift-evolution] access control   Ilya Belenkiy
• [swift-evolution] [Review] SE-0023 API Design Guidelines   Joe Groff
• [swift-evolution] [Update] SE-0023 API Design Guidelines   Douglas Gregor
• [swift-evolution] [Proposal] Property behaviors   Joe Groff
• [swift-evolution] access control   Félix Cloutier
• [swift-evolution] [Proposal] Property behaviors   Taras Zakharko
• [swift-evolution] [Proposal] Property behaviors   Taras Zakharko
• [swift-evolution] [Review] SE-0023 API Design Guidelines   David Owens II
• [swift-evolution] access control   Ilya Belenkiy
• [swift-evolution] Idea: Let Generic Parameters Have Labels & Default Values   davesweeris at mac.com
• [swift-evolution] access control   Goffredo Marocchi
• [swift-evolution] access control   Félix Cloutier
• [swift-evolution] [Proposal] Property behaviors   davesweeris at mac.com
• [swift-evolution] SE-0023 API Design Guidelines: Mutating vs Functional   Erica Sadun
• [swift-evolution] Idea: Let Generic Parameters Have Labels & Default Values   T.J. Usiyan
• [swift-evolution] access control   Thorsten Seitz
• [swift-evolution] access control   Thorsten Seitz
• [swift-evolution] access control   Ilya Belenkiy
• [swift-evolution] [Proposal] Property behaviors   Thorsten Seitz
• [swift-evolution] Partially Constrained Protocols [Was: [Proposal] Separate protocols and interfaces]   Maximilian Hünenberger
• [swift-evolution] access control   Ilya Belenkiy
• [swift-evolution] access control   Ilya Belenkiy
• [swift-evolution] Idea: Let Generic Parameters Have Labels & Default Values   Jordan Rose
• [swift-evolution] Draft Proposal: Declare variables in 'case' labels with multiple patterns   Jordan Rose
• [swift-evolution] access control   Matthew Johnson
• [swift-evolution] access control   Haravikk
• [swift-evolution] Partially Constrained Protocols [Was: [Proposal] Separate protocols and interfaces]   David Waite
• [swift-evolution] Idea: Let Generic Parameters Have Labels & Default Values   Maximilian Hünenberger
• [swift-evolution] Partially Constrained Protocols [Was: [Proposal] Separate protocols and interfaces]   David Waite
• [swift-evolution] access control   Taras Zakharko
• [swift-evolution] access control   Dave Abrahams
• [swift-evolution] access control   Jordan Rose
• [swift-evolution] named parameters   Jordan Rose
• [swift-evolution] access control   Matthew Johnson
• [swift-evolution] Draft Proposal: Declare variables in 'case' labels with multiple patterns   Andrew Bennett
• [swift-evolution] access control   Matthew Johnson
• [swift-evolution] Proposal: Replace ?? by an (optional) argument to ?   Amir Michail
• [swift-evolution] Pre-imported modules (sort of PCH)   Vanderlei Martinelli
• [swift-evolution] Proposal: Replace ?? by an (optional) argument to ?   Erica Sadun
• [swift-evolution] Proposal: Replace ?? by an (optional) argument to ?   Amir Michail
• [swift-evolution] Proposal: Replace ?? by an (optional) argument to ?   Craig Cruden
• [swift-evolution] access control   Andrew Bennett
• [swift-evolution] [Proposal] Property behaviors   Jordan Rose
• [swift-evolution] [Proposal] Partial initializers   Matthew Johnson
• [swift-evolution] Proposal: Replace ?? by an (optional) argument to ?   Howard Lovatt
• [swift-evolution] access control   Matthew Johnson
• [swift-evolution] Proposal: Replace ?? by an (optional) argument to ?   Rob Mayoff
• [swift-evolution] [Proposal] Property behaviors   Joe Groff
• [swift-evolution] Proposal: Replace ?? by an (optional) argument to ?   Austin Zheng
• [swift-evolution] Proposal: Replace ?? by an (optional) argument to ?   Andrew Bennett
• [swift-evolution] Proposal: Replace ?? by an (optional) argument to ?   Nate Birkholz
• [swift-evolution] access control   Andrew Bennett
• [swift-evolution] Proposal: Replace ?? by an (optional) argument to ?   Trent Nadeau
• [swift-evolution] For... else   Andrew Bennett
• [swift-evolution] [Proposal] Property behaviors   Jordan Rose
• [swift-evolution] access control   Rob Mayoff
• [swift-evolution] access control   Nate Birkholz
• [swift-evolution] access control   Rob Mayoff
• [swift-evolution] Proposal: Replace ?? by an (optional) argument to ?   Howard Lovatt
• [swift-evolution] [proposal] Either in the Swift Standard Library   Kevin Ballard
• [swift-evolution] [Review] SE-0023 API Design Guidelines   Thorsten Seitz
• [swift-evolution] [proposal] Either in the Swift Standard Library   Craig Cruden
• [swift-evolution] [proposal] Either in the Swift Standard Library   Developer
• [swift-evolution] [proposal] Either in the Swift Standard Library   Rob Mayoff
• [swift-evolution] [proposal] Either in the Swift Standard Library   Kevin Ballard
• [swift-evolution] [proposal] Either in the Swift Standard Library   Chris Lattner
• [swift-evolution] [proposal] Either in the Swift Standard Library   Developer
• [swift-evolution] [proposal] Either in the Swift Standard Library   Developer
• [swift-evolution] [proposal] Either in the Swift Standard Library   Dmitri Gribenko
• [swift-evolution] [Proposal] Property behaviors   Chris Lattner
• [swift-evolution] [proposal] Either in the Swift Standard Library   Kevin Ballard
• [swift-evolution] [proposal] Either in the Swift Standard Library   Developer
• [swift-evolution] [proposal] Either in the Swift Standard Library   Developer
• [swift-evolution] [proposal] Either in the Swift Standard Library   Craig Cruden
• [swift-evolution] [proposal] Either in the Swift Standard Library   Andrew Bennett
• [swift-evolution] [proposal] Either in the Swift Standard Library   Haravikk
• [swift-evolution] [proposal] Either in the Swift Standard Library   Craig Cruden
• [swift-evolution] Make generics covariant - was: Make generics covariant and add generics to protocols   Howard Lovatt
• [swift-evolution] Thoughts on making NSOperatingSystemVersion Comparable?   Robert S Mozayeni
• [swift-evolution] access control   Ilya Belenkiy
• [swift-evolution] access control   Ilya Belenkiy
• [swift-evolution] access control   Taras Zakharko
• [swift-evolution] [proposal] Either in the Swift Standard Library   plx
• [swift-evolution] access control   Matthew Johnson
• [swift-evolution] access control   Matthew Johnson
• [swift-evolution] access control   Matthew Johnson
• [swift-evolution] access control   Matthew Johnson
• [swift-evolution] access control   Ilya Belenkiy
• [swift-evolution] Delegate Method Conventions (was:[Review] SE-0023 API Design Guidelines)   plx
• [swift-evolution] [proposal] Either in the Swift Standard Library   Chris Lattner
• [swift-evolution] access control   Ilya Belenkiy
• [swift-evolution] Partially Constrained Protocols [Was: [Proposal] Separate protocols and interfaces]   Maximilian Hünenberger
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Charles Kissinger
• [swift-evolution] [Proposal] Property behaviors   Joe Groff
• [swift-evolution] deinit and failable initializers   Chris Eidhof
• [swift-evolution] [Review] SE-0023 API Design Guidelines   Paul Cantrell
• [swift-evolution] [proposal] Either in the Swift Standard Library   Developer
• [swift-evolution] [proposal] Either in the Swift Standard Library   Developer
• [swift-evolution] Partially Constrained Protocols [Was: [Proposal] Separate protocols and interfaces]   Maximilian Hünenberger
• [swift-evolution] [proposal] Either in the Swift Standard Library   T.J. Usiyan
• [swift-evolution] deinit and failable initializers   Douglas Gregor
• [swift-evolution] [proposal] Either in the Swift Standard Library   Greg Titus
• [swift-evolution] For... else   Félix Cloutier
• [swift-evolution] [proposal] Either in the Swift Standard Library   Developer
• [swift-evolution] deinit and failable initializers   Félix Cloutier
• [swift-evolution] [proposal] Either in the Swift Standard Library   Developer
• [swift-evolution] deinit and failable initializers   Joe Groff
• [swift-evolution] [proposal] Either in the Swift Standard Library   T.J. Usiyan
• [swift-evolution] Partially Constrained Protocols [Was: [Proposal] Separate protocols and interfaces]   David Waite
• [swift-evolution] [proposal] Either in the Swift Standard Library   T.J. Usiyan
• [swift-evolution] [Review] SE-0023 API Design Guidelines   Dave Abrahams
• [swift-evolution] Partially Constrained Protocols [Was: [Proposal] Separate protocols and interfaces]   David Waite
• [swift-evolution] [Review] SE-0023 API Design Guidelines   Dave Abrahams
• [swift-evolution] [Review] SE-0023 API Design Guidelines   Dave Abrahams
• [swift-evolution] [proposal] Either in the Swift Standard Library   plx
• [swift-evolution] [Review] SE-0023 API Design Guidelines   Dave Abrahams
• [swift-evolution] [proposal] Either in the Swift Standard Library   David Waite
• [swift-evolution] [Review] SE-0023 API Design Guidelines   Dave Abrahams
• [swift-evolution] deinit and failable initializers   Félix Cloutier
• [swift-evolution] [Proposal] Property behaviors   Curt Clifton
• [swift-evolution] [Proposal] Property behaviors   Jacob Bandes-Storch
• [swift-evolution] [Review] SE-0023 API Design Guidelines   Dave Abrahams
• [swift-evolution] [Review] SE-0023 API Design Guidelines   Dave Abrahams
• [swift-evolution] [proposal] Either in the Swift Standard Library   Chris Lattner
• [swift-evolution] [Review] SE-0023 API Design Guidelines   Dave Abrahams
• [swift-evolution] deinit and failable initializers   Chris Eidhof
• [swift-evolution] [proposal] Either in the Swift Standard Library   Kevin Ballard
• [swift-evolution] [Proposal] Eliminating Swift's Screaming Snake Case Identifiers   Erica Sadun
• [swift-evolution] [proposal] Either in the Swift Standard Library   Developer
• [swift-evolution] [proposal] Either in the Swift Standard Library   Kevin Ballard
• [swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift   Dave Abrahams
• [swift-evolution] [proposal] Either in the Swift Standard Library   Developer
• [swift-evolution] [proposal] Either in the Swift Standard Library   Kevin Ballard
• [swift-evolution] [Accepted] SE-0022 Referencing the Objective-C selector of a method   Joe Groff
• [swift-evolution] [proposal] Either in the Swift Standard Library   Developer
• [swift-evolution] For... else   Andrew Bennett
• [swift-evolution] [Proposal] Eliminating Swift's Screaming Snake Case Identifiers   Adriano Ferreira
• [swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift   Jacob Bandes-Storch
• [swift-evolution] Thoughts on making NSOperatingSystemVersion Comparable?   Jordan Rose
• [swift-evolution] Thoughts on making NSOperatingSystemVersion Comparable?   Robert S Mozayeni
• [swift-evolution] Thoughts on making NSOperatingSystemVersion Comparable?   Jordan Rose
• [swift-evolution] Thoughts on making NSOperatingSystemVersion Comparable?   Jordan Rose
• [swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching   Tian Zhang
• [swift-evolution] [Draft proposal] Faster/lower-level external String initialization   Zach Waldowski
• [swift-evolution] [Proposal] Eliminating Swift's Screaming Snake Case Identifiers   Joe Groff
• [swift-evolution] [Proposal] Property behaviors   Zach Waldowski
• [swift-evolution] Pitch: (Almost) std libs   Tino Heth
• [swift-evolution] Pitch: (Almost) std libs   Trent Nadeau
• [swift-evolution] [Proposal] Eliminating Swift's Screaming Snake Case Identifiers   Trent Nadeau
• [swift-evolution] Pitch: (Almost) std libs   Howard Lovatt
• [swift-evolution] Pitch: (Almost) std libs   Matthew Johnson
• [swift-evolution] [proposal] Either in the Swift Standard Library   Chris Lattner
• [swift-evolution] [proposal] Either in the Swift Standard Library   Matthew Johnson
• [swift-evolution] [Proposal] Eliminating Swift's Screaming Snake Case Identifiers   Chris Lattner
• [swift-evolution] [Review] SE-0023 API Design Guidelines   Trent Nadeau
• [swift-evolution] Delegate Method Conventions   Dave Abrahams
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Dave Abrahams
• [swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching   Dave Abrahams
• [swift-evolution] Pitch: (Almost) std libs   David Turnbull
• [swift-evolution] [Proposal] Eliminating Swift's Screaming Snake Case Identifiers   Erica Sadun
• [swift-evolution] [Review] SE-0023 API Design Guidelines   Dave Abrahams
• [swift-evolution] deinit and failable initializers   Joseph Lord
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Dany St-Amant
• [swift-evolution] [Review] SE-0023 API Design Guidelines   Trent Nadeau
• [swift-evolution] [Proposal] Eliminating Swift's Screaming Snake Case Identifiers   Joseph Lord
• [swift-evolution] Pitch: (Almost) std libs   Trent Nadeau
• [swift-evolution] Pitch: (Almost) std libs   David Turnbull
• [swift-evolution] For... else   Félix Cloutier
• [swift-evolution] Pitch: (Almost) std libs   Craig Cruden
• [swift-evolution] [Proposal] Eliminating Swift's Screaming Snake Case Identifiers   davesweeris at mac.com
• [swift-evolution] Thoughts on making NSOperatingSystemVersion Comparable?   Jacob Bandes-Storch
• [swift-evolution] [proposal] Either in the Swift Standard Library   Nate Birkholz
• [swift-evolution] [Proposal] Eliminating Swift's Screaming Snake Case Identifiers   Brian Gesiak
• [swift-evolution] Pitch: (Almost) std libs   Jordan Rose
• [swift-evolution] Pitch: (Almost) std libs   Jordan Rose
• [swift-evolution] Pitch: (Almost) std libs   Trent Nadeau
• [swift-evolution] [proposal] Either in the Swift Standard Library   Developer
• [swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching   J. Cheyo Jimenez
• [swift-evolution] #if Support for Module Presence   Colin Cornaby
• [swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching   Nate Birkholz
• [swift-evolution] [proposal] Either in the Swift Standard Library   Developer
• [swift-evolution] [Proposal] Eliminating Swift's Screaming Snake Case Identifiers   Douglas Gregor
• [swift-evolution] [proposal] Either in the Swift Standard Library   Craig Cruden
• [swift-evolution] [proposal] Either in the Swift Standard Library   swift at lng.la
• [swift-evolution] [proposal] Either in the Swift Standard Library   Developer
• [swift-evolution] [proposal] Either in the Swift Standard Library   swift at lng.la
• [swift-evolution] [Review] SE-0023 API Design Guidelines   Thorsten Seitz
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   Chris Lattner
• [swift-evolution] [proposal] Either in the Swift Standard Library   Craig Cruden
• [swift-evolution] [proposal] Either in the Swift Standard Library   Chris Lattner
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   T.J. Usiyan
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   Jacob Bandes-Storch
• [swift-evolution] Pitch: (Almost) std libs   Félix Cloutier
• [swift-evolution] [proposal] Either in the Swift Standard Library   Dave Abrahams
• [swift-evolution] [Proposal] Eliminating Swift's Screaming Snake Case Identifiers   Chris Lattner
• [swift-evolution] [proposal] Either in the Swift Standard Library   Developer
• [swift-evolution] [proposal] Either in the Swift Standard Library   Dave Abrahams
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Dave Abrahams
• [swift-evolution] [proposal] Either in the Swift Standard Library   Dave Abrahams
• [swift-evolution] Idea: Let Generic Parameters Have Labels & Default Values   davesweeris at mac.com
• [swift-evolution] Pitch: (Almost) std libs   David Turnbull
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Guillaume Lessard
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   James Campbell
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   davesweeris at mac.com
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   Jens Persson
• [swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift   Douglas Gregor
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   Charles Srstka
• [swift-evolution] [proposal] default func ==(_:_:)   Jan E. Schotsman
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Dave Abrahams
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Dave Abrahams
• [swift-evolution] [proposal] default func ==(_:_:)   davesweeris at mac.com
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   davesweeris at mac.com
• [swift-evolution] deinit and failable initializers   Kostiantyn Koval
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   Haravikk
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   David Waite
• [swift-evolution] [proposal] default func ==(_:_:)   Haravikk
• [swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift   Radosław Pietruszewski
• [swift-evolution] [Review] SE-0023 API Design Guidelines   Radosław Pietruszewski
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   Nisse Bergman
• [swift-evolution] [Review] SE-0023 API Design Guidelines   Radosław Pietruszewski
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   Howard Lovatt
• [swift-evolution] access control   Ilya Belenkiy
• [swift-evolution] deinit and failable initializers   Jean-Daniel Dupas
• [swift-evolution] access control   Thorsten Seitz
• [swift-evolution] Allowing `guard let self = self else { … }` for weakly captured self in a closure.   Hoon H.
• [swift-evolution] access control   Matthew Johnson
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   Paul Cantrell
• [swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift   Matthew Johnson
• [swift-evolution] Proposal: Make $0 always refer to a closure’s first argument   Paul Cantrell
• [swift-evolution] access control   Thorsten Seitz
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Guillaume Lessard
• [swift-evolution] access control   David Owens II
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   Greg Titus
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   David Owens II
• [swift-evolution] deinit and failable initializers   Charles Srstka
• [swift-evolution] access control   Matthew Johnson
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   Matthew Johnson
• [swift-evolution] Pitch: (Almost) std libs   Jordan Rose
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   plx
• [swift-evolution] [Review] SE-0023 API Design Guidelines   David Owens II
• [swift-evolution] deinit and failable initializers   davesweeris at mac.com
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   davesweeris at mac.com
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   Jordan Rose
• [swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift   Dave Abrahams
• [swift-evolution] [Review] SE-0023 API Design Guidelines   Dave Abrahams
• [swift-evolution] Proposal: Make $0 always refer to a closure’s first argument   Chris Lattner
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   Chris Lattner
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   Chris Lattner
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   Chris Lattner
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   Chris Lattner
• [swift-evolution] deinit and failable initializers   Jean-Daniel Dupas
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   davesweeris at mac.com
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   Chris Lattner
• [swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift   Matthew Johnson
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   swift at lng.la
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   Chris Lattner
• [swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift   Ben Rimmington
• [swift-evolution] [Review] SE-0023 API Design Guidelines (when to use properties)   Dave Abrahams
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   swift at lng.la
• [swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift   Matthew Johnson
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   Chris Lattner
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   James Campbell
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   David Waite
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   Jarod Long
• [swift-evolution] XCTest   James Campbell
• [swift-evolution] deinit and failable initializers   davesweeris at mac.com
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   Chris Lattner
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   Chris Lattner
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   Radek Pietruszewski
• [swift-evolution] [Review] SE-0023 API Design Guidelines   Dave Abrahams
• [swift-evolution] XCTest   Brian Gesiak
• [swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift   Ben Rimmington
• [swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift   Matthew Johnson
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   Christopher Whidden
• [swift-evolution] Proposal: Make $0 always refer to a closure’s first argument   davesweeris at mac.com
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   swift at lng.la
• [swift-evolution] [Review] SE-0023 API Design Guidelines (when to use properties)   David Waite
• [swift-evolution] [Review] SE-0023 API Design Guidelines (when to use properties)   Howard Lovatt
• [swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift   Ben Rimmington
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   Zach Waldowski
• [swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift   Tony Parker
• [swift-evolution] [Review] SE-0023 API Design Guidelines (when to use properties)   David Waite
• [swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift   Douglas Gregor
• [swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift   Rob Mayoff
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Charles Kissinger
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Radosław Pietruszewski
• [swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift   Haravikk
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   David Owens II
• [swift-evolution] Proposal: Make $0 always refer to a closure’s first argument   Paul Cantrell
• [swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift   Douglas Gregor
• [swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift   Radosław Pietruszewski
• [swift-evolution] #if Support for Module Presence   Greg Parker
• [swift-evolution] [Proposal] Eliminating Swift's Screaming Snake Case Identifiers   Erica Sadun
• [swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift   Douglas Gregor
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Charles Kissinger
• [swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift   Douglas Gregor
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Jordan Rose
• [swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift   Douglas Gregor
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Jordan Rose
• [swift-evolution] Seven Swift traps explained by David Ungar from IBM Research   Amir Michail
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   Andrew Bennett
• [swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift   Matthew Johnson
• [swift-evolution] [Review] SE-0023 API Design Guidelines (when to use properties)   Dave Abrahams
• [swift-evolution] [Review] SE-0023 API Design Guidelines (when to use properties)   Dave Abrahams
• [swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift   Douglas Gregor
• [swift-evolution] [Proposal] Partial initializers   Jordan Rose
• [swift-evolution] Seven Swift traps explained by David Ungar from IBM Research   Joe Groff
• [swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift   Dave Abrahams
• [swift-evolution] [Review] SE-0023 API Design Guidelines (when to use properties)   David Waite
• [swift-evolution] Renaming "Build Configuration"   Jordan Rose
• [swift-evolution] [Review] SE-0023 API Design Guidelines   Charles Kissinger
• [swift-evolution] Modernize Switch/Case Statements?   Joseph Essin
• [swift-evolution] Modernize Switch/Case Statements?   Ilya Belenkiy
• [swift-evolution] Modernize Switch/Case Statements?   Craig Cruden
• [swift-evolution] [proposal] Either in the Swift Standard Library   Kevin Ballard
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Justin Kolb
• [swift-evolution] undefined   Patrick Pijnappel
• [swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching   Jordan Rose
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Howard Lovatt
• [swift-evolution] Modernize Switch/Case Statements?   Howard Lovatt
• [swift-evolution] [Proposal] Eliminating Swift's Screaming Snake Case Identifiers   Dany St-Amant
• [swift-evolution] [Review] SE-0023 API Design Guidelines (when to use properties)   Howard Lovatt
• [swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching   J. Cheyo Jimenez
• [swift-evolution] [Review] SE-0023 API Design Guidelines (when to use properties)   Howard Lovatt
• [swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching   Howard Lovatt
• [swift-evolution] Brainstorming: Optional sugar inferred map   Craig Cruden
• [swift-evolution] Brainstorming: Optional sugar inferred map   Paul Ossenbruggen
• [swift-evolution] Brainstorming: Optional sugar inferred map   Craig Cruden
• [swift-evolution] [Review] SE-0023 API Design Guidelines (when to use properties)   David Waite
• [swift-evolution] Brainstorming: Optional sugar inferred map   Thorsten Seitz
• [swift-evolution] [Proposal] Eliminating Swift's Screaming Snake Case Identifiers   Curt Clifton
• [swift-evolution] Brainstorming: Optional sugar inferred map   Paul Ossenbruggen
• [swift-evolution] Modernize Switch/Case Statements?   Brent Royal-Gordon
• [swift-evolution] Brainstorming: Optional sugar inferred map   Craig Cruden
• [swift-evolution] [proposal] Either in the Swift Standard Library   Thorsten Seitz
• [swift-evolution] Brainstorming: Optional sugar inferred map   Paul Ossenbruggen
• [swift-evolution] Brainstorming: Optional sugar inferred map   Howard Lovatt
• [swift-evolution] [Review] SE-0023 API Design Guidelines (when to use properties)   Charles Kissinger
• [swift-evolution] Modernize Switch/Case Statements?   Howard Lovatt
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   Brent Royal-Gordon
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Dave Abrahams
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Dave Abrahams
• [swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift   Dave Abrahams
• [swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift   Dave Abrahams
• [swift-evolution] [Review] SE-0023 API Design Guidelines (when to use properties)   Dave Abrahams
• [swift-evolution] [Review] SE-0023 API Design Guidelines (when to use properties)   Dave Abrahams
• [swift-evolution] [Review] SE-0023 API Design Guidelines (when to use properties)   Dave Abrahams
• [swift-evolution] Brainstorming: Optional sugar inferred map   Jacob Bandes-Storch
• [swift-evolution] [Review] SE-0023 API Design Guidelines (when to use properties)   Howard Lovatt
• [swift-evolution] Isolated and failable green threads?   Niklas Saers
• [swift-evolution] Brainstorming: Optional sugar inferred map   Robert S Mozayeni
• [swift-evolution] Isolated and failable green threads?   Brent Royal-Gordon
• [swift-evolution] Isolated and failable green threads?   Austin Zheng
• [swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching   Brent Royal-Gordon
• [swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift   David Hart
• [swift-evolution] [Proposal] Partial initializers   James Campbell
• [swift-evolution] Apply for closure   James Campbell
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Radosław Pietruszewski
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   Jens Persson
• [swift-evolution] access control   Brent Royal-Gordon
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   Taras Zakharko
• [swift-evolution] undefined   Haravikk
• [swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift   Haravikk
• [swift-evolution] undefined   James Campbell
• [swift-evolution] access control   Ilya Belenkiy
• [swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching   Tino Heth
• [swift-evolution] Apply for closure   Tino Heth
• [swift-evolution] [proposal] Either in the Swift Standard Library   Matthew Johnson
• [swift-evolution] [Proposal] Eliminating Swift's Screaming Snake Case Identifiers   Jean-Daniel Dupas
• [swift-evolution] [Review] SE-0023 API Design Guidelines (when to use properties)   Michael Wells
• [swift-evolution] [Proposal] Eliminating Swift's Screaming Snake Case Identifiers   Erica Sadun
• [swift-evolution] [Proposal] Eliminating Swift's Screaming Snake Case Identifiers   Erica Sadun
• [swift-evolution] access control   Douglas Gregor
• [swift-evolution] [Review] SE-0023 API Design Guidelines (when to use properties)   Dave Abrahams
• [swift-evolution] access control   Ilya Belenkiy
• [swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift   Dave Abrahams
• [swift-evolution] [proposal] Either in the Swift Standard Library   Craig Cruden
• [swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift   Dave Abrahams
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Dave Abrahams
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   Paul Cantrell
• [swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching   Joe Groff
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Erica Sadun
• [swift-evolution] Isolated and failable green threads?   Chris Lattner
• [swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching   Erica Sadun
• [swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching   Jordan Rose
• [swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching   Jacob Bandes-Storch
• [swift-evolution] [proposal] Either in the Swift Standard Library   Chris Lattner
• [swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching   Joe Groff
• [swift-evolution] [proposal] Either in the Swift Standard Library   Chris Lattner
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   Chris Lattner
• [swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching   Nate Birkholz
• [swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching   Erica Sadun
• [swift-evolution] [proposal] Either in the Swift Standard Library   Kevin Ballard
• [swift-evolution] Renaming "Build Configuration"   Ben Langmuir
• [swift-evolution] Apply for closure   James Campbell
• [swift-evolution] [proposal] Either in the Swift Standard Library   Kevin Ballard
• [swift-evolution] Renaming "Build Configuration"   Jacob Bandes-Storch
• [swift-evolution] Renaming "Build Configuration"   Jordan Rose
• [swift-evolution] [proposal] Either in the Swift Standard Library   Joe Groff
• [swift-evolution] undefined   Dave Abrahams
• [swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching   Joe Groff
• [swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching   Dave Abrahams
• [swift-evolution] Renaming "Build Configuration"   Jacob Bandes-Storch
• [swift-evolution] Renaming "Build Configuration"   Kevin Ballard
• [swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching   Kevin Ballard
• [swift-evolution] Pitch: only allow capture of inout parameters in @noescape closures   Joe Groff
• [swift-evolution] [swift-evolution-announce] [Review] SE-0023 API Design Guidelines   Ricardo Parada
• [swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift   Jordan Rose
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   Tino Heth
• [swift-evolution] [proposal] Either in the Swift Standard Library   Matthew Johnson
• [swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift   Jacob Bandes-Storch
• [swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift   Radosław Pietruszewski
• [swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching   swift at lng.la
• [swift-evolution] Pitch: only allow capture of inout parameters in @noescape closures   Kevin Ballard
• [swift-evolution] Pitch: only allow capture of inout parameters in @noescape closures   Jacob Bandes-Storch
• [swift-evolution] Pitch: only allow capture of inout parameters in @noescape closures   Jordan Rose
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Andrew Trick
• [swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching   Dave Abrahams
• [swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift   Dave Abrahams
• [swift-evolution] Pitch: only allow capture of inout parameters in @noescape closures   Dave Abrahams
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Joe Groff
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Matthew Johnson
• [swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching   David Farler
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Erica Sadun
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Jacob Bandes-Storch
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Joe Groff
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Joe Groff
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Jacob Bandes-Storch
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Joe Groff
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Félix Cloutier
• [swift-evolution] [Review] SE-0023 API Design Guidelines   Ricardo Parada
• [swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching   Douglas Gregor
• [swift-evolution] Allowing `guard let self = self else { … }` for weakly captured self in a closure.   Hoon H.
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Haravikk
• [swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching   J. Cheyo Jimenez
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   Taras Zakharko
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Félix Cloutier
• [swift-evolution] Allowing `guard let self = self else { … }` for weakly captured self in a closure.   Hoon H.
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Joe Groff
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Erica Sadun
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   Brent Royal-Gordon
• [swift-evolution] undefined   Patrick Pijnappel
• [swift-evolution] undefined   Dave Abrahams
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Dany St-Amant
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Trent Nadeau
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Justin Kolb
• [swift-evolution] [proposal] Either in the Swift Standard Library   Craig Cruden
• [swift-evolution] Static Subscript   davesweeris at mac.com
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Félix Cloutier
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Nate Birkholz
• [swift-evolution] Static Subscript   Félix Cloutier
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Nate Birkholz
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Justin Kolb
• [swift-evolution] Pitch: only allow capture of inout parameters in @noescape closures   Chris Lattner
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Chris Lattner
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Brent Royal-Gordon
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Chris Lattner
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Alex Migicovsky
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Justin Kolb
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Howard Lovatt
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Howard Lovatt
• [swift-evolution] Brainstorming: Optional sugar inferred map   Craig Cruden
• [swift-evolution] Brainstorming: Optional sugar inferred map   Jacob Bandes-Storch
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Félix Cloutier
• [swift-evolution] Brainstorming: Optional sugar inferred map   Craig Cruden
• [swift-evolution] Pitch: (Almost) std libs   David Turnbull
• [swift-evolution] Brainstorming: Optional sugar inferred map   Paul Ossenbruggen
• [swift-evolution] Brainstorming: Optional sugar inferred map   Craig Cruden
• [swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching   Chris Lattner
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Joe Groff
• [swift-evolution] Static Subscript   David Sweeris
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Joe Groff
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Justin Kolb
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Félix Cloutier
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Joe Groff
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Félix Cloutier
• [swift-evolution] SE-0003 Removing var from Function Parameters and Pattern Matching   Chris Lattner
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Chris Lattner
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Chris Lattner
• [swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching   Thorsten Seitz
• [swift-evolution] SE-0003 Removing var from Function Parameters and Pattern Matching   Nate Birkholz
• [swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching   Thorsten Seitz
• [swift-evolution] Modernize Switch/Case Statements?   Charles Constant
• [swift-evolution] SE-0003 Removing var from Function Parameters and Pattern Matching   Thorsten Seitz
• [swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching   Craig Cruden
• [swift-evolution] SE-0003 Removing var from Function Parameters and Pattern Matching   Paul Ossenbruggen
• [swift-evolution] Pitch: (Almost) std libs   Charles Kissinger
• [swift-evolution] SE-0003 Removing var from Function Parameters and Pattern Matching   Paul Cantrell
• [swift-evolution] Modernize Switch/Case Statements?   Thorsten Seitz
• [swift-evolution] Proposal: Pattern Matching Partial Function (#111)   Craig Cruden
• [swift-evolution] Proposal: Pattern Matching Partial Function (#111)   Charles Constant
• [swift-evolution] Proposal: Pattern Matching Partial Function (#111)   Paul Cantrell
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   David Sweeris
• [swift-evolution] SE-0003 Removing var from Function Parameters and Pattern Matching   Taras Zakharko
• [swift-evolution] Proposal: Pattern Matching Partial Function (#111)   Charles Constant
• [swift-evolution] [Review] SE-0023 API Design Guidelines   David Waite
• [swift-evolution] SR-104: Improve Crash-Safety when Importing Objective-C Code Without Nullability Attributes   Fabian Ehrentraud
• [swift-evolution] Proposal: Pattern Matching Partial Function (#111)   Charles Constant
• [swift-evolution] Guaranteed closure execution   Gwendal Roué
• [swift-evolution] Proposal: Pattern Matching Partial Function (#111)   Paul Ossenbruggen
• [swift-evolution] Isolated and failable green threads?   Fabian Balslev Saers
• [swift-evolution] Proposal: Pattern Matching Partial Function (#111)   Charles Constant
• [swift-evolution] SE-0003 Removing var from Function Parameters and Pattern Matching   Ondrej Barina
• [swift-evolution] Guaranteed closure execution   Jacob Bandes-Storch
• [swift-evolution] Pitch: (Almost) std libs   David Turnbull
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Tino Heth
• [swift-evolution] Proposal: Pattern Matching Partial Function (#111)   James Campbell
• [swift-evolution] Guaranteed closure execution   Gwendal Roué
• [swift-evolution] Proposal: Pattern Matching Partial Function (#111)   Craig Cruden
• [swift-evolution] Brainstorming: Optional sugar inferred map   Paul Ossenbruggen
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   davesweeris at mac.com
• [swift-evolution] Proposal: Replace ?? by an (optional) argument to ?   Thorsten Seitz
• [swift-evolution] Proposal: Pattern Matching Partial Function (#111)   Charles Constant
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Benedikt Terhechte
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Tino Heth
• [swift-evolution] Guaranteed closure execution   Brent Royal-Gordon
• [swift-evolution] SE-0003 Removing var from Function Parameters and Pattern Matching   Ilya Belenkiy
• [swift-evolution] access control   Carlos Rodríguez Domínguez
• [swift-evolution] Guaranteed closure execution   Thorsten Seitz
• [swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching   Dany St-Amant
• [swift-evolution] Guaranteed closure execution   Gwendal Roué
• [swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching   Haravikk
• [swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching   Craig Cruden
• [swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching   Charles Constant
• [swift-evolution] Proposal: Replace ?? by an (optional) argument to ?   Amir Michail
• [swift-evolution] Proposal: Replace ?? by an (optional) argument to ?   Craig Cruden
• [swift-evolution] Proposal: Replace ?? by an (optional) argument to ?   Amir Michail
• [swift-evolution] Proposal: Replace ?? by an (optional) argument to ?   Ross O'Brien
• [swift-evolution] Proposal: Replace ?? by an (optional) argument to ?   Nikolai Vazquez
• [swift-evolution] SE-0003 Removing var from Function Parameters and Pattern Matching   Matthew Johnson
• [swift-evolution] [swift-evolution-announce] [Review] SE-0023 API Design Guidelines   Patrick Gili
• [swift-evolution] Pitch: (Almost) std libs   Charles Kissinger
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Thorsten Seitz
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Erica Sadun
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Erica Sadun
• [swift-evolution] SE-0003 Removing var from Function Parameters and Pattern Matching   Vanderlei Martinelli
• [swift-evolution] [swift-evolution-announce] [Review] SE-0023 API Design Guidelines   Erica Sadun
• [swift-evolution] [Review] SE-0023 API Design Guidelines (when to use properties)   Charles Kissinger
• [swift-evolution] [swift-evolution-announce] [Review] SE-0023 API Design Guidelines   Patrick Gili
• [swift-evolution] [Review] SE-0023 API Design Guidelines   Erica Sadun
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Dave Abrahams
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Dave Abrahams
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Dave Abrahams
• [swift-evolution] [swift-evolution-announce] [Review] SE-0023 API Design Guidelines   Erica Sadun
• [swift-evolution] [swift-evolution-announce] [Review] SE-0023 API Design Guidelines   Dave Abrahams
• [swift-evolution] [proposal] Either in the Swift Standard Library   Dave Abrahams
• [swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching   Dave Abrahams
• [swift-evolution] Proposal: Replace ?? by an (optional) argument to ?   Amir Michail
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Erica Sadun
• [swift-evolution] Proposal: Replace ?? by an (optional) argument to ?   Erica Sadun
• [swift-evolution] access control   Jean-Daniel Dupas
• [swift-evolution] [proposal] Either in the Swift Standard Library   Erica Sadun
• [swift-evolution] Adding proposal to modernize debug identifiers (#123)   Erica Sadun
• [swift-evolution] Pitch: Import Objective-C Constants as Enums   Jeff Kelley
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Joe Groff
• [swift-evolution] access control   Ilya Belenkiy
• [swift-evolution] Brainstorming: Optional sugar inferred map   Jacob Bandes-Storch
• [swift-evolution] Isolated and failable green threads?   Chris Lattner
• [swift-evolution] Pitch: (Almost) std libs   Tino Heth
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Chris Lattner
• [swift-evolution] Guaranteed closure execution   Chris Lattner
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   Chris Lattner
• [swift-evolution] SE-0003 Removing var from Function Parameters and Pattern Matching   swift at lng.la
• [swift-evolution] Brainstorming: Optional sugar inferred map   Paul Ossenbruggen
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Félix Cloutier
• [swift-evolution] Guaranteed closure execution   Félix Cloutier
• [swift-evolution] Brainstorming: Optional sugar inferred map   Jacob Bandes-Storch
• [swift-evolution] [Review] SE-0023 API Design Guidelines   Adriano Ferreira
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Austin Zheng
• [swift-evolution] SR-104: Improve Crash-Safety when Importing Objective-C Code Without Nullability Attributes   Douglas Gregor
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Joe Groff
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Austin Zheng
• [swift-evolution] Pitch: Import Objective-C Constants as Enums   Douglas Gregor
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Alex Migicovsky
• [swift-evolution] SE-0003 Removing var from Function Parameters and Pattern Matching   Benedikt Terhechte
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Joe Groff
• [swift-evolution] Pitch: Import Objective-C Constants as Enums   Douglas Gregor
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Erica Sadun
• [swift-evolution] Pitch: Import Objective-C Constants as Enums   Douglas Gregor
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Jordan Rose
• [swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching   Jordan Rose
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Trent Nadeau
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Joe Groff
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   davesweeris at mac.com
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Trent Nadeau
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   davesweeris at mac.com
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Joe Groff
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Joe Groff
• [swift-evolution] Pitch: Import Objective-C Constants as Enums   Zach Waldowski
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Jordan Rose
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Trent Nadeau
• [swift-evolution] [Review] SE-0028 Modernizing Swift's Debugging Identifiers (__LINE__, etc)   Chris Lattner
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Adrian Kashivskyy
• [swift-evolution] [Proposal] Adjusting `inout` Declarations for Type Decoration   Erica Sadun
• [swift-evolution] [Proposal] Adjusting `inout` Declarations for Type Decoration   davesweeris at mac.com
• [swift-evolution] [Review] SE-0028 Modernizing Swift's Debugging Identifiers (__LINE__, etc)   Trent Nadeau
• [swift-evolution] SE-0003 Removing var from Function Parameters and Pattern Matching   Kevin Ballard
• [swift-evolution] [Proposal] Adjusting `inout` Declarations for Type Decoration   Trent Nadeau
• [swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching   Tyler Cloutier
• [swift-evolution] [Review] SE-0028 Modernizing Swift's Debugging Identifiers (__LINE__, etc)   Adrian Kashivskyy
• [swift-evolution] [Proposal] Adjusting `inout` Declarations for Type Decoration   Haravikk
• [swift-evolution] [Review] SE-0028 Modernizing Swift's Debugging Identifiers (__LINE__, etc)   davesweeris at mac.com
• [swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift   Jordan Rose
• [swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching   Dave Abrahams
• [swift-evolution] [swift-evolution-announce] [Review] SE-0028 Modernizing Swift's Debugging Identifiers (__LINE__, etc)   Kevin Ballard
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Dave Abrahams
• [swift-evolution] Syntax extensions for indicating mutation (was: [Review] SE-0023 API Design Guidelines)   Dave Abrahams
• [swift-evolution] [swift-evolution-announce] [Review] SE-0028 Modernizing Swift's Debugging Identifiers (__LINE__, etc)   Erica Sadun
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Erica Sadun
• [swift-evolution] [Proposal] Adjusting `inout` Declarations for Type Decoration   Matthew Johnson
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Félix Cloutier
• [swift-evolution] [swift-evolution-announce] [Review] SE-0028 Modernizing Swift's Debugging Identifiers (__LINE__, etc)   Matthew Johnson
• [swift-evolution] [Review] SE-0023 API Design Guidelines   David Waite
• [swift-evolution] [Review] SE-0028 Modernizing Swift's Debugging Identifiers (__LINE__, etc)   Nate Birkholz
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Dave Abrahams
• [swift-evolution] [swift-evolution-announce] [Review] SE-0028 Modernizing Swift's Debugging Identifiers (__LINE__, etc)   Kevin Ballard
• [swift-evolution] [swift-evolution-announce] [Review] SE-0028 Modernizing Swift's Debugging Identifiers (__LINE__, etc)   Matthew Johnson
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Dave Abrahams
• [swift-evolution] Syntax extensions for indicating mutation (was: [Review] SE-0023 API Design Guidelines)   Haravikk
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Dave Abrahams
• [swift-evolution] [Review] SE-0023 API Design Guidelines   Paul Cantrell
• [swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift   Tony Parker
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Joe Groff
• [swift-evolution] [Proposal] Adjusting `inout` Declarations for Type Decoration   Joseph Lord
• [swift-evolution] [swift-evolution-announce] [Review] SE-0028 Modernizing Swift's Debugging Identifiers (__LINE__, etc)   Paul Ossenbruggen
• [swift-evolution] [Review] SE-0023 API Design Guidelines   Matt Whiteside
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Trent Nadeau
• [swift-evolution] [swift-evolution-announce] [Review] SE-0028 Modernizing Swift's Debugging Identifiers (__LINE__, etc)   Erica Sadun
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Chris Lattner
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Chris Lattner
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Chris Lattner
• [swift-evolution] [Proposal] Adjusting `inout` Declarations for Type Decoration   Erica Sadun
• [swift-evolution] [Proposal] Adjusting `inout` Declarations for Type Decoration   Joe Groff
• [swift-evolution] [Proposal] Adjusting `inout` Declarations for Type Decoration   Chris Lattner
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Trent Nadeau
• [swift-evolution] [Proposal] Adjusting `inout` Declarations for Type Decoration   Trent Nadeau
• [swift-evolution] [Proposal] Adjusting `inout` Declarations for Type Decoration   Jacob Bandes-Storch
• [swift-evolution] Partially Constrained Protocols [Was: [Proposal] Separate protocols and interfaces]   Maximilian Hünenberger
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Chris Lattner
• [swift-evolution] [Proposal] Adjusting `inout` Declarations for Type Decoration   Charles Kissinger
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Erica Sadun
• [swift-evolution] Pitch: Import Objective-C Constants as Enums   Jeff Kelley
• [swift-evolution] [Review] SE-0023 API Design Guidelines   Brent Royal-Gordon
• [swift-evolution] [Proposal] Adjusting `inout` Declarations for Type Decoration   Erica Sadun
• [swift-evolution] [Review] SE-0023 API Design Guidelines   Adriano Ferreira
• [swift-evolution] Partially Constrained Protocols [Was: [Proposal] Separate protocols and interfaces]   Maximilian Hünenberger
• [swift-evolution] SE-0003 Removing var from Function Parameters and Pattern Matching   Rudolf Adamkovič
• [swift-evolution] [Proposal] Use inout at function call sites   Trent Nadeau
• [swift-evolution] Modernize Switch/Case Statements?   Rudolf Adamkovič
• [swift-evolution] [Proposal] Use inout at function call sites   Erica Sadun
• [swift-evolution] [Proposal] Use inout at function call sites   Dmitri Gribenko
• [swift-evolution] [Proposal] Use inout at function call sites   Matthew Johnson
• [swift-evolution] [Proposal] Use inout at function call sites   Benedikt Terhechte
• [swift-evolution] [swift-evolution-announce] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift   Brent Royal-Gordon
• [swift-evolution] [Proposal] Use inout at function call sites   swift at lng.la
• [swift-evolution] [Proposal] Use inout at function call sites   Nate Birkholz
• [swift-evolution] [Proposal] Use inout at function call sites   Zach Waldowski
• [swift-evolution] Brainstorming: Optional sugar inferred map   Craig Cruden
• [swift-evolution] [Proposal] Use inout at function call sites   Jordan Rose
• [swift-evolution] [swift-evolution-announce] [Review] SE-0028 Modernizing Swift's Debugging Identifiers (__LINE__, etc)   Adrian Prantl
• [swift-evolution] [Proposal] Use inout at function call sites   Joe Groff
• [swift-evolution] [Proposal] Adjusting `inout` Declarations for Type Decoration   Charles Kissinger
• [swift-evolution] [Proposal] Use inout at function call sites   Erica Sadun
• [swift-evolution] [Proposal] Adjusting `inout` Declarations for Type Decoration   Erica Sadun
• [swift-evolution] [Proposal] Adjusting `inout` Declarations for Type Decoration   Trent Nadeau
• [swift-evolution] [Proposal] Adjusting `inout` Declarations for Type Decoration   Allen Ding
• [swift-evolution] Protocols and var { get }   Frank Ecsedy
• [swift-evolution] Protocols and var { get }   Dmitri Gribenko
• [swift-evolution] [Proposal] Adjusting `inout` Declarations for Type Decoration   Charles Kissinger
• [swift-evolution] [Proposal] Adjusting `inout` Declarations for Type Decoration   Erica Sadun
• [swift-evolution] [Proposal] Adjusting `inout` Declarations for Type Decoration   Austin Zheng
• [swift-evolution] [Proposal] Use inout at function call sites   Allen Ding
• [swift-evolution] Pitch: (Almost) std libs   David Turnbull
• [swift-evolution] [Proposal] Use inout at function call sites   Trent Nadeau
• [swift-evolution] [Proposal] Adjusting `inout` Declarations for Type Decoration   Allen Ding
• [swift-evolution] [Review] SE-0023 API Design Guidelines (was: Syntax extensions for indicating mutation)   Dave Abrahams
• [swift-evolution] [Proposal] Use inout at function call sites   Jeremy Kates
• [swift-evolution] [Proposal] Use inout at function call sites   Kevin Ballard
• [swift-evolution] [Proposal] Use inout at function call sites   Trent Nadeau
• [swift-evolution] [Proposal] Use inout at function call sites   Austin Zheng
• [swift-evolution] [Proposal] Use inout at function call sites   Jordan Rose
• [swift-evolution] Proposal: Tail Call Optimization keyword/attribute   T.J. Usiyan
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Brent Royal-Gordon
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Alex Migicovsky
• [swift-evolution] [Proposal] Use inout at function call sites   Jordan Rose
• [swift-evolution] Protocols and var { get }   Brent Royal-Gordon
• [swift-evolution] [swift-evolution-announce] [Review] SE-0023 API Design Guidelines   Patrick Gili
• [swift-evolution] [Proposal] Use inout at function call sites   Jordan Rose
• [swift-evolution] [Proposal] Use inout at function call sites   Brent Royal-Gordon
• [swift-evolution] [Proposal] Use inout at function call sites   Kevin Ballard
• [swift-evolution] [Proposal] Use inout at function call sites   Jordan Rose
• [swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift   John Randolph
• [swift-evolution] [Proposal] Use inout at function call sites   Kevin Ballard
• [swift-evolution] [Proposal] Adjusting `inout` Declarations for Type Decoration   Jordan Rose
• [swift-evolution] [swift-evolution-announce] [Review] SE-0023 API Design Guidelines   Patrick Gili
• [swift-evolution] [Proposal] Use inout at function call sites   Brent Royal-Gordon
• [swift-evolution] [Proposal] Use inout at function call sites   T.J. Usiyan
• [swift-evolution] [Proposal] Use inout at function call sites   Charles Kissinger
• [swift-evolution] [Proposal] Use inout at function call sites   Jordan Rose
• [swift-evolution] [Proposal] Use inout at function call sites   Dany St-Amant
• [swift-evolution] [Proposal] Use inout at function call sites   Trent Nadeau
• [swift-evolution] [Proposal] Use inout at function call sites   Austin Zheng
• [swift-evolution] [Proposal] Use inout at function call sites   Trent Nadeau
• [swift-evolution] [Proposal] Use inout at function call sites   Chris Lattner
• [swift-evolution] Brainstorming: Optional sugar inferred map   David Sweeris
• [swift-evolution] [Proposal] Use inout at function call sites   Charles Kissinger
• [swift-evolution] [Proposal] Use inout at function call sites   Austin Zheng
• [swift-evolution] [Proposal] Use inout at function call sites   Charles Kissinger
• [swift-evolution] [Proposal] Use inout at function call sites   Austin Zheng
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Howard Lovatt
• [swift-evolution] [Proposal] Use inout at function call sites   Howard Lovatt
• [swift-evolution] [Proposal] Adjusting `inout` Declarations for Type Decoration   Howard Lovatt
• [swift-evolution] Protocols and var { get }   Howard Lovatt
• [swift-evolution] Protocols and var { get }   Frank Ecsedy
• [swift-evolution] Protocols and var { get }   davesweeris at mac.com
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   Nikita Leonov
• [swift-evolution] [Proposal] Use inout at function call sites   Ondrej Barina
• [swift-evolution] [Proposal] Use inout at function call sites   Andrew Trick
• [swift-evolution] [Proposal] Use inout at function call sites   Paul Ossenbruggen
• [swift-evolution] Modernize Switch/Case Statements?   Haravikk
• [swift-evolution] Brainstorming: Optional sugar inferred map   Craig Cruden
• [swift-evolution] [proposal] default func ==(_:_:)   Jan E. Schotsman
• [swift-evolution] [Proposal] Use inout at function call sites   Haravikk
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Goffredo Marocchi
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Haravikk
• [swift-evolution] [Proposal] Use inout at function call sites   Goffredo Marocchi
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Goffredo Marocchi
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Brent Royal-Gordon
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   Tino Heth
• [swift-evolution] SR-104: Improve Crash-Safety when Importing Objective-C Code Without Nullability Attributes   Fabian Ehrentraud
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Haravikk
• [swift-evolution] [proposal] Either in the Swift Standard Library   Craig Cruden
• [swift-evolution] [proposal] default func ==(_:_:)   davesweeris at mac.com
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   Tino Heth
• [swift-evolution] Proposal: Replace ?? by an (optional) argument to ?   Thorsten Seitz
• [swift-evolution] [proposal] Either in the Swift Standard Library   Tino Heth
• [swift-evolution] Modernize Switch/Case Statements?   Andrew Bennett
• [swift-evolution] Guaranteed closure execution   Rod Brown
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   Taras Zakharko
• [swift-evolution] Proposal: Allow @available(*, unavailble) to getter or setter.   Hoon H.
• [swift-evolution] Modernize Switch/Case Statements?   ‫אביאל גרוס‬‎
• [swift-evolution] Fwd: [Review] SE-0006 Apply API Guidelines to the Standard Library   Maximilian Hünenberger
• [swift-evolution] Modernize Switch/Case Statements?   Maximilian Hünenberger
• [swift-evolution] Modernize Switch/Case Statements?   Craig Cruden
• [swift-evolution] [Proposal] Use inout at function call sites   Tino Heth
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   plx
• [swift-evolution] Proposal: Compile-time parameters   Tino Heth
• [swift-evolution] [Proposal] Use inout at function call sites   Trent Nadeau
• [swift-evolution] [Proposal] Use inout at function call sites   Greg Titus
• [swift-evolution] Constant generic properties in mutable contexts   Maximilian Hünenberger
• [swift-evolution] [Proposal] Use inout at function call sites   Radosław Pietruszewski
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   plx
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Charles Kissinger
• [swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift   Radosław Pietruszewski
• [swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift   Trent Nadeau
• [swift-evolution] Constant generic properties in mutable contexts   Brent Royal-Gordon
• [swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift   Radosław Pietruszewski
• [swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching   Thorsten Seitz
• [swift-evolution] Proposal: Replace ?? by an (optional) argument to ?   Thorsten Seitz
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Dany St-Amant
• [swift-evolution] Brainstorming: Optional sugar inferred map   Paul Ossenbruggen
• [swift-evolution] Proposal: Replace ?? by an (optional) argument to ?   Amir Michail
• [swift-evolution] Proposal: Replace ?? by an (optional) argument to ?   Ilya Belenkiy
• [swift-evolution] [Proposal] Adjusting `inout` Declarations for Type Decoration   Charles Kissinger
• [swift-evolution] Delegate Method Conventions   plx
• [swift-evolution] Proposal: Replace ?? by an (optional) argument to ?   Greg Titus
• [swift-evolution] Reconsider ++ and -- operators removal and prevent other well-known operators from change   Vanderlei Martinelli
• [swift-evolution] Reconsider ++ and -- operators removal and prevent other well-known operators from change   Vanderlei Martinelli
• [swift-evolution] Constant generic properties in mutable contexts   Joe Groff
• [swift-evolution] Brainstorming: Optional sugar inferred map   Joe Groff
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   Haravikk
• [swift-evolution] Reconsider ++ and -- operators removal and prevent other well-known operators from change   Radosław Pietruszewski
• [swift-evolution] Reconsider ++ and -- operators removal and prevent other well-known operators from change   Will Stanton
• [swift-evolution] Proposal: Pattern Matching Partial Function (#111)   Radosław Pietruszewski
• [swift-evolution] Reconsider ++ and -- operators removal and prevent other well-known operators from change   Vanderlei Martinelli
• [swift-evolution] Proposal: Pattern Matching Partial Function (#111)   Craig Cruden
• [swift-evolution] Reconsider ++ and -- operators removal and prevent other well-known operators from change   Vanderlei Martinelli
• [swift-evolution] Constant generic properties in mutable contexts   Maximilian Hünenberger
• [swift-evolution] Reconsider ++ and -- operators removal and prevent other well-known operators from change   Austin Zheng
• [swift-evolution] Reconsider ++ and -- operators removal and prevent other well-known operators from change   Vanderlei Martinelli
• [swift-evolution] Reconsider ++ and -- operators removal and prevent other well-known operators from change   Vanderlei Martinelli
• [swift-evolution] Proposal: Allow @available(*, unavailble) to getter or setter.   Kevin Lundberg
• [swift-evolution] Reconsider ++ and -- operators removal and prevent other well-known operators from change   Austin Zheng
• [swift-evolution] Reconsider ++ and -- operators removal and prevent other well-known operators from change   Vanderlei Martinelli
• [swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift   Douglas Gregor
• [swift-evolution] Guaranteed closure execution   Félix Cloutier
• [swift-evolution] Reconsider ++ and -- operators removal and prevent other well-known operators from change   Taras Zakharko
• [swift-evolution] Reconsider ++ and -- operators removal and prevent other well-known operators from change   Vanderlei Martinelli
• [swift-evolution] Reconsider ++ and -- operators removal and prevent other well-known operators from change   Craig Cruden
• [swift-evolution] Reconsider ++ and -- operators removal and prevent other well-known operators from change   Taras Zakharko
• [swift-evolution] Guaranteed closure execution   Matthew Johnson
• [swift-evolution] [Review] SE-0023 API Design Guidelines   Dave Abrahams
• [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)   Dave Abrahams
• [swift-evolution] #import (project scope import) (former: "Pre-imported modules (sort of PCH)”)   Vanderlei Martinelli
• [swift-evolution] [Extending review] SE-0005, SE-0006, SE-0023 API Guidelines and impact   Douglas Gregor
• [swift-evolution] Guaranteed closure execution   Jacob Bandes-Storch
• [swift-evolution] Swift 4 evolution mailing list for not Swift 2.x/Swift 3 suitable proposals (async/await, for example)   Vanderlei Martinelli
• [swift-evolution] [Proposal] Adjusting `inout` Declarations for Type Decoration   Patrick Gili
• [swift-evolution] Swift 4 evolution mailing list for not Swift 2.x/Swift 3 suitable proposals (async/await, for example)   Radosław Pietruszewski
• [swift-evolution] Swift 4 evolution mailing list for not Swift 2.x/Swift 3 suitable proposals (async/await, for example)   Craig Cruden
• [swift-evolution] Swift 4 evolution mailing list for not Swift 2.x/Swift 3 suitable proposals (async/await, for example)   Craig Cruden
• [swift-evolution] Proposal: Compile-time parameters   Félix Cloutier
• [swift-evolution] Guaranteed closure execution   Félix Cloutier
• [swift-evolution] Proposal: Compile-time parameters   T.J. Usiyan
• [swift-evolution] Guaranteed closure execution   T.J. Usiyan
• [swift-evolution] Guaranteed closure execution   Matthew Johnson
• [swift-evolution] [proposal] default func ==(_:_:)   Andrew Bennett
• [swift-evolution] Reconsider ++ and -- operators removal and prevent other well-known operators from change   David Turnbull
• [swift-evolution] Swift 4 evolution mailing list for not Swift 2.x/Swift 3 suitable proposals (async/await, for example)   Chris Lattner
• [swift-evolution] Proposal: Compile-time parameters   Joe Groff
• [swift-evolution] Guaranteed closure execution   Chris Lattner
• [swift-evolution] Guaranteed closure execution   Chris Lattner
• [swift-evolution] Reconsider ++ and -- operators removal and prevent other well-known operators from change   davesweeris at mac.com
• [swift-evolution] Reconsider ++ and -- operators removal and prevent other well-known operators from change   Chris Lattner
• [swift-evolution] Proposal: Compile-time parameters   davesweeris at mac.com
• [swift-evolution] [Proposal] Adjusting `inout` Declarations for Type Decoration   Taras Zakharko
• [swift-evolution] Reconsider ++ and -- operators removal and prevent other well-known operators from change   Thorsten Seitz
• [swift-evolution] Reconsider ++ and -- operators removal and prevent other well-known operators from change   Haravikk
• [swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift   Drew Crawford
• [swift-evolution] Brainstorming: New operator type - chaining   Joseph Lord
• [swift-evolution] Reconsider ++ and -- operators removal and prevent other well-known operators from change   Developer
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Matt Whiteside
• [swift-evolution] [Review] SE-0028 Modernizing Swift's Debugging Identifiers (__LINE__, etc)   Curt Clifton
• [swift-evolution] Proposal: Allow @available(*, unavailble) to getter or setter.   Hoon H.
• [swift-evolution] Default implementation for protocols   Howard Lovatt
• [swift-evolution] Guaranteed closure execution   Rod Brown
• [swift-evolution] Brainstorming: New operator type - chaining   Howard Lovatt
• [swift-evolution] Swift 4 evolution mailing list for not Swift 2.x/Swift 3 suitable proposals (async/await, for example)   Vanderlei Martinelli
• [swift-evolution] Proposal: Pattern Matching Partial Function (#111)   Howard Lovatt
• [swift-evolution] [Review] SE-0023 API Design Guidelines (when to use properties)   Joseph Lord
• [swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching   Howard Lovatt
• [swift-evolution] [Review] SE-0023 API Design Guidelines   Joseph Lord
• [swift-evolution] [Review] SE-0023 API Design Guidelines (when to use properties)   Howard Lovatt
• [swift-evolution] Brainstorming: New operator type - chaining   Joseph Lord
• [swift-evolution] Protocols and var { get }   Howard Lovatt
• [swift-evolution] Brainstorming: New operator type - chaining   Craig Cruden
• [swift-evolution] Brainstorming: New operator type - chaining   Howard Lovatt
• [swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching   Dany St-Amant
• [swift-evolution] [Review] SE-0023 API Design Guidelines   Dave Abrahams
• [swift-evolution] [Review] SE-0023 API Design Guidelines   Dave Abrahams
• [swift-evolution] [Review] SE-0023 API Design Guidelines (when to use properties)   Dave Abrahams
• [swift-evolution] [Review] SE-0023 API Design Guidelines   Dave Abrahams
• [swift-evolution] [Review] SE-0023 API Design Guidelines (when to use properties)   Dave Abrahams
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Dave Abrahams
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Dave Abrahams
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   Andrew Bennett
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Dave Abrahams
• [swift-evolution] Operator implementation inside struct/class body   Vanderlei Martinelli
• [swift-evolution] Default implementation for protocols   Chris Lattner
• [swift-evolution] Swift 4 evolution mailing list for not Swift 2.x/Swift 3 suitable proposals (async/await, for example)   Chris Lattner
• [swift-evolution] Tuple conversion and type composition   Andrew Bennett
• [swift-evolution] Brainstorming: New operator type - chaining   Chris Lattner
• [swift-evolution] Brainstorming: Optional sugar inferred map   Paul Ossenbruggen
• [swift-evolution] Operator implementation inside struct/class body   Chris Lattner
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Dave Abrahams
• [swift-evolution] [pitch] Printing versions of try! and try?   Erica Sadun
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Dave Abrahams
• [swift-evolution] Guaranteed closure execution   Félix Cloutier
• [swift-evolution] Default implementation for protocols   Howard Lovatt
• [swift-evolution] Guaranteed closure execution   Gwendal Roué
• [swift-evolution] Modernize Switch/Case Statements?   Thorsten Seitz
• [swift-evolution] Proposal: Replace ?? by an (optional) argument to ?   Thorsten Seitz
• [swift-evolution] Proposal: Compile-time parameters   Thorsten Seitz
• [swift-evolution] Brainstorming: New operator type - chaining   Joseph Lord
• [swift-evolution] Tuple conversion and type composition   Tino Heth
• [swift-evolution] Operator implementation inside struct/class body   Haravikk
• [swift-evolution] [Review] SE-0023 API Design Guidelines (when to use properties)   Rod Brown
• [swift-evolution] Proposal: Compile-time parameters   Tino Heth
• [swift-evolution] Proposal: Compile-time parameters   Tino Heth
• [swift-evolution] [Review] SE-0023 API Design Guidelines   Rod Brown
• [swift-evolution] Proposal: Compile-time parameters   Tino Heth
• [swift-evolution] [Review] SE-0023 API Design Guidelines   Rod Brown
• [swift-evolution] Reconsider ++ and -- operators removal and prevent other well-known operators from change   Tino Heth
• [swift-evolution] Proposal: Replace ?? by an (optional) argument to ?   Amir Michail
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Erica Sadun
• [swift-evolution] Empower String type with regular expression   Patrick Gili
• [swift-evolution] Proposal: Require functions to have a cyclomatic complexity of <= 10.   Amir Michail
• [swift-evolution] Empower String type with regular expression   Patrick Gili
• [swift-evolution] Modernize Switch/Case Statements?   Erica Sadun
• [swift-evolution] Proposal: Require functions to have a cyclomatic complexity of <= 10.   David Turnbull
• [swift-evolution] Guaranteed closure execution   Dany St-Amant
• [swift-evolution] Empower String type with regular expression   Patrick Gili
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   Janosch Hildebrand
• [swift-evolution] Empower String type with regular expression   Patrick Gili
• [swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching   Paul Cantrell
• [swift-evolution] Modernize Switch/Case Statements?   Radosław Pietruszewski
• [swift-evolution] [Review] SE-0023 API Design Guidelines   Paul Cantrell
• [swift-evolution] Modernize Switch/Case Statements?   Thorsten Seitz
• [swift-evolution] [Review] SE-0023 API Design Guidelines   Paul Cantrell
• [swift-evolution] Proposal: Require functions to have a cyclomatic complexity of <= 10.   Developer
• [swift-evolution] Empower String type with regular expression   Dany St-Amant
• [swift-evolution] Email To Post   Logan Wright
• [swift-evolution] Default implementation for protocols   Maximilian Hünenberger
• [swift-evolution] Operator implementation inside struct/class body   Vanderlei Martinelli
• [swift-evolution] Empower String type with regular expression   Patrick Gili
• [swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching   Tino Heth
• [swift-evolution] Optional safe subscripting for arrays   Rudolf Adamkovič
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Dave Abrahams
• [swift-evolution] [Review] SE-0023 API Design Guidelines   Dave Abrahams
• [swift-evolution] Proposal: Require functions to have a cyclomatic complexity of <= 10.   Jonathan Tang
• [swift-evolution] Optional safe subscripting for arrays   Maximilian Hünenberger
• [swift-evolution] [Review] SE-0023 API Design Guidelines   Dave Abrahams
• [swift-evolution] Proposal: Require functions to have a cyclomatic complexity of <= 10.   David Sweeris
• [swift-evolution] Optional safe subscripting for arrays   David Sweeris
• [swift-evolution] Brainstorming: New operator type - chaining   Jonathan Tang
• [swift-evolution] Optional safe subscripting for arrays   David Turnbull
• [swift-evolution] [Review] SE-0023 API Design Guidelines   Howard Lovatt
• [swift-evolution] [Review] SE-0023 API Design Guidelines   Vanderlei Martinelli
• [swift-evolution] Reconsider ++ and -- operators removal and prevent other well-known operators from change   Jonathan Tang
• [swift-evolution] Evolving UnsafeMutablePointer.alloc (was Re: [Review] SE-0006 Apply API Guidelines to the Standard Library)   Janosch Hildebrand
• [swift-evolution] Modernize Switch/Case Statements?   Allen Ding
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   Kevin Ballard
• [swift-evolution] Proposal: Replace ?? by an (optional) argument to ?   Kevin Ballard
• [swift-evolution] Brainstorming: New operator type - chaining   Tyler Cloutier
• [swift-evolution] Brainstorming: New operator type - chaining   Tyler Cloutier
• [swift-evolution] Brainstorming: New operator type - chaining   Austin Zheng
• [swift-evolution] Proposal: Replace ?? by an (optional) argument to ?   Kevin Ballard
• [swift-evolution] Empower String type with regular expression   Dany St-Amant
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   Erica Sadun
• [swift-evolution] Thoughts on making NSOperatingSystemVersion Comparable?   Robert S Mozayeni
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   John Randolph
• [swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library   John Randolph
• [swift-evolution] [Review] SE-0023 API Design Guidelines   Erica Sadun
• [swift-evolution] [Review] SE-0023 API Design Guidelines (when to use properties)   Brent Royal-Gordon
• [swift-evolution] Empower String type with regular expression   Chris Lattner
• [swift-evolution] Guaranteed closure execution   Félix Cloutier
• [swift-evolution] Empower String type with regular expression   John Randolph
• [swift-evolution] Default implementation for protocols   Howard Lovatt
• [swift-evolution] Guaranteed closure execution   Chris Lattner
• [swift-evolution] Brainstorming: Optional sugar inferred map   Paul Ossenbruggen
• [swift-evolution] Guaranteed closure execution   Chris Lattner
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   Chris Lattner
• [swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications   Chris Lattner
• [swift-evolution] Operator implementation inside struct/class body   Chris Lattner
• [swift-evolution] Guaranteed closure execution   Félix Cloutier
• [swift-evolution] [swift-evolution-announce] [Review] SE-0023 API Design Guidelines   Ricardo Parada

Last message date: Sun Jan 31 23:29:44 CST 2016
Archived on: Mon Feb 1 12:22:55 CST 2016

• Messages sorted by: [ thread ] [ subject ] [ author ]
• More info on this list...