The Week Of Monday 27 June 2016 Archives by date

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

Starting: Mon Jun 27 00:10:24 CDT 2016
Ending: Sun Jul 3 23:20:52 CDT 2016
Messages: 1132

• [swift-evolution] Stdlib closure argument labels and parameter names   Charlie Monroe
• [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint   Xiaodi Wu
• [swift-evolution] An upcoming proposal for simplifying leak free, safe closures.   Charlie Monroe
• [swift-evolution] Stdlib closure argument labels and parameter names   Xiaodi Wu
• [swift-evolution] Prohibit invisible characters in identifier names   Saagar Jha
• [swift-evolution] Prohibit invisible characters in identifier names   Charlie Monroe
• [swift-evolution] Prohibit invisible characters in identifier names   Saagar Jha
• [swift-evolution] [Pitch] Add Null struct to Foundation   Jean-Daniel Dupas
• [swift-evolution] [Draft] UnsafeRawPointer API   Dave Abrahams
• [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint   David Hart
• [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint   Xiaodi Wu
• [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint   James Hillhouse
• [swift-evolution] An upcoming proposal for simplifying leak free, safe closures.   Christopher Kornher
• [swift-evolution] [Proposal] Remove force unwrapping in function signature.   David Rönnqvist
• [swift-evolution] SE-0105: Removing Where Clauses from For-In Loops   David Rönnqvist
• [swift-evolution] [Proposal] Revising access modifiers on extensions   Adrian Zubarev
• [swift-evolution] [Proposal] Remove force unwrapping in function signature.   Charlie Monroe
• [swift-evolution] An upcoming proposal for simplifying leak free, safe closures.   Manuel Krebber
• [swift-evolution] Stdlib closure argument labels and parameter names   David Rönnqvist
• [swift-evolution] [Proposal] Revising access modifiers on extensions   Adrian Zubarev
• [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint   Haravikk
• [swift-evolution] [Idea] Syntactic sugar for using methods as functions   Manuel Krebber
• [swift-evolution] [Proposal] Disallow implicit conversion between function/closure with a list of parameters and with tuple parameter. Remove function type inconsistency.   Haravikk
• [swift-evolution] [Proposal] Revising access modifiers on extensions   Adrian Zubarev
• [swift-evolution] [Proposal] Revising access modifiers on extensions   Adrian Zubarev
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Ben Rimmington
• [swift-evolution] [Proposal] Revising access modifiers on extensions   Adrian Zubarev
• [swift-evolution] Stdlib closure argument labels and parameter names   Dave Abrahams
• [swift-evolution] Stdlib closure argument labels and parameter names   Dave Abrahams
• [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint   Xiaodi Wu
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Xiaodi Wu
• [swift-evolution] [Pitch] Remove type inference for associated types   Matthew Johnson
• [swift-evolution] Stdlib closure argument labels and parameter names   Xiaodi Wu
• [swift-evolution] [Idea] Syntactic sugar for using methods as functions   David Rönnqvist
• [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint   Stephen Canon
• [swift-evolution] Revisiting SE-0041 Names   Dave Abrahams
• [swift-evolution] Revisiting SE-0041 Names   Dave Abrahams
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Matthew Johnson
• [swift-evolution] [Review] SE-0104: Protocol-oriented integers   Stephen Canon
• [swift-evolution] Stdlib closure argument labels and parameter names   Dave Abrahams
• [swift-evolution] Revisiting SE-0041 Names   Matthew Johnson
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Matthew Johnson
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Matthew Johnson
• [swift-evolution] [Idea] Syntactic sugar for using methods as functions   Félix Cloutier
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Ben Rimmington
• [swift-evolution] Stdlib closure argument labels and parameter names   Erica Sadun
• [swift-evolution] Stdlib closure argument labels and parameter names   Erica Sadun
• [swift-evolution] Revisiting SE-0041 Names   Dave Abrahams
• [swift-evolution] Stdlib closure argument labels and parameter names   Sean Heber
• [swift-evolution] Stdlib closure argument labels and parameter names   Vladimir.S
• [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint   Erica Sadun
• [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint   Karl
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Dave Abrahams
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Dave Abrahams
• [swift-evolution] [swift-evolution-announce] [Review] SE-0095: Replace `protocol<P1, P2>` syntax with `P1 & P2`   Joe Groff
• [swift-evolution] [Pitch] Add Null struct to Foundation   michael.peternell at gmx.at
• [swift-evolution] [Question] Grand Renaming and Delegate/Datasource protocols !   Jerome ALVES
• [swift-evolution] [Review] SE-0104: Protocol-oriented integers   Nicola Salmoria
• [swift-evolution] Revisiting SE-0041 Names   Erica Sadun
• [swift-evolution] [swift-evolution-announce] [Review] SE-0095: Replace `protocol<P1, P2>` syntax with `P1 & P2`   Austin Zheng
• [swift-evolution] Revisiting SE-0041 Names   L. Mihalkovic
• [swift-evolution] [swift-evolution-announce] [Review] SE-0095: Replace `protocol<P1, P2>` syntax with `P1 & P2`   L. Mihalkovic
• [swift-evolution] [Idea] Syntactic sugar for using methods as functions   Anton Zhilin
• [swift-evolution] Stdlib closure argument labels and parameter names   Dave Abrahams
• [swift-evolution] [Pitch] Add Null struct to Foundation   Jean-Daniel Dupas
• [swift-evolution] [Proposal] Remove force unwrapping in function signature.   Jean-Daniel Dupas
• [swift-evolution] Revisiting SE-0041 Names   Dave Abrahams
• [swift-evolution] [Proposal] Remove force unwrapping in function signature.   Saagar Jha
• [swift-evolution] [Proposal draft] NSError bridging   Douglas Gregor
• [swift-evolution] [Proposal] Revising access modifiers on extensions   Jordan Rose
• [swift-evolution] [Idea] Syntactic sugar for using methods as functions   Charlie Monroe
• [swift-evolution] [Proposal] Remove force unwrapping in function signature.   Charlie Monroe
• [swift-evolution] Revisiting SE-0041 Names   Erica Sadun
• [swift-evolution] Stdlib closure argument labels and parameter names   Erica Sadun
• [swift-evolution] [Proposal] Remove force unwrapping in function signature.   Saagar Jha
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Matthew Johnson
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Matthew Johnson
• [swift-evolution] [Question] Grand Renaming and Delegate/Datasource protocols !   Saagar Jha
• [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint   Saagar Jha
• [swift-evolution] An upcoming proposal for simplifying leak free, safe closures.   Christopher Kornher
• [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint   David Sweeris
• [swift-evolution] [Proposal] Remove force unwrapping in function signature.   Charlie Monroe
• [swift-evolution] Stdlib closure argument labels and parameter names   Dave Abrahams
• [swift-evolution] An upcoming proposal for simplifying leak free, safe closures.   Christopher Kornher
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Haravikk
• [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint   Stephen Canon
• [swift-evolution] Stdlib closure argument labels and parameter names   Erica Sadun
• [swift-evolution] [Discussion] Terms of Art Swiftification   Erica Sadun
• [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint   Saagar Jha
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Dave Abrahams
• [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint   Pyry Jahkola
• [swift-evolution] Stdlib closure argument labels and parameter names   Dave Abrahams
• [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint   Stephen Canon
• [swift-evolution] [Discussion] Terms of Art Swiftification   Dave Abrahams
• [swift-evolution] [Pitch] Remove type inference for associated types   Dave Abrahams
• [swift-evolution] [swift-evolution-announce] [Review] SE-0095: Replace `protocol<P1, P2>` syntax with `P1 & P2`   L. Mihalkovic
• [swift-evolution] [Proposal] Revising access modifiers on extensions   Adrian Zubarev
• [swift-evolution] [Pitch] Remove type inference for associated types   Austin Zheng
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Anton Zhilin
• [swift-evolution] [Proposal] Revising access modifiers on extensions   L. Mihalkovic
• [swift-evolution] An upcoming proposal for simplifying leak free, safe closures.   Dennis Lysenko
• [swift-evolution] [Discussion] Terms of Art Swiftification   Sean Heber
• [swift-evolution] [discussion] Change the behavior of @objc on a class?   Jordan Rose
• [swift-evolution] [Proposal] Remove force unwrapping in function signature.   Dennis Lysenko
• [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint   David Hart
• [swift-evolution] An upcoming proposal for simplifying leak free, safe closures.   L. Mihalkovic
• [swift-evolution] [Question] Grand Renaming and Delegate/Datasource protocols !   Dennis Lysenko
• [swift-evolution] Partial list of open Swift 3 design topics   Chris Lattner
• [swift-evolution] [Discussion] Terms of Art Swiftification   Sean Heber
• [swift-evolution] [discussion] Change the behavior of @objc on a class?   Russ Bishop
• [swift-evolution] [Discussion] Terms of Art Swiftification   Jeff Kelley
• [swift-evolution] [Question] Grand Renaming and Delegate/Datasource protocols !   Sean Heber
• [swift-evolution] [Discussion] Terms of Art Swiftification   Sean Heber
• [swift-evolution] An upcoming proposal for simplifying leak free, safe closures.   Russ Bishop
• [swift-evolution] [Draft] UnsafeRawPointer API   L. Mihalkovic
• [swift-evolution] [Proposal draft] NSError bridging   Charles Srstka
• [swift-evolution] [Proposal draft] NSError bridging   Charles Srstka
• [swift-evolution] [Idea] Syntactic sugar for using methods as functions   Anton Zhilin
• [swift-evolution] [Proposal] Revising access modifiers on extensions   Adrian Zubarev
• [swift-evolution] [Proposal] Revising access modifiers on extensions   Jordan Rose
• [swift-evolution] Revisiting SE-0041 Names   David Sweeris
• [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint   David Sweeris
• [swift-evolution] [Draft] UnsafeRawPointer API   Andrew Trick
• [swift-evolution] [Proposal] Revising access modifiers on extensions   Adrian Zubarev
• [swift-evolution] [Draft] UnsafeRawPointer API   Andrew Trick
• [swift-evolution] [Pitch] Remove type inference for associated types   Dave Abrahams
• [swift-evolution] [Proposal] Revising access modifiers on extensions   Adrian Zubarev
• [swift-evolution] Revisiting SE-0041 Names   Dave Abrahams
• [swift-evolution] [Draft] UnsafeRawPointer API   Dave Abrahams
• [swift-evolution] [Draft] UnsafeRawPointer API   Dave Abrahams
• [swift-evolution] [Draft] UnsafeRawPointer API   Dave Abrahams
• [swift-evolution] [discussion] Change the behavior of @objc on a class?   Dave Abrahams
• [swift-evolution] [Proposal] Sealed classes by default   Javier Soto
• [swift-evolution] Revisiting SE-0041 Names   Dave Abrahams
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Dave Abrahams
• [swift-evolution] Stdlib closure argument labels and parameter names   Dave Abrahams
• [swift-evolution] [Draft] UnsafeRawPointer API   Andrew Trick
• [swift-evolution] [Returned for revision] SE-0077: Improved operator declarations   John McCall
• [swift-evolution] [Draft] UnsafeRawPointer API   Andrew Trick
• [swift-evolution] [Review] SE-0104: Protocol-oriented integers   Dave Abrahams
• [swift-evolution] [Review] SE-0104: Protocol-oriented integers   Dave Abrahams
• [swift-evolution] [Discussion] A Problem With SE-0025?   Jordan Rose
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Russ Bishop
• [swift-evolution] [Review] SE-0104: Protocol-oriented integers   Dave Abrahams
• [swift-evolution] [Proposal] Sealed classes by default   Michael Ilseman
• [swift-evolution] [Draft] UnsafeRawPointer API   Andrew Trick
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Matthew Johnson
• [swift-evolution] [Proposal] Remove force unwrapping in function signature.   Saagar Jha
• [swift-evolution] [Draft] UnsafeRawPointer API   Andrew Trick
• [swift-evolution] [Draft] UnsafeRawPointer API   Andrew Trick
• [swift-evolution] [Discussion] A Problem With SE-0025?   Matthew Johnson
• [swift-evolution] [Proposal] Sealed classes by default   Javier Soto
• [swift-evolution] [Proposal] Sealed classes by default   Michael Ilseman
• [swift-evolution] Revisiting SE-0041 Names   Erica Sadun
• [swift-evolution] SE-0105: Removing Where Clauses from For-In Loops   Tony Arnold
• [swift-evolution] [Proposal] Revising access modifiers on extensions   Jose Cheyo Jimenez
• [swift-evolution] An upcoming proposal for simplifying leak free, safe closures.   Christopher Kornher
• [swift-evolution] An upcoming proposal for simplifying leak free, safe closures.   Christopher Kornher
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Jonathan Hull
• [swift-evolution] An upcoming proposal for simplifying leak free, safe closures.   Christopher Kornher
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Brent Royal-Gordon
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Matthew Johnson
• [swift-evolution] Stdlib closure argument labels and parameter names   Brent Royal-Gordon
• [swift-evolution] [Draft] UnsafeRawPointer API   Dave Abrahams
• [swift-evolution] [Draft] UnsafeRawPointer API   Dave Abrahams
• [swift-evolution] [Draft] Rationalizing Sequence end-operation names   Brent Royal-Gordon
• [swift-evolution] Revisiting SE-0041 Names   Dave Abrahams
• [swift-evolution] [Draft] UnsafeRawPointer API   Andrew Trick
• [swift-evolution] SE-0105: Removing Where Clauses from For-In Loops   Karl
• [swift-evolution] [Discussion] Terms of Art Swiftification   Patrick Smith
• [swift-evolution] [Discussion] Terms of Art Swiftification   Jose Cheyo Jimenez
• [swift-evolution] Stdlib closure argument labels and parameter names   Patrick Smith
• [swift-evolution] Revisiting SE-0041 Names   Xiaodi Wu
• [swift-evolution] [Proposal] Revising access modifiers on extensions   L. Mihalkovic
• [swift-evolution] [Proposal] Sealed classes by default   L. Mihalkovic
• [swift-evolution] [Draft] Rationalizing Sequence end-operation names   Brent Royal-Gordon
• [swift-evolution] [Idea] Syntactic sugar for using methods as functions   Félix Cloutier
• [swift-evolution] [discussion] Change the behavior of @objc on a class?   Charlie Monroe
• [swift-evolution] [Question] Grand Renaming and Delegate/Datasource protocols !   Brent Royal-Gordon
• [swift-evolution] Partial list of open Swift 3 design topics   Charlie Monroe
• [swift-evolution] Partial list of open Swift 3 design topics   Austin Zheng
• [swift-evolution] Stdlib closure argument labels and parameter names   Dave Abrahams
• [swift-evolution] [Draft] UnsafeRawPointer API   Dave Abrahams
• [swift-evolution] Partial list of open Swift 3 design topics   Karl
• [swift-evolution] [Draft] UnsafeRawPointer API   L. Mihalkovic
• [swift-evolution] [Draft] UnsafeRawPointer API   Dmitri Gribenko
• [swift-evolution] [Draft] UnsafeRawPointer API   L. Mihalkovic
• [swift-evolution] [Discussion] Terms of Art Swiftification   Charlie Monroe
• [swift-evolution] Partial list of open Swift 3 design topics   Charlie Monroe
• [swift-evolution] An upcoming proposal for simplifying leak free, safe closures.   Charlie Monroe
• [swift-evolution] [Discussion] Terms of Art Swiftification   Karl
• [swift-evolution] [discussion] Change the behavior of @objc on a class?   Jean-Daniel Dupas
• [swift-evolution] [Discussion] Terms of Art Swiftification   David Rönnqvist
• [swift-evolution] [Discussion] Terms of Art Swiftification   Charlie Monroe
• [swift-evolution] SE-0105: Removing Where Clauses from For-In Loops   Tony Arnold
• [swift-evolution] [Discussion] A Problem With SE-0025?   David Hart
• [swift-evolution] [Discussion] A Problem With SE-0025?   David Hart
• [swift-evolution] [Proposal] Sealed classes by default   Haravikk
• [swift-evolution] [Proposal] Sealed classes by default   Anton Zhilin
• [swift-evolution] [Draft] Rationalizing Sequence end-operation names   Brent Royal-Gordon
• [swift-evolution] [Proposal] Sealed classes by default   Alejandro Martinez
• [swift-evolution] [Idea] Syntactic sugar for using methods as functions   admin at wheerd.de
• [swift-evolution] [Proposal] Sealed classes by default   David Rönnqvist
• [swift-evolution] An upcoming proposal for simplifying leak free, safe closures.   admin at wheerd.de
• [swift-evolution] [Proposal] Sealed classes by default   L. Mihalkovic
• [swift-evolution] [Idea] Syntactic sugar for using methods as functions   Haravikk
• [swift-evolution] [Discussion] Terms of Art Swiftification   Sean Heber
• [swift-evolution] Optionals and nil in Switch statement   Lucas Jordan
• [swift-evolution] Revisiting SE-0041 Names   Erica Sadun
• [swift-evolution] [Draft] Rationalizing Sequence end-operation names   Patrick Smith
• [swift-evolution] [Proposal draft] NSError bridging   Jeff Kelley
• [swift-evolution] Partial list of open Swift 3 design topics   Wallacy
• [swift-evolution] [Returned for revision] SE-0077: Improved operator declarations   Brandon Knope
• [swift-evolution] [Proposal] Sealed classes by default   Mark Lacey
• [swift-evolution] [Proposal] Sealed classes by default   Sean Heber
• [swift-evolution] [Proposal] Sealed classes by default   Charlie Monroe
• [swift-evolution] [Proposal] Sealed classes by default   Javier Soto
• [swift-evolution] [Proposal] Sealed classes by default   Matthew Johnson
• [swift-evolution] [Proposal] Sealed classes by default   Mark Lacey
• [swift-evolution] [Proposal] Sealed classes by default   Matthew Johnson
• [swift-evolution] [Proposal] Sealed classes by default   L. Mihalkovic
• [swift-evolution] [Proposal draft] NSError bridging   Shawn Erickson
• [swift-evolution] [Proposal] Sealed classes by default   L. Mihalkovic
• [swift-evolution] Optionals and nil in Switch statement   Kevin Nattinger
• [swift-evolution] [Proposal] Sealed classes by default   John McCall
• [swift-evolution] [Proposal] Sealed classes by default   L. Mihalkovic
• [swift-evolution] Partial list of open Swift 3 design topics   Douglas Gregor
• [swift-evolution] [Discussion] Terms of Art Swiftification   Shawn Erickson
• [swift-evolution] [Returned for revision] SE-0077: Improved operator declarations   L. Mihalkovic
• [swift-evolution] [Discussion] A Problem With SE-0025?   Jordan Rose
• [swift-evolution] Optionals and nil in Switch statement   Nevin Brackett-Rozinsky
• [swift-evolution] Partial list of open Swift 3 design topics   Douglas Gregor
• [swift-evolution] [Returned for revision] SE-0077: Improved operator declarations   John McCall
• [swift-evolution] Optionals and nil in Switch statement   Kevin Nattinger
• [swift-evolution] Partial list of open Swift 3 design topics   Douglas Gregor
• [swift-evolution] [Discussion] A Problem With SE-0025?   John McCall
• [swift-evolution] Partial list of open Swift 3 design topics   Vladimir.S
• [swift-evolution] An upcoming proposal for simplifying leak free, safe closures.   Christopher Kornher
• [swift-evolution] [Pitch] Changing the behavior of Subsequences of String Views   Loïc Lecrenier
• [swift-evolution] Partial list of open Swift 3 design topics   Austin Zheng
• [swift-evolution] Partial list of open Swift 3 design topics   Erica Sadun
• [swift-evolution] An upcoming proposal for simplifying leak free, safe closures.   Christopher Kornher
• [swift-evolution] Optionals and nil in Switch statement   Lucas Jordan
• [swift-evolution] Add an implicit return nil if function reaches end before return explicitly called   Logan Sease
• [swift-evolution] [Pitch] Changing the behavior of Subsequences of String Views   Dmitri Gribenko
• [swift-evolution] Revisiting SE-0041 Names   Dave Abrahams
• [swift-evolution] Partial list of open Swift 3 design topics   Vladimir.S
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Dave Abrahams
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Dave Abrahams
• [swift-evolution] Partial list of open Swift 3 design topics   Douglas Gregor
• [swift-evolution] [Returned for revision] SE-0077: Improved operator declarations   Dave Abrahams
• [swift-evolution] [discussion] Change the behavior of @objc on a class?   Douglas Gregor
• [swift-evolution] modifying Array<Element> to return Element! when subscripted   Dave Abrahams
• [swift-evolution] Partial list of open Swift 3 design topics   Austin Zheng
• [swift-evolution] Optionals and nil in Switch statement   Kevin Nattinger
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Matthew Johnson
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   Dave Abrahams
• [swift-evolution] [Pitch] Simpler interpretation of a reference to a generic type with no arguments   Dave Abrahams
• [swift-evolution] Shorthand unwrap proposal   Dave Abrahams
• [swift-evolution] Setter methods for vars   Austin Feight
• [swift-evolution] Optionals and nil in Switch statement   Kevin Nattinger
• [swift-evolution] [Draft] Rationalizing Sequence end-operation names   David Hart
• [swift-evolution] [Pitch] Remove type inference for associated types   Douglas Gregor
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Matthew Johnson
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Jonathan Hull
• [swift-evolution] [Pitch] Remove type inference for associated types   Matthew Johnson
• [swift-evolution] [Draft] Rationalizing Sequence end-operation names   Xiaodi Wu
• [swift-evolution] Setter methods for vars   Kenny Leung
• [swift-evolution] Add an implicit return nil if function reaches end before return explicitly called   Xiaodi Wu
• [swift-evolution] [Pitch] Remove type inference for associated types   Douglas Gregor
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Jonathan Hull
• [swift-evolution] [Pitch] Changing the behavior of Subsequences of String Views   Loïc Lecrenier
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Jonathan Hull
• [swift-evolution] [Returned for revision] SE-0077: Improved operator declarations   Anton Zhilin
• [swift-evolution] [Proposal] Sealed classes by default   Michael Peternell
• [swift-evolution] [Proposal] Revising access modifiers on extensions   Adrian Zubarev
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Matthew Johnson
• [swift-evolution] Prohibit invisible characters in identifier names   Russ Bishop
• [swift-evolution] [Draft] UnsafeRawPointer API   Andrew Trick
• [swift-evolution] Setter methods for vars   Michael Peternell
• [swift-evolution] Prohibit invisible characters in identifier names   Xiaodi Wu
• [swift-evolution] [Pitch] Remove type inference for associated types   Austin Zheng
• [swift-evolution] [Proposal] Sealed classes by default   John McCall
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Brent Royal-Gordon
• [swift-evolution] [discussion] Change the behavior of @objc on a class?   Jordan Rose
• [swift-evolution] [Draft] UnsafeRawPointer API   Dmitri Gribenko
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   Erica Sadun
• [swift-evolution] [Proposal] Revising access modifiers on extensions   Jose Cheyo Jimenez
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Dave Abrahams
• [swift-evolution] [Proposal] Revising access modifiers on extensions   Adrian Zubarev
• [swift-evolution] Collection index complexity and data structures   Dave Abrahams
• [swift-evolution] [Draft] UnsafeRawPointer API   Andrew Trick
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   Brandon Knope
• [swift-evolution] [Proposal] Sealed classes by default   Christopher Kornher
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Erica Sadun
• [swift-evolution] Fix or remove Swift.min and Swift.max?   Jens Persson
• [swift-evolution] [Proposal draft] NSError bridging   Douglas Gregor
• [swift-evolution] Optionals and nil in Switch statement   Nevin Brackett-Rozinsky
• [swift-evolution] [Proposal] Sealed classes by default   John McCall
• [swift-evolution] [Draft] Rationalizing Sequence end-operation names   Brent Royal-Gordon
• [swift-evolution] Partial list of open Swift 3 design topics   David Hart
• [swift-evolution] Setter methods for vars   David Hart
• [swift-evolution] [Proposal] Sealed classes by default   Michael Peternell
• [swift-evolution] [Draft] Rationalizing Sequence end-operation names   David Hart
• [swift-evolution] [Draft] Rationalizing Sequence end-operation names   Xiaodi Wu
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Matthew Johnson
• [swift-evolution] Setter methods for vars   michael.peternell at gmx.at
• [swift-evolution] [Pitch] Remove type inference for associated types   Matthew Johnson
• [swift-evolution] Setter methods for vars   Sean Heber
• [swift-evolution] Setter methods for vars   Xiaodi Wu
• [swift-evolution] Setter methods for vars   michael.peternell at gmx.at
• [swift-evolution] Setter methods for vars   Austin Feight
• [swift-evolution] [Proposal] Sealed classes by default   Mark Lacey
• [swift-evolution] [Proposal] Sealed classes by default   John McCall
• [swift-evolution] [Pitch] Remove type inference for associated types   Dave Abrahams
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   Dave Abrahams
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Dave Abrahams
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   Brandon Knope
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   Erica Sadun
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   Hooman Mehr
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Erica Sadun
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Matthew Johnson
• [swift-evolution] [Draft] UnsafeRawPointer API   Dmitri Gribenko
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   David Sweeris
• [swift-evolution] [Discussion] A Problem With SE-0025?   Matthew Judge
• [swift-evolution] Request for quickie proposal and review   Dave Abrahams
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Erica Sadun
• [swift-evolution] [Discussion] A Problem With SE-0025?   Jordan Rose
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Sean Heber
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Matthew Johnson
• [swift-evolution] Request for quickie proposal and review   Erica Sadun
• [swift-evolution] [Discussion] A Problem With SE-0025?   Matthew Johnson
• [swift-evolution] Request for quickie proposal and review   Erica Sadun
• [swift-evolution] Request for quickie proposal and review   Erica Sadun
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Erica Sadun
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Sean Heber
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Erica Sadun
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Sean Heber
• [swift-evolution] Partial list of open Swift 3 design topics   Chris Lattner
• [swift-evolution] Partial list of open Swift 3 design topics   Chris Lattner
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Greg Titus
• [swift-evolution] [Pitch] Remove type inference for associated types   Chris Lattner
• [swift-evolution] [Discussion] A Problem With SE-0025?   Matthew Judge
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Sean Heber
• [swift-evolution] [Proposal] Remove force unwrapping in function signature.   Chris Lattner
• [swift-evolution] [Accepted] SE-0106: Add a macOS Alias for the OSX Platform Configuration Test   Chris Lattner
• [swift-evolution] [Review] SE-0107: UnsafeRawPointer API   Chris Lattner
• [swift-evolution] Partial list of open Swift 3 design topics   Dmitri Gribenko
• [swift-evolution] Setter methods for vars   L. Mihalkovic
• [swift-evolution] [Pitch] Remove type inference for associated types   Paulo Faria
• [swift-evolution] [discussion] Change the behavior of @objc on a class?   L. Mihalkovic
• [swift-evolution] [Pitch] Remove type inference for associated types   Douglas Gregor
• [swift-evolution] [Proposal] Remove force unwrapping in function signature.   David Waite
• [swift-evolution] [Pitch] Remove type inference for associated types   Paulo Faria
• [swift-evolution] [Pitch] Remove type inference for associated types   Paulo Faria
• [swift-evolution] Partial list of open Swift 3 design topics   David Waite
• [swift-evolution] [Proposal] Remove force unwrapping in function signature.   Saagar Jha
• [swift-evolution] Partial list of open Swift 3 design topics   Dmitri Gribenko
• [swift-evolution] [Returned for revision] SE-0077: Improved operator declarations   L. Mihalkovic
• [swift-evolution] Optionals and nil in Switch statement   Charlie Monroe
• [swift-evolution] [Pitch] Remove type inference for associated types   Paulo Faria
• [swift-evolution] [Pitch] Remove type inference for associated types   Austin Zheng
• [swift-evolution] [Proposal draft] NSError bridging   Riley Testut
• [swift-evolution] [Pitch] Remove type inference for associated types   Douglas Gregor
• [swift-evolution] [Draft] UnsafeRawPointer API   Andrew Trick
• [swift-evolution] [Pitch] Remove type inference for associated types   Austin Zheng
• [swift-evolution] [Pitch] Remove type inference for associated types   Paulo Faria
• [swift-evolution] [Pitch] Remove type inference for associated types   Douglas Gregor
• [swift-evolution] [Pitch] Remove type inference for associated types   Austin Zheng
• [swift-evolution] [Pitch] Remove type inference for associated types   Paulo Faria
• [swift-evolution] [Pitch] Remove type inference for associated types   Douglas Gregor
• [swift-evolution] [Proposal draft] NSError bridging   Douglas Gregor
• [swift-evolution] IUO in Swift 3.0   David Hart
• [swift-evolution] [discussion] Fixing Protocols with Self or Associated Type Requirements   Riley Testut
• [swift-evolution] [Pitch] Remove type inference for associated types   Paulo Faria
• [swift-evolution] [Discussion] A Problem With SE-0025?   David Hart
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Adrian Zubarev
• [swift-evolution] [Proposal] Sealed classes by default   Jean-Daniel Dupas
• [swift-evolution] [Pitch] Remove type inference for associated types   Paulo Faria
• [swift-evolution] Take 2: Stdlib closure argument labels and parameter names   Dave Abrahams
• [swift-evolution] [Pitch] Remove type inference for associated types   Douglas Gregor
• [swift-evolution] Setter methods for vars   David Hart
• [swift-evolution] [Pitch] Remove type inference for associated types   Paulo Faria
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Dave Abrahams
• [swift-evolution] [Review] SE-0109: Remove the Boolean protocol   Douglas Gregor
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Adrian Zubarev
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Dave Abrahams
• [swift-evolution] [Pitch] Remove type inference for associated types   Douglas Gregor
• [swift-evolution] [Proposal draft] NSError bridging   Charlie Monroe
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Adrian Zubarev
• [swift-evolution] Optionals and nil in Switch statement   David Hart
• [swift-evolution] [discussion] Fixing Protocols with Self or Associated Type Requirements   Robert Widmann
• [swift-evolution] [Pitch] Remove type inference for associated types   Dave Abrahams
• [swift-evolution] [Pitch] Remove type inference for associated types   Paulo Faria
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   Dave Abrahams
• [swift-evolution] [DRAFT] Enhancing the Platform Configuration Test Suite for Conditional Compilation Blocks   Jacob Bandes-Storch
• [swift-evolution] [discussion] Fixing Protocols with Self or Associated Type Requirements   David Hart
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Adrian Zubarev
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Adrian Zubarev
• [swift-evolution] Optionals and nil in Switch statement   Charlie Monroe
• [swift-evolution] [Draft] Rationalizing Sequence end-operation names   L. Mihalkovic
• [swift-evolution] Optionals and nil in Switch statement   David Hart
• [swift-evolution] Extend FloatingPoint with tau!   David Hart
• [swift-evolution] [discussion] Fixing Protocols with Self or Associated Type Requirements   Robert Widmann
• [swift-evolution] [Proposal draft] NSError bridging   Dmitri Gribenko
• [swift-evolution] [discussion] Fixing Protocols with Self or Associated Type Requirements   Austin Zheng
• [swift-evolution] [Review] SE-0109: Remove the Boolean protocol   Joseph Lord
• [swift-evolution] [Proposal] Remove force unwrapping in function signature.   Spromicky
• [swift-evolution] Take 2: Stdlib closure argument labels and parameter names   Anton Zhilin
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   David Sweeris
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Haravikk
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   David Sweeris
• [swift-evolution] [Proposal draft] NSError bridging   Charles Srstka
• [swift-evolution] [Proposal] Remove force unwrapping in function signature.   Vladimir.S
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Vladimir.S
• [swift-evolution] [Review] SE-0109: Remove the Boolean protocol   Taras Zakharko
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Steve Canon
• [swift-evolution] [Review] SE-0109: Remove the Boolean protocol   David Sweeris
• [swift-evolution] [Review] SE-0109: Remove the Boolean protocol   David Sweeris
• [swift-evolution] [Discussion] A Problem With SE-0025?   Matthew Johnson
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   David Sweeris
• [swift-evolution] [Review] SE-0109: Remove the Boolean protocol   Matthew Johnson
• [swift-evolution] [Post Swift 3] [Proposal] Introducing `group` mechanism   Adrian Zubarev
• [swift-evolution] [Proposal] Sealed classes by default   David Sweeris
• [swift-evolution] [Pitch] Remove type inference for associated types   Brandon Knope
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Stephen Canon
• [swift-evolution] Take 2: Stdlib closure argument labels and parameter names   Matthew Johnson
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Erica Sadun
• [swift-evolution] [swift-evolution-announce] [Review] SE-0109: Remove the Boolean protocol   Matthew Johnson
• [swift-evolution] [Pitch] Remove type inference for associated types   Sean Heber
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Matthew Johnson
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Adrian Zubarev
• [swift-evolution] [swift-evolution-announce] [Review] SE-0107: UnsafeRawPointer API   Matthew Johnson
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Matthew Johnson
• [swift-evolution] [Review] SE-0107: UnsafeRawPointer API   Brad Hilton
• [swift-evolution] [Review] SE-0109: Remove the Boolean protocol   Taras Zakharko
• [swift-evolution] modifying Array<Element> to return Element! when subscripted   T.J. Usiyan
• [swift-evolution] [Discussion] A Problem With SE-0025?   David Hart
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Adrian Zubarev
• [swift-evolution] Take 2: Stdlib closure argument labels and parameter names   Erica Sadun
• [swift-evolution] [Pitch] Remove type inference for associated types   Brandon Knope
• [swift-evolution] [DRAFT] Enhancing the Platform Configuration Test Suite for Conditional Compilation Blocks   Erica Sadun
• [swift-evolution] [Pitch] Remove type inference for associated types   Austin Zheng
• [swift-evolution] [Discussion] A Problem With SE-0025?   Matthew Johnson
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Adrian Zubarev
• [swift-evolution] Take 2: Stdlib closure argument labels and parameter names   Matthew Johnson
• [swift-evolution] [Post Swift 3] [Proposal] Introducing `group` mechanism   Charlie Monroe
• [swift-evolution] [Post Swift 3] [Proposal] Introducing `group` mechanism   Adrian Zubarev
• [swift-evolution] [Discussion] A Problem With SE-0025?   Sean Heber
• [swift-evolution] [Discussion] A Problem With SE-0025?   Xiaodi Wu
• [swift-evolution] [Pitch] Remove type inference for associated types   Douglas Gregor
• [swift-evolution] [Discussion] A Problem With SE-0025?   Matthew Johnson
• [swift-evolution] [Discussion] A Problem With SE-0025?   Xiaodi Wu
• [swift-evolution] Take 2: Stdlib closure argument labels and parameter names   Xiaodi Wu
• [swift-evolution] [Discussion] A Problem With SE-0025?   Matthew Johnson
• [swift-evolution] modifying Array<Element> to return Element! when subscripted   Xiaodi Wu
• [swift-evolution] Take 2: Stdlib closure argument labels and parameter names   Matthew Johnson
• [swift-evolution] [Discussion] A Problem With SE-0025?   Xiaodi Wu
• [swift-evolution] Access modifier blocks   Adrian Zubarev
• [swift-evolution] [Discussion] A Problem With SE-0025?   Matthew Johnson
• [swift-evolution] [Discussion] A Problem With SE-0025?   Austin Zheng
• [swift-evolution] Take 2: Stdlib closure argument labels and parameter names   Sean Heber
• [swift-evolution] [Discussion] A Problem With SE-0025?   Xiaodi Wu
• [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint   Karl
• [swift-evolution] Take 2: Stdlib closure argument labels and parameter names   Erica Sadun
• [swift-evolution] [Discussion] A Problem With SE-0025?   Matthew Johnson
• [swift-evolution] Take 2: Stdlib closure argument labels and parameter names   Xiaodi Wu
• [swift-evolution] [Discussion] A Problem With SE-0025?   Jordan Rose
• [swift-evolution] [discussion] Change the behavior of @objc on a class?   Jordan Rose
• [swift-evolution] [Review] SE-0109: Remove the Boolean protocol   David Sweeris
• [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint   Matthew Johnson
• [swift-evolution] [Proposal] Sealed classes by default   michael.peternell at gmx.at
• [swift-evolution] [Proposal draft] NSError bridging   Michael Peternell
• [swift-evolution] [Discussion] A Problem With SE-0025?   Xiaodi Wu
• [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint   Stephen Canon
• [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint   Stephen Canon
• [swift-evolution] [Proposal draft] NSError bridging   Dmitri Gribenko
• [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint   Matthew Johnson
• [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint   Stephen Canon
• [swift-evolution] Take 2: Stdlib closure argument labels and parameter names   David Hart
• [swift-evolution] [Proposal] Sealed classes by default   Michael Peternell
• [swift-evolution] [Proposal] Sealed classes by default   Matthew Johnson
• [swift-evolution] [Discussion] A Problem With SE-0025?   Jordan Rose
• [swift-evolution] [Proposal] Sealed classes by default   David Sweeris
• [swift-evolution] Take 2: Stdlib closure argument labels and parameter names   Sean Heber
• [swift-evolution] [Post Swift 3] [Proposal] Introducing `group` mechanism   Adrian Zubarev
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   Dave Abrahams
• [swift-evolution] [Post Swift 3] [Proposal] Introducing `group` mechanism   L. Mihalkovic
• [swift-evolution] [Post Swift 3] [Proposal] Introducing `group` mechanism   Adrian Zubarev
• [swift-evolution] [Post Swift 3] [Proposal] Introducing `group` mechanism   Adrian Zubarev
• [swift-evolution] [swift-evolution-announce] [Review] SE-0107: UnsafeRawPointer API   Robert Widmann
• [swift-evolution] [Discussion] A Problem With SE-0025?   Michael Peternell
• [swift-evolution] [Discussion] A Problem With SE-0025?   Jordan Rose
• [swift-evolution] [Discussion] A Problem With SE-0025?   Xiaodi Wu
• [swift-evolution] [Post Swift 3] [Proposal] Introducing `group` mechanism   Adrian Zubarev
• [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint   Xiaodi Wu
• [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint   Stephen Canon
• [swift-evolution] [Proposal] Sealed classes by default   Xiaodi Wu
• [swift-evolution] Take 2: Stdlib closure argument labels and parameter names   Dave Abrahams
• [swift-evolution] [Proposal] Sealed classes by default   John McCall
• [swift-evolution] [Post Swift 3] [Proposal] Introducing `group` mechanism   Adrian Zubarev
• [swift-evolution] [Proposal] Sealed classes by default   michael.peternell at gmx.at
• [swift-evolution] Take 2: Stdlib closure argument labels and parameter names   Dave Abrahams
• [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint   Xiaodi Wu
• [swift-evolution] Take 2: Stdlib closure argument labels and parameter names   Dave Abrahams
• [swift-evolution] Take 2: Stdlib closure argument labels and parameter names   Dave Abrahams
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Adrian Zubarev
• [swift-evolution] [Post Swift 3] [Proposal] Introducing `group` mechanism   Xiaodi Wu
• [swift-evolution] [Post Swift 3] [Proposal] Introducing `group` mechanism   L. Mihalkovic
• [swift-evolution] [Discussion] A Problem With SE-0025?   Vladimir.S
• [swift-evolution] [Post Swift 3] [Proposal] Introducing `group` mechanism   L. Mihalkovic
• [swift-evolution] [Proposal] Sealed classes by default   John McCall
• [swift-evolution] [Review] SE-0107: UnsafeRawPointer API   Andrew Trick
• [swift-evolution] [Proposal] Sealed classes by default   Vladimir.S
• [swift-evolution] [Post Swift 3] [Proposal] Introducing `group` mechanism   Adrian Zubarev
• [swift-evolution] [Post Swift 3] [Proposal] Introducing `group` mechanism   Adrian Zubarev
• [swift-evolution] [Proposal] Sealed classes by default   Michael Peternell
• [swift-evolution] [Proposal draft] NSError bridging   Charles Srstka
• [swift-evolution] [Proposal] Sealed classes by default   Vladimir.S
• [swift-evolution] [Review] SE-0108: Remove associated type inference   Chris Lattner
• [swift-evolution] [swift-evolution-announce] [Review] SE-0109: Remove the Boolean protocol   Scott James Remnant
• [swift-evolution] [Review] SE-0077 v2: Improved operator declarations   Joe Groff
• [swift-evolution] [Review] SE-0109: Remove the Boolean protocol   Chris Lattner
• [swift-evolution] [Proposal] Sealed classes by default   Leonardo Pessoa
• [swift-evolution] [Proposal] Sealed classes by default   Jose Cheyo Jimenez
• [swift-evolution] [Review] SE-0109: Remove the Boolean protocol   Goffredo Marocchi
• [swift-evolution] [Proposal] Sealed classes by default   John McCall
• [swift-evolution] [Proposal] Sealed classes by default   John McCall
• [swift-evolution] [Discussion] A Problem With SE-0025?   Jose Cheyo Jimenez
• [swift-evolution] [Discussion] A Problem With SE-0025?   Jordan Rose
• [swift-evolution] [Proposal] Sealed classes by default   Jean-Daniel Dupas
• [swift-evolution] [Pitch] Change custom operator rules to reserve operators for future use?   Austin Zheng
• [swift-evolution] [Review] SE-0109: Remove the Boolean protocol   Taras Zakharko
• [swift-evolution] [Proposal] Sealed classes by default   Matthew Johnson
• [swift-evolution] [Proposal] Sealed classes by default   Xiaodi Wu
• [swift-evolution] [Review] SE-0104: Protocol-oriented integers   Brent Royal-Gordon
• [swift-evolution] [Review] SE-0109: Remove the Boolean protocol   Tony Allevato
• [swift-evolution] [Discussion] A Problem With SE-0025?   Jordan Rose
• [swift-evolution] [Discussion] A Problem With SE-0025?   Xiaodi Wu
• [swift-evolution] [Discussion] A Problem With SE-0025?   Jordan Rose
• [swift-evolution] [Discussion] A Problem With SE-0025?   Xiaodi Wu
• [swift-evolution] [Discussion] A Problem With SE-0025?   Matthew Johnson
• [swift-evolution] [Discussion] A Problem With SE-0025?   Jordan Rose
• [swift-evolution] [Discussion] A Problem With SE-0025?   Matthew Johnson
• [swift-evolution] [Discussion] A Problem With SE-0025?   Xiaodi Wu
• [swift-evolution] [Discussion] A Problem With SE-0025?   Jordan Rose
• [swift-evolution] [Discussion] A Problem With SE-0025?   Xiaodi Wu
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   David Sweeris
• [swift-evolution] [Discussion] A Problem With SE-0025?   Xiaodi Wu
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   Xiaodi Wu
• [swift-evolution] [Post Swift 3] [Proposal] Introducing `group` mechanism   David Sweeris
• [swift-evolution] [Discussion] A Problem With SE-0025?   Xiaodi Wu
• [swift-evolution] [Discussion] A Problem With SE-0025?   Matthew Johnson
• [swift-evolution] [Discussion] A Problem With SE-0025?   Matthew Johnson
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   David Sweeris
• [swift-evolution] [Discussion] A Problem With SE-0025?   Xiaodi Wu
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   David Sweeris
• [swift-evolution] [Discussion] A Problem With SE-0025?   Xiaodi Wu
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Nate Cook
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   Xiaodi Wu
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Brent Royal-Gordon
• [swift-evolution] [Discussion] A Problem With SE-0025?   Xiaodi Wu
• [swift-evolution] [Discussion] A Problem With SE-0025?   Michael Peternell
• [swift-evolution] [Discussion] A Problem With SE-0025?   Xiaodi Wu
• [swift-evolution] [Discussion] A Problem With SE-0025?   Matthew Johnson
• [swift-evolution] [Discussion] A Problem With SE-0025?   Matthew Johnson
• [swift-evolution] [Proposal draft] NSError bridging   Paul Cantrell
• [swift-evolution] [Discussion] A Problem With SE-0025?   Xiaodi Wu
• [swift-evolution] [Discussion] A Problem With SE-0025?   michael.peternell at gmx.at
• [swift-evolution] [Discussion] A Problem With SE-0025?   Xiaodi Wu
• [swift-evolution] [Discussion] A Problem With SE-0025?   Matthew Johnson
• [swift-evolution] [Discussion] A Problem With SE-0025?   Matthew Johnson
• [swift-evolution] [Discussion] A Problem With SE-0025?   Xiaodi Wu
• [swift-evolution] [Discussion] A Problem With SE-0025?   Matthew Johnson
• [swift-evolution] [Discussion] A Problem With SE-0025?   Xiaodi Wu
• [swift-evolution] [Proposal] Sealed classes by default   Rod Brown
• [swift-evolution] [Discussion] A Problem With SE-0025?   Matthew Johnson
• [swift-evolution] [Discussion] A Problem With SE-0025?   Xiaodi Wu
• [swift-evolution] [Review] SE-0108: Remove associated type inference   Russ Bishop
• [swift-evolution] [Discussion] A Problem With SE-0025?   Matthew Johnson
• [swift-evolution] [Proposal] Sealed classes by default   Mark Lacey
• [swift-evolution] [Discussion] A Problem With SE-0025?   Xiaodi Wu
• [swift-evolution] [Discussion] A Problem With SE-0025?   Matthew Johnson
• [swift-evolution] [Discussion] A Problem With SE-0025?   Matthew Johnson
• [swift-evolution] [Discussion] A Problem With SE-0025?   Matthew Johnson
• [swift-evolution] [Discussion] A Problem With SE-0025?   Xiaodi Wu
• [swift-evolution] [Proposal] Sealed classes by default   David Sweeris
• [swift-evolution] [Proposal] Sealed classes by default   Matthew Johnson
• [swift-evolution] [Proposal] Sealed classes by default   Matthew Johnson
• [swift-evolution] [Discussion] A Problem With SE-0025?   David Hart
• [swift-evolution] [Discussion] A Problem With SE-0025?   Matthew Johnson
• [swift-evolution] [Discussion] A Problem With SE-0025?   Xiaodi Wu
• [swift-evolution] [Discussion] A Problem With SE-0025?   Matthew Johnson
• [swift-evolution] [Proposal] Sealed classes by default   John McCall
• [swift-evolution] [Proposal draft] NSError bridging   Charles Srstka
• [swift-evolution] [Discussion] A Problem With SE-0025?   Jose Cheyo Jimenez
• [swift-evolution] [swift-evolution-announce] [Review] SE-0108: Remove associated type inference   Brent Royal-Gordon
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   David Sweeris
• [swift-evolution] [Discussion] A Problem With SE-0025?   Jordan Rose
• [swift-evolution] [Pitch] Make NSNotification names a protocol like ErrorProtocol   Kenny Leung
• [swift-evolution] [Discussion] A Problem With SE-0025?   Xiaodi Wu
• [swift-evolution] [Discussion] A Problem With SE-0025?   Jordan Rose
• [swift-evolution] [Pitch] Make NSNotification names a protocol like ErrorProtocol   Brent Royal-Gordon
• [swift-evolution] [Discussion] A Problem With SE-0025?   Matthew Johnson
• [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint   Karl Wagner
• [swift-evolution] [Proposal] Remove force unwrapping in function signature.   Chris Lattner
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   David Waite
• [swift-evolution] [Accepted] SE-0095: Replace protocol<P1, P2> syntax with P1 & P2 syntax   Chris Lattner
• [swift-evolution] [Pitch] Make NSNotification names a protocol like ErrorProtocol   Kenny Leung
• [swift-evolution] [Draft] UnsafeRawPointer API   Andrew Trick
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Matthew Johnson
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Matthew Johnson
• [swift-evolution] [Review] SE-0107: UnsafeRawPointer API   Andrew Trick
• [swift-evolution] [swift-evolution-announce] [Review] SE-0108: Remove associated type inference   Matthew Johnson
• [swift-evolution] [Pitch] Make NSNotification names a protocol like ErrorProtocol   Brent Royal-Gordon
• [swift-evolution] [Discussion] A Problem With SE-0025?   Jordan Rose
• [swift-evolution] [Discussion] A Problem With SE-0025?   Xiaodi Wu
• [swift-evolution] Notification.Name   Brent Royal-Gordon
• [swift-evolution] [Review] SE-0077 v2: Improved operator declarations   Matthew Johnson
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   Erica Sadun
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   Jacob Bandes-Storch
• [swift-evolution] [Pitch] Make NSNotification names a protocol like ErrorProtocol   Douglas Gregor
• [swift-evolution] Partial list of open Swift 3 design topics   Karl
• [swift-evolution] [Review] SE-0109: Remove the Boolean protocol   Brent Royal-Gordon
• [swift-evolution] [Post Swift 3] [Proposal] Introducing `group` mechanism   L. Mihalkovic
• [swift-evolution] [swift-evolution-announce] [Review] SE-0108: Remove associated type inference   Russ Bishop
• [swift-evolution] [Post Swift 3] [Proposal] Introducing `group` mechanism   Jose Cheyo Jimenez
• [swift-evolution] [Post Swift 3] [Proposal] Introducing `group` mechanism   L. Mihalkovic
• [swift-evolution] [Proposal] Sealed classes by default   L. Mihalkovic
• [swift-evolution] [Proposal draft] NSError bridging   Charlie Monroe
• [swift-evolution] [Proposal] Sealed classes by default   L. Mihalkovic
• [swift-evolution] [swift-evolution-announce] [Review] SE-0108: Remove associated type inference   Douglas Gregor
• [swift-evolution] [Proposal draft] NSError bridging   Douglas Gregor
• [swift-evolution] [Discussion] A Problem With SE-0025?   Jean-Daniel Dupas
• [swift-evolution] [Discussion] A Problem With SE-0025?   John McCall
• [swift-evolution] [Proposal] Sealed classes by default   John McCall
• [swift-evolution] [Proposal] Sealed classes by default   John McCall
• [swift-evolution] [Proposal draft] NSError bridging   Brent Royal-Gordon
• [swift-evolution] [Review] SE-0077 v2: Improved operator declarations   Anton Zhilin
• [swift-evolution] [Post Swift 3] [Proposal] Introducing `group` mechanism   Haravikk
• [swift-evolution] [Post Swift 3] [Proposal] Introducing `group` mechanism   Haravikk
• [swift-evolution] Re : [Post Swift 3] [Proposal] Introducing `group` mechanism   Adrian Zubarev
• [swift-evolution] Extend FloatingPoint with tau!   Jonathan Hull
• [swift-evolution] [Discussion] A Problem With SE-0025?   Matthew Johnson
• [swift-evolution] [Proposal draft] NSError bridging   Matthew Johnson
• [swift-evolution] Extend FloatingPoint with tau!   Rimantas Liubertas
• [swift-evolution] [Review] SE-0077 v2: Improved operator declarations   Matthew Johnson
• [swift-evolution] [Post Swift 3] [Proposal] Introducing `group` mechanism   Matthew Johnson
• [swift-evolution] [Pitch] Change custom operator rules to reserve operators for future use?   Matthew Johnson
• [swift-evolution] [Pitch] Remove type inference for associated types   Brent Royal-Gordon
• [swift-evolution] [Review] SE-0077 v2: Improved operator declarations   Anton Zhilin
• [swift-evolution] [Pitch] Change custom operator rules to reserve operators for future use?   Jonathan Hull
• [swift-evolution] Extend FloatingPoint with tau!   Joseph Bell
• [swift-evolution] [Pitch] Remove type inference for associated types   Brandon Knope
• [swift-evolution] [Post Swift 3] [Proposal] Introducing `group` mechanism   Brandon Knope
• [swift-evolution] [Review] SE-0077 v2: Improved operator declarations   Matthew Johnson
• [swift-evolution] Extend FloatingPoint with tau!   Stephen Canon
• [swift-evolution] Extend FloatingPoint with tau!   David Waite
• [swift-evolution] [Pitch] Remove type inference for associated types   David Sweeris
• [swift-evolution] [Proposal] Remove force unwrapping in function signature.   J.E. Schotsman
• [swift-evolution] Extend FloatingPoint with tau!   David Waite
• [swift-evolution] [Review] SE-0077 v2: Improved operator declarations   Joe Groff
• [swift-evolution] Notification.Name   Ben Rimmington
• [swift-evolution] [Discussion] A Problem With SE-0025?   Jordan Rose
• [swift-evolution] [Proposal] Remove force unwrapping in function signature.   Saagar Jha
• [swift-evolution] Notification.Name   Michael Ilseman
• [swift-evolution] [swift-evolution-announce] [Review] SE-0107: UnsafeRawPointer API   Guillaume Lessard
• [swift-evolution] [Discussion] A Problem With SE-0025?   Xiaodi Wu
• [swift-evolution] Extend FloatingPoint with tau!   Joe Groff
• [swift-evolution] [Rejected] SE-0105: Removing Where Clauses from For-In Loops   Chris Lattner
• [swift-evolution] [Pitch] Remove type inference for associated types   David Hart
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   David Sweeris
• [swift-evolution] [Discussion] A Problem With SE-0025?   John McCall
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Dave Abrahams
• [swift-evolution] [Pitch] Remove type inference for associated types   Douglas Gregor
• [swift-evolution] [Pitch] Remove type inference for associated types   Kevin Nattinger
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Xiaodi Wu
• [swift-evolution] [Pitch] Remove type inference for associated types   Douglas Gregor
• [swift-evolution] [Proposal draft] NSError bridging   Douglas Gregor
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Russ Bishop
• [swift-evolution] [Pitch] Remove type inference for associated types   David Hart
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   Xiaodi Wu
• [swift-evolution] [Proposal] Sealed classes by default   Andrew Trick
• [swift-evolution] [Review] SE-0077 v2: Improved operator declarations   John McCall
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   Jacob Bandes-Storch
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   Erica Sadun
• [swift-evolution] [Proposal] Sealed classes by default   John McCall
• [swift-evolution] [Review] SE-0112: Improved NSError Bridging   Chris Lattner
• [swift-evolution] [Review] SE-0110: Distinguish between single-tuple and multiple-argument function types   Chris Lattner
• [swift-evolution] [Review] SE-0077 v2: Improved operator declarations   Matthew Johnson
• [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels   Chris Lattner
• [swift-evolution] [Proposal] Sealed classes by default   Matthew Johnson
• [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels   Erica Sadun
• [swift-evolution] [Review] SE-0110: Distinguish between single-tuple and multiple-argument function types   Sean Heber
• [swift-evolution] [swift-evolution-announce] [Review] SE-0112: Improved NSError Bridging   Scott James Remnant
• [swift-evolution] [Review] SE-0110: Distinguish between single-tuple and multiple-argument function types   Guillaume Lessard
• [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels   Sean Heber
• [swift-evolution] [swift-evolution-announce] [Review] SE-0107: UnsafeRawPointer API   Andrew Trick
• [swift-evolution] [swift-evolution-announce] [Review] SE-0111: Remove type system significance of function argument labels   Scott James Remnant
• [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels   Austin Zheng
• [swift-evolution] [Review] SE-0077 v2: Improved operator declarations   John McCall
• [swift-evolution] [Review] SE-0077 v2: Improved operator declarations   Xiaodi Wu
• [swift-evolution] Enhanced existential types proposal discussion   Russ Bishop
• [swift-evolution] [swift-evolution-announce] [Review] SE-0111: Remove type system significance of function argument labels   Austin Zheng
• [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels   Xiaodi Wu
• [swift-evolution] [Returned for Revision] SE-0101: Rename sizeof and related functions to comply with API Guidelines   Chris Lattner
• [swift-evolution] [swift-evolution-announce] [Review] SE-0111: Remove type system significance of function argument labels   Scott James Remnant
• [swift-evolution] [swift-evolution-announce] [Review] SE-0111: Remove type system significance of function argument labels   Austin Zheng
• [swift-evolution] [Review] SE-0077 v2: Improved operator declarations   Matthew Johnson
• [swift-evolution] Request for quickie proposal and review   Dave Abrahams
• [swift-evolution] Request for quickie proposal and review   Dave Abrahams
• [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels   Taras Zakharko
• [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels   Xiaodi Wu
• [swift-evolution] [Review] SE-0110: Distinguish between single-tuple and multiple-argument function types   Matthew Johnson
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   Dave Abrahams
• [swift-evolution] [Review] SE-0077 v2: Improved operator declarations   Xiaodi Wu
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   Dave Abrahams
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   Xiaodi Wu
• [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels   Taras Zakharko
• [swift-evolution] [Review] SE-0110: Distinguish between single-tuple and multiple-argument function types   Taras Zakharko
• [swift-evolution] [Review] SE-0110: Distinguish between single-tuple and multiple-argument function types   David Hart
• [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels   David Hart
• [swift-evolution] [Post Swift 3] [Proposal] Introducing `group` mechanism   Haravikk
• [swift-evolution] Allowing enum extensions to also be able to expand case options   Edward Valentini
• [swift-evolution] Allowing enum extensions to also be able to expand case options   David Sweeris
• [swift-evolution] Allowing enum extensions to also be able to expand case options   Edward Valentini
• [swift-evolution] [swift-evolution-announce] [Review] SE-0111: Remove type system significance of function argument labels   Vladimir.S
• [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels   Austin Zheng
• [swift-evolution] Allowing enum extensions to also be able to expand case options   Guillermo Peralta Scura
• [swift-evolution] [Post Swift 3] [Proposal] Introducing `group` mechanism   Adrian Zubarev
• [swift-evolution] Allowing enum extensions to also be able to expand case options   Dan Appel
• [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels   Vladimir.S
• [swift-evolution] [Discussion] A Problem With SE-0025?   Jordan Rose
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Haravikk
• [swift-evolution] [Accepted] SE-0103: Make non-escaping closures the default   Chris Lattner
• [swift-evolution] Allowing enum extensions to also be able to expand case options   Edward Valentini
• [swift-evolution] Allowing enum extensions to also be able to expand case options   Guillermo Peralta Scura
• [swift-evolution] [swift-evolution-announce] [Review] SE-0111: Remove type system significance of function argument labels   Scott James Remnant
• [swift-evolution] [Proposal] Sealed classes by default   John McCall
• [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels   Taras Zakharko
• [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels   Austin Zheng
• [swift-evolution] [swift-evolution-announce] [Review] SE-0111: Remove type system significance of function argument labels   Xiaodi Wu
• [swift-evolution] Allowing enum extensions to also be able to expand case options   Paul Cantrell
• [swift-evolution] [Proposal] Sealed classes by default   Xiaodi Wu
• [swift-evolution] [Proposal] Sealed classes by default   John McCall
• [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels   Taras Zakharko
• [swift-evolution] [Proposal] Sealed classes by default   Xiaodi Wu
• [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint   Xiaodi Wu
• [swift-evolution] [Accepted] SE-0102: Remove @noreturn attribute and introduce an empty Never type   Chris Lattner
• [swift-evolution] Allowing enum extensions to also be able to expand case options   Dan Appel
• [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint   Stephen Canon
• [swift-evolution] [Review] SE-0110: Distinguish between single-tuple and multiple-argument function types   Vladimir.S
• [swift-evolution] [Proposal] Sealed classes by default   John McCall
• [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint   Taras Zakharko
• [swift-evolution] Allowing enum extensions to also be able to expand case options   David Waite
• [swift-evolution] [Accepted] SE-0104: Protocol-oriented integers   Chris Lattner
• [swift-evolution] [Review] SE-0110: Distinguish between single-tuple and multiple-argument function types   Austin Zheng
• [swift-evolution] Allowing enum extensions to also be able to expand case options   Paul Cantrell
• [swift-evolution] Allowing enum extensions to also be able to expand case options   Dan Appel
• [swift-evolution] Allowing enum extensions to also be able to expand case options   Dan Appel
• [swift-evolution] [Review] SE-0110: Distinguish between single-tuple and multiple-argument function types   Vladimir.S
• [swift-evolution] Objective-C’s @compatibility_alias => Swift’s typealias?   Ayaka Nonaka
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Dave Abrahams
• [swift-evolution] [swift-evolution-announce] [Review] SE-0111: Remove type system significance of function argument labels   Michael Ilseman
• [swift-evolution] [swift-evolution-announce] [Review] SE-0112: Improved NSError Bridging   Charles Srstka
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Dave Abrahams
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Dave Abrahams
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   Russ Bishop
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   Dave Abrahams
• [swift-evolution] [swift-evolution-announce] [Review] SE-0111: Remove type system significance of function argument labels   Charles Srstka
• [swift-evolution] [swift-evolution-announce] [Review] SE-0111: Remove type system significance of function argument labels   Austin Zheng
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   Erica Sadun
• [swift-evolution] Allowing enum extensions to also be able to expand case options   Paul Cantrell
• [swift-evolution] Objective-C’s @compatibility_alias => Swift’s typealias?   Sean Heber
• [swift-evolution] [swift-evolution-announce] [Review] SE-0110: Distinguish between single-tuple and multiple-argument function types   Paul Cantrell
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Russ Bishop
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   Dave Abrahams
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   Erica Sadun
• [swift-evolution] [swift-evolution-announce] [Review] SE-0111: Remove type system significance of function argument labels   Michael Ilseman
• [swift-evolution] Allowing enum extensions to also be able to expand case options   Marc Palmer
• [swift-evolution] [swift-evolution-announce] [Review] SE-0108: Remove associated type inference   Jordan Rose
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Dave Abrahams
• [swift-evolution] [swift-evolution-announce] [Review] SE-0111: Remove type system significance of function argument labels   Michael Ilseman
• [swift-evolution] Objective-C’s @compatibility_alias => Swift’s typealias?   Andrew Bennett
• [swift-evolution] Objective-C’s @compatibility_alias => Swift’s typealias?   Harlan Haskins
• [swift-evolution] Objective-C’s @compatibility_alias => Swift’s typealias?   Ayaka Nonaka
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   James Berry
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   James Berry
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   Erica Sadun
• [swift-evolution] Allowing enum extensions to also be able to expand case options   Andrew Bennett
• [swift-evolution] [swift-evolution-announce] [Review] SE-0111: Remove type system significance of function argument labels   Scott James Remnant
• [swift-evolution] Allowing enum extensions to also be able to expand case options   Austin Zheng
• [swift-evolution] Allowing enum extensions to also be able to expand case options   Daniel Duan
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   James Berry
• [swift-evolution] Allowing enum extensions to also be able to expand case options   Andrew Bennett
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   Matthew Johnson
• [swift-evolution] Allowing enum extensions to also be able to expand case options   Andrew Bennett
• [swift-evolution] [swift-evolution-announce] [Review] SE-0111: Remove type system significance of function argument labels   Xiaodi Wu
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   Dave Abrahams
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   Matthew Johnson
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   Xiaodi Wu
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   John McCall
• [swift-evolution] Objective-C’s @compatibility_alias => Swift’s typealias?   Nicholas Maccharoli
• [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels   Matthew Johnson
• [swift-evolution] [swift-evolution-announce] [Review] SE-0112: Improved NSError Bridging   Charles Srstka
• [swift-evolution] [swift-evolution-announce] [Review] SE-0112: Improved NSError Bridging   Charles Srstka
• [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels   Jordan Rose
• [swift-evolution] [swift-evolution-announce] [Review] SE-0112: Improved NSError Bridging   Matthew Johnson
• [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels   Matthew Johnson
• [swift-evolution] Objective-C’s @compatibility_alias => Swift’s typealias?   Douglas Gregor
• [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels   Jordan Rose
• [swift-evolution] [Proposal] Remove force unwrapping in function signature.   Charlie Monroe
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   Dave Abrahams
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   Dave Abrahams
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   Xiaodi Wu
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   James Berry
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   Jacob Bandes-Storch
• [swift-evolution] [Review] SE-0113: Add integral rounding functions to FloatingPoint   Chris Lattner
• [swift-evolution] [swift-evolution-announce] [Review] SE-0113: Add integral rounding functions to FloatingPoint   Shawn Erickson
• [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels   David Hart
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   Xiaodi Wu
• [swift-evolution] Allowing enum extensions to also be able to expand case options   Chris Lattner
• [swift-evolution] Objective-C’s @compatibility_alias => Swift’s typealias?   Goffredo Marocchi
• [swift-evolution] [Proposal] Sealed classes by default   Brent Royal-Gordon
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   Dave Abrahams
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   Dave Abrahams
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   Xiaodi Wu
• [swift-evolution] [Proposal] Sealed classes by default   Xiaodi Wu
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Haravikk
• [swift-evolution] Proposal: Remove the underscore and `in` for `for` loop   Diego Barros
• [swift-evolution] Proposal: Remove the underscore and `in` for `for` loop   Adrian Zubarev
• [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint   Björn Forster
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Adrian Zubarev
• [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels   Taras Zakharko
• [swift-evolution] [Proposal] Union Type   Cao Jiannan
• [swift-evolution] [Proposal] Union Type   Cao Jiannan
• [swift-evolution] [Proposal] Sealed classes by default   Brent Royal-Gordon
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Brent Royal-Gordon
• [swift-evolution] [Probe] The automatically generated init for structs   Daniel Steinberg
• [swift-evolution] [Review] SE-0113: Add integral rounding functions to FloatingPoint   Joseph Lord
• [swift-evolution] [Review] SE-0113: Add integral rounding functions to FloatingPoint   Stephen Canon
• [swift-evolution] Overrides in class extensions   Rudolf Adamkovič
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   Stephen Canon
• [swift-evolution] Besides pi, include also e as a builtin mathematical constant into floats   Björn Forster
• [swift-evolution] [Review] SE-0113: Add integral rounding functions to FloatingPoint   Taras Zakharko
• [swift-evolution] Include sqrt and remainder into FloatingPoint protocol as built in functions as required by IEEE754   Björn Forster
• [swift-evolution] Proposal: Remove the underscore and `in` for `for` loop   Joseph Bell
• [swift-evolution] [swift-evolution-announce] [Review] SE-0108: Remove associated type inference   T.J. Usiyan
• [swift-evolution] [Discussion] Can we make `.Type` Hashable?   Adrian Zubarev
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   David Sweeris
• [swift-evolution] [Discussion] Can we make `.Type` Hashable?   David Sweeris
• [swift-evolution] [apple/swift-evolution] Proposal: Union Type   Cao Jiannan
• [swift-evolution] [Proposal] Union Type   Adrian Zubarev
• [swift-evolution] [Proposal] Union Type   Cao Jiannan
• [swift-evolution] [Proposal] Union Type   Cao Jiannan
• [swift-evolution] [Proposal] Union Type   Adrian Zubarev
• [swift-evolution] [Discussion] Can we make `.Type` Hashable?   Tony Allevato
• [swift-evolution] [Discussion] Can we make `.Type` Hashable?   Sean Heber
• [swift-evolution] Variadics through tuples   James Froggatt
• [swift-evolution] [Discussion] Can we make `.Type` Hashable?   Matthew Johnson
• [swift-evolution] [Discussion] Can we make `.Type` Hashable?   Adrian Zubarev
• [swift-evolution] Proposal: Remove the underscore and `in` for `for` loop   Sean Heber
• [swift-evolution] [Proposal] Union Type   Cao Jiannan
• [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels   Brad Hilton
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Dave Abrahams
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Dave Abrahams
• [swift-evolution] [Review] SE-0113: Add integral rounding functions to FloatingPoint   Brad Hilton
• [swift-evolution] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type   Thorsten Seitz
• [swift-evolution] [Review] SE-0105: Removing Where Clauses from For-In Loops   Thorsten Seitz
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   Erica Sadun
• [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint   Stephen Canon
• [swift-evolution] Include sqrt and remainder into FloatingPoint protocol as built in functions as required by IEEE754   Xiaodi Wu
• [swift-evolution] [Review] SE-0113: Add integral rounding functions to FloatingPoint   T.J. Usiyan
• [swift-evolution] [Review] SE-0113: Add integral rounding functions to FloatingPoint   Shawn Erickson
• [swift-evolution] [Pitch] Self.withoutSpecialization   T.J. Usiyan
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   John McCall
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Matthew Johnson
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Matthew Johnson
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Matthew Johnson
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Matthew Johnson
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Erica Sadun
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Shawn Erickson
• [swift-evolution] Besides pi, include also e as a builtin mathematical constant into floats   Erica Sadun
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Dave Abrahams
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Matthew Johnson
• [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels   Jordan Rose
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Matthew Johnson
• [swift-evolution] [Review] SE-0077 v2: Improved operator declarations   Anton Zhilin
• [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines   John McCall
• [swift-evolution] [Review] SE-0077 v2: Improved operator declarations   Anton Zhilin
• [swift-evolution] [Proposal] Sealed classes by default   John McCall
• [swift-evolution] [Proposal] Sealed classes by default   John McCall
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Dave Abrahams
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Dave Abrahams
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Dave Abrahams
• [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels   Michael Ilseman
• [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels   Michael Ilseman
• [swift-evolution] [Proposal] Union Type   Joe Groff
• [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels   T.J. Usiyan
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Xiaodi Wu
• [swift-evolution] [swift-evolution-announce] [Review] SE-0113: Add integral rounding functions to FloatingPoint   Jordan Rose
• [swift-evolution] [swift-evolution-announce] [Review] SE-0113: Add integral rounding functions to FloatingPoint   Stephen Canon
• [swift-evolution] [swift-evolution-announce] [Review] SE-0113: Add integral rounding functions to FloatingPoint   Jordan Rose
• [swift-evolution] [Review] SE-0113: Add integral rounding functions to FloatingPoint   Karl
• [swift-evolution] [Review] SE-0113: Add integral rounding functions to FloatingPoint   Stephen Canon
• [swift-evolution] [swift-evolution-announce] [Review] SE-0113: Add integral rounding functions to FloatingPoint   Erica Sadun
• [swift-evolution] [swift-evolution-announce] [Review] SE-0113: Add integral rounding functions to FloatingPoint   Xiaodi Wu
• [swift-evolution] [swift-evolution-announce] [Review] SE-0113: Add integral rounding functions to FloatingPoint   Stephen Canon
• [swift-evolution] [Proposal] Sealed classes by default   Leonardo Pessoa
• [swift-evolution] Fwd: [Proposal] Union Type   Cao Jiannan
• [swift-evolution] Allowing enum extensions to also be able to expand case options   Dan Appel
• [swift-evolution] [Proposal] Union Type   L. Mihalkovic
• [swift-evolution] [Proposal] Sealed classes by default   Michael Ilseman
• [swift-evolution] [Proposal] Sealed classes by default   John McCall
• [swift-evolution] [Discussion] Can we make `.Type` Hashable?   Keith Smiley
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Dave Abrahams
• [swift-evolution] Variadics through tuples   Vladimir.S
• [swift-evolution] [Discussion] Can we make `.Type` Hashable?   Alex Migicovsky
• [swift-evolution] [Proposal] Sealed classes by default   Sean Heber
• [swift-evolution] [Proposal] Sealed classes by default   Sean Heber
• [swift-evolution] [Proposal] Sealed classes by default   Sean Heber
• [swift-evolution] Besides pi, include also e as a builtin mathematical constant into floats   David Waite
• [swift-evolution] Besides pi, include also e as a builtin mathematical constant into floats   Stephen Canon
• [swift-evolution] [Proposal] Union Type   David Sweeris
• [swift-evolution] renaming CustomStringConvertible   Eric Habberstad
• [swift-evolution] renaming CustomStringConvertible   Xiaodi Wu
• [swift-evolution] renaming CustomStringConvertible   Dmitri Gribenko
• [swift-evolution] renaming CustomStringConvertible   Xiaodi Wu
• [swift-evolution] renaming CustomStringConvertible   Vladimir.S
• [swift-evolution] renaming CustomStringConvertible   David Sweeris
• [swift-evolution] renaming CustomStringConvertible   Xiaodi Wu
• [swift-evolution] renaming CustomStringConvertible   Vladimir.S
• [swift-evolution] [Discussion] Rename BitwiseOperations protocol   Riley Testut
• [swift-evolution] renaming CustomStringConvertible   Dmitri Gribenko
• [swift-evolution] [Proposal] Union Type   Matthew Johnson
• [swift-evolution] [Proposal] Sealed classes by default   Jose Cheyo Jimenez
• [swift-evolution] renaming CustomStringConvertible   David Sweeris
• [swift-evolution] [Review] SE-0113: Add integral rounding functions to FloatingPoint   David Rönnqvist
• [swift-evolution] [Proposal] Union Type   Chris Lattner
• [swift-evolution] [Probe] The automatically generated init for structs   Chris Lattner
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Dave Abrahams
• [swift-evolution] [Review] SE-0113: Add integral rounding functions to FloatingPoint   David Rönnqvist
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Xiaodi Wu
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Dave Abrahams
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Vladimir.S
• [swift-evolution] Variadics through tuples   James Froggatt
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Dmitri Gribenko
• [swift-evolution] [Probe] The automatically generated init for structs   Daniel Steinberg
• [swift-evolution] [Discussion] Can we make `.Type` Hashable?   Keith Smiley
• [swift-evolution] [Review] SE-0113: Add integral rounding functions to FloatingPoint   Jonathan Hull
• [swift-evolution] Variadics through tuples   Vladimir.S
• [swift-evolution] [Review] SE-0112: Improved NSError Bridging   Douglas Gregor
• [swift-evolution] [swift-evolution-announce] [Review] SE-0108: Remove associated type inference   Brent Royal-Gordon
• [swift-evolution] Variadics through tuples   James Froggatt
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Matthew Johnson
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Adrian Zubarev
• [swift-evolution] Variadics through tuples   James Froggatt
• [swift-evolution] [Review] SE-0114: Updating Buffer "Value" Names to "Header" Names   Chris Lattner
• [swift-evolution] [swift-evolution-announce] [Review] SE-0114: Updating Buffer "Value" Names to "Header" Names   Austin Zheng
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   David Sweeris
• [swift-evolution] [swift-evolution-announce] [Review] SE-0114: Updating Buffer "Value" Names to "Header" Names   James Berry
• [swift-evolution] [swift-evolution-announce] [Review] SE-0113: Add integral rounding functions to FloatingPoint   James Berry
• [swift-evolution] [Proposal] Sealed classes by default   Ben Rimmington
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Matthew Johnson
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Matthew Johnson
• [swift-evolution] [swift-evolution-announce] [Review] SE-0114: Updating Buffer "Value" Names to "Header" Names   Matthew Johnson
• [swift-evolution] [Review] SE-0110: Distinguish between single-tuple and multiple-argument function types   Daniel Duan
• [swift-evolution] [Draft] Rationalizing Sequence end-operation names   Dave Abrahams
• [swift-evolution] [swift-evolution-announce] [Review] SE-0108: Remove associated type inference   Russ Bishop
• [swift-evolution] Fwd: [Draft] Rationalizing Sequence end-operation names   Dave Abrahams
• [swift-evolution] [Returned for Revision] SE-0091: Improving operator requirements in protocols   Chris Lattner
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Dave Abrahams
• [swift-evolution] Variadics through tuples   Vladimir.S
• [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols   Chris Lattner
• [swift-evolution] Variadics through tuples   Chris Lattner
• [swift-evolution] [Pitch] Self.withoutSpecialization   T.J. Usiyan
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Dave Abrahams
• [swift-evolution] [Review] SE-0110: Distinguish between single-tuple and multiple-argument function types   Vladimir.S
• [swift-evolution] [swift-evolution-announce] [Review] SE-0115: Rename Literal Syntax Protocols   David Sweeris
• [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels   Tony Allevato
• [swift-evolution] [Review] SE-0110: Distinguish between single-tuple and multiple-argument function types   T.J. Usiyan
• [swift-evolution] [Pitch] Importing Objective-C 'id' as Swift 'Any'   Joe Groff
• [swift-evolution] [Pitch] Importing Objective-C 'id' as Swift 'Any'   T.J. Usiyan
• [swift-evolution] [Pitch] Importing Objective-C 'id' as Swift 'Any'   Daniel Duan
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Dave Abrahams
• [swift-evolution] Take 2: Stdlib closure argument labels and parameter names   Dave Abrahams
• [swift-evolution] Take 2: Stdlib closure argument labels and parameter names   Dave Abrahams
• [swift-evolution] [Review] SE-0104: Protocol-oriented integers   Dave Abrahams
• [swift-evolution] [Discussion] Rename BitwiseOperations protocol   Dave Abrahams
• [swift-evolution] renaming CustomStringConvertible   Dave Abrahams
• [swift-evolution] [Review] SE-0112: Improved NSError Bridging   Charles Srstka
• [swift-evolution] [Review] SE-0112: Improved NSError Bridging   Douglas Gregor
• [swift-evolution] Take 2: Stdlib closure argument labels and parameter names   Matthew Johnson
• [swift-evolution] [Pitch] Importing Objective-C 'id' as Swift 'Any'   Matthew Johnson
• [swift-evolution] [Review] SE-0110: Distinguish between single-tuple and multiple-argument function types   Daniel Duan
• [swift-evolution] [Review] SE-0112: Improved NSError Bridging   Brent Royal-Gordon
• [swift-evolution] Variadics through tuples   James Froggatt
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Matthew Johnson
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Dave Abrahams
• [swift-evolution] [swift-evolution-announce] [Review] SE-0111: Remove type system significance of function argument labels   James Froggatt
• [swift-evolution] Take 2: Stdlib closure argument labels and parameter names   Dave Abrahams
• [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels   James Froggatt
• [swift-evolution] [swift-evolution-announce] [Review] SE-0111: Remove type system significance of function argument labels   James Froggatt
• [swift-evolution] [swift-evolution-announce] [Review] SE-0110: Distinguish between single-tuple and multiple-argument function types   James Froggatt
• [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels   Austin Zheng
• [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels   James Froggatt
• [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels   Austin Zheng
• [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels   James Froggatt
• [swift-evolution] [swift-evolution-announce] [Review] SE-0111: Remove type system significance of function argument labels   James Froggatt
• [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels   Austin Zheng
• [swift-evolution] [Pitch] Importing Objective-C 'id' as Swift 'Any'   David Waite
• [swift-evolution] [Review] SE-0104: Protocol-oriented integers   Patrick Pijnappel
• [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels   James Froggatt
• [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels   James Froggatt
• [swift-evolution] [Review] SE-0112: Improved NSError Bridging   Charles Srstka
• [swift-evolution] Bridging Python Packages to Swift   Muhammad Tahir Vali
• [swift-evolution] [Pitch] Importing Objective-C 'id' as Swift 'Any'   Chris Lattner
• [swift-evolution] [swift-evolution-announce] [Review] SE-0115: Rename Literal Syntax Protocols   Brent Royal-Gordon
• [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels   Xiaodi Wu
• [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels   James Froggatt
• [swift-evolution] [Review] SE-0114: Updating Buffer "Value" Names to "Header" Names   Brent Royal-Gordon
• [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels   Xiaodi Wu
• [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels   James Froggatt
• [swift-evolution] [Discussion] Can we make `.Type` Hashable?   L. Mihalkovic
• [swift-evolution] [Proposal] Sealed classes by default   L. Mihalkovic
• [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels   Xiaodi Wu
• [swift-evolution] [swift-evolution-announce] [Review] SE-0113: Add integral rounding functions to FloatingPoint   Brent Royal-Gordon
• [swift-evolution] [Pitch] Importing Objective-C 'id' as Swift 'Any'   Goffredo Marocchi
• [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>   Thorsten Seitz
• [swift-evolution] [Proposal] Sealed classes by default   Brent Royal-Gordon
• [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols   Charlie Monroe
• [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols   Anton Zhilin
• [swift-evolution] [Accepted] SE-0104: Protocol-oriented integers   Nevin Brackett-Rozinsky
• [swift-evolution] [Pitch] Remove destructive consumption from Sequence   Matthew Johnson
• [swift-evolution] [Proposal] Sealed classes by default   L. Mihalkovic
• [swift-evolution] [Pitch] Importing Objective-C 'id' as Swift 'Any'   Matthew Johnson
• [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols   Matthew Johnson
• [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols   Anton Zhilin
• [swift-evolution] Proposal: Remove the underscore and `in`for `for` loop   Anton Zhilin
• [swift-evolution] [Pitch] Importing Objective-C 'id' as Swift 'Any'   Shawn Erickson
• [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols   Anton Zhilin
• [swift-evolution] [Review] SE-0104: Protocol-oriented integers   Dave Abrahams
• [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols   Matthew Johnson
• [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols   Anton Zhilin
• [swift-evolution] [Proposal] Sealed classes by default   T.J. Usiyan
• [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols   Matthew Johnson
• [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols   Dave Abrahams
• [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols   Dave Abrahams
• [swift-evolution] [Pitch] Self.withoutSpecialization   Dave Abrahams
• [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols   Riley Testut
• [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols   Riley Testut
• [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols   Adrian Zubarev
• [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols   Anton Zhilin
• [swift-evolution] [swift-evolution-announce] [Review] SE-0115: Rename Literal Syntax Protocols   Chris Lattner
• [swift-evolution] [swift-evolution-announce] [Review] SE-0115: Rename Literal Syntax Protocols   Adrian Zubarev
• [swift-evolution] [Pitch] Importing Objective-C 'id' as Swift 'Any'   Chris Lattner
• [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols   Anton Zhilin
• [swift-evolution] [Pitch] Self.withoutSpecialization   T.J. Usiyan
• [swift-evolution] [Proposal] Sealed classes by default   L. Mihalkovic
• [swift-evolution] [Discussion] Static curried versions for variables and constants.   Nikita Leonov
• [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols   Dave Abrahams
• [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols   Riley Testut
• [swift-evolution] [Review] SE-0077 v2: Improved operator declarations   Nevin Brackett-Rozinsky
• [swift-evolution] [Discussion] Static curried versions for variables and constants.   Brent Royal-Gordon
• [swift-evolution] [Discussion] Static curried versions for variables and constants.   Nikita Leonov
• [swift-evolution] Random ideas: goto, loop, multiple dispatch, explicit aliasing   Daryle Walker
• [swift-evolution] Fixed-sized arrays   Daryle Walker
• [swift-evolution] Random ideas: goto, loop, multiple dispatch, explicit aliasing   Taras Zakharko
• [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols   Dave Abrahams
• [swift-evolution] [swift-evolution-announce] [Review] SE-0107: UnsafeRawPointer API   Brent Royal-Gordon
• [swift-evolution] Random ideas: goto, loop, multiple dispatch, explicit aliasing   Brent Royal-Gordon
• [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols   Erica Sadun
• [swift-evolution] [Pitch] Importing Objective-C 'id' as Swift 'Any'   Kevin Lundberg
• [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols   Anders Ha
• [swift-evolution] [swift-evolution-announce] [Review] SE-0107: UnsafeRawPointer API   Andrew Trick
• [swift-evolution] [Review] SE-0077 v2: Improved operator declarations   Goffredo Marocchi
• [swift-evolution] [Review] SE-0107: UnsafeRawPointer API (initialize:with:)   Andrew Trick
• [swift-evolution] Proposal: Remove the underscore and `in`for `for` loop   Haravikk
• [swift-evolution] [Review] SE-0110: Distinguish between single-tuple and multiple-argument function types   Vladimir.S
• [swift-evolution] [Review] SE-0112: Improved NSError Bridging   Mohsen Ramezanpoor
• [swift-evolution] [Proposal Draft] Literal Syntax Protocols   Vladimir.S
• [swift-evolution] [Review] SE-0107: UnsafeRawPointer API (initialize:with:)   Xiaodi Wu
• [swift-evolution] [Pre-proposal] Fix function type grammar   Anton Zhilin
• [swift-evolution] [Draft] Rationalizing Sequence end-operation names   Nevin Brackett-Rozinsky
• [swift-evolution] [Pre-proposal] Fix function type grammar   Chris Lattner
• [swift-evolution] [Pre-proposal] Fix function type grammar   Anton Zhilin
• [swift-evolution] [Review] SE-0077 v2: Improved operator declarations   Ben Rimmington
• [swift-evolution] [Pre-proposal] Fix function type grammar   Chris Lattner
• [swift-evolution] [Discussion] Rename BitwiseOperations protocol   Nevin Brackett-Rozinsky
• [swift-evolution] [Review] SE-0110: Distinguish between single-tuple and multiple-argument function types   Haravikk
• [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols   David Sweeris
• [swift-evolution] [Review] SE-0110: Distinguish between single-tuple and multiple-argument function types   Vladimir.S
• [swift-evolution] [Pre-proposal] Fix function type grammar   Vladimir.S
• [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols   Nevin Brackett-Rozinsky
• [swift-evolution] [Pre-proposal] Fix function type grammar   Anton Zhilin
• [swift-evolution] [Review] SE-0110: Distinguish between single-tuple and multiple-argument function types   Haravikk
• [swift-evolution] [Review] SE-0110: Distinguish between single-tuple and multiple-argument function types   Xiaodi Wu
• [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels   Pyry Jahkola
• [swift-evolution] [Discussion] Rename BitwiseOperations protocol   Chris Lattner
• [swift-evolution] [Discussion] Rename BitwiseOperations protocol   Riley Testut
• [swift-evolution] [Discussion] Zero-element tuple glitch   Anton Zhilin
• [swift-evolution] [Discussion] Rename BitwiseOperations protocol   Chris Lattner
• [swift-evolution] [Pre-proposal] Fix function type grammar   Vladimir.S
• [swift-evolution] [Discussion] Determining argument count from context   Anton Zhilin
• [swift-evolution] [Review] SE-0110: Distinguish between single-tuple and multiple-argument function types   Vladimir.S
• [swift-evolution] [Discussion] Determining argument count from context   Vladimir.S
• [swift-evolution] [Discussion] Zero-element tuple glitch   Vladimir.S
• [swift-evolution] [Discussion] Determining argument count from context   Paul Cantrell
• [swift-evolution] Fix or remove Swift.min and Swift.max?   Pyry Jahkola
• [swift-evolution] [Pre-proposal] Fix function type grammar   Anton Zhilin
• [swift-evolution] Bit arrays   Daryle Walker
• [swift-evolution] [Discussion] Zero-element tuple glitch   Anton Zhilin
• [swift-evolution] [Pre-proposal] Fix function type grammar   Vladimir.S
• [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels   L. Mihalkovic
• [swift-evolution] [Discussion] Zero-element tuple glitch   Vladimir.S
• [swift-evolution] [Discussion] Zero-element tuple glitch   Austin Zheng
• [swift-evolution] [Discussion] Zero-element tuple glitch   Xiaodi Wu
• [swift-evolution] Bit arrays   Chris Lattner
• [swift-evolution] Multiple protocols variable - automatic class-type inference   Jakub Skotnicki
• [swift-evolution] Bit arrays   Xiaodi Wu
• [swift-evolution] Bit arrays   Taras Zakharko
• [swift-evolution] [Discussion] Zero-element tuple glitch   Austin Zheng
• [swift-evolution] [Review] SE-0112: Improved NSError Bridging   Douglas Gregor
• [swift-evolution] Fix or remove Swift.min and Swift.max?   Haravikk
• [swift-evolution] [Accepted] SE-0104: Protocol-oriented integers   Félix Cloutier
• [swift-evolution] [Pre-proposal] Fix function type grammar   Anton Zhilin
• [swift-evolution] [Pre-proposal] Fix function type grammar   Austin Zheng
• [swift-evolution] [Proposal] Allow enumerating cases in enumerations   Gabriel Lanata
• [swift-evolution] [Proposal] Allow enumerating cases in enumerations   Saagar Jha
• [swift-evolution] [Proposal] Allow enumerating cases in enumerations   Guillermo Peralta Scura
• [swift-evolution] Bit arrays   Chris Lattner
• [swift-evolution] [Idea] Large integer literals   Brent Royal-Gordon

Last message date: Sun Jul 3 23:20:52 CDT 2016
Archived on: Tue Jul 5 10:30:02 CDT 2016

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