The Week Of Monday 18 April 2016 Archives by date

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

Starting: Mon Apr 18 01:14:39 CDT 2016
Ending: Sun Apr 24 22:04:49 CDT 2016
Messages: 500

• [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices   Thorsten Seitz
• [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices   Dmitri Gribenko
• [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices   Thorsten Seitz
• [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices   Thorsten Seitz
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Dennis Weissmann
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Gwendal Roué
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Dennis Weissmann
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Gwendal Roué
• [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices   Thorsten Seitz
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Justin Jia
• [swift-evolution] [PROPOSAL]Return subclass type to a protocol where a superclass is defined without the need for associatedtype   Ross O'Brien
• [swift-evolution] [PROPOSAL]Return subclass type to a protocol where a superclass is defined without the need for associatedtype   Gwendal Roué
• [swift-evolution] [PROPOSAL]Return subclass type to a protocol where a superclass is defined without the need for associatedtype   Yogev Sitton
• [swift-evolution] [PROPOSAL]Return subclass type to a protocol where a superclass is defined without the need for associatedtype   Yogev Sitton
• [swift-evolution] [PROPOSAL]Return subclass type to a protocol where a superclass is defined without the need for associatedtype   Gwendal Roué
• [swift-evolution] [PROPOSAL]Return subclass type to a protocol where a superclass is defined without the need for associatedtype   Yogev Sitton
• [swift-evolution] [Proposal] Custom operators   Антон Жилин
• [swift-evolution] [PROPOSAL]Return subclass type to a protocol where a superclass is defined without the need for associatedtype   Gwendal Roué
• [swift-evolution] [PROPOSAL]Return subclass type to a protocol where a superclass is defined without the need for associatedtype   Ross O'Brien
• [swift-evolution] [PROPOSAL]Return subclass type to a protocol where a superclass is defined without the need for associatedtype   Yogev Sitton
• [swift-evolution] [PROPOSAL]Return subclass type to a protocol where a superclass is defined without the need for associatedtype   Gwendal Roué
• [swift-evolution] [PROPOSAL]Return subclass type to a protocol where a superclass is defined without the need for associatedtype   Ross O'Brien
• [swift-evolution] [Pitch] Unifying init parameters with properties   Vladimir.S
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Dennis Weissmann
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Thorsten Seitz
• [swift-evolution] ValueEnumerable protocol with derived implementation for enums   Vladimir.S
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Tino Heth
• [swift-evolution] [SR-933] Rename flatten to flattened   Vladimir.S
• [swift-evolution] What about a VBA style with Statement?   Vladimir.S
• [swift-evolution] What about a VBA style with Statement?   Vladimir.S
• [swift-evolution] Feature proposal: Range operator with step   Vladimir.S
• [swift-evolution] [Proposal] Add keyword "by" as syntactic sugar to streamline For-In-loop   Vladimir.S
• [swift-evolution] [META] Fast Track Reviews   Erica Sadun
• [swift-evolution] [Draft] Expanded min/max algorithms   Dmitri Gribenko
• [swift-evolution] [Accepted] SE-0048: Generic Type Aliases   Douglas Gregor
• [swift-evolution] [Proposal] mapValues   Maximilian Hünenberger
• [swift-evolution] [META] Fast Track Reviews   Jacob Bandes-Storch
• [swift-evolution] [Accepted] SE-0064: Referencing the Objective-C selector of property getters and setters   David Hart
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Vladimir.S
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Daniel Duan
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Vladimir.S
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Tony Allevato
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Erica Sadun
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Radosław Pietruszewski
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Goffredo Marocchi
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Ricardo Parada
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Erica Sadun
• [swift-evolution] [Draft] Expanded min/max algorithms   Matthew Johnson
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Tony Allevato
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Brent Royal-Gordon
• [swift-evolution] [META] Fast Track Reviews   Les Pruszynski
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Dennis Weissmann
• [swift-evolution] [Pitch] Extend Any.Type to allow construction of bound generic types   Douglas Gregor
• [swift-evolution] [Accepted] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly   Douglas Gregor
• [swift-evolution] [META] Fast Track Reviews   Brent Royal-Gordon
• [swift-evolution] swift-evolution Digest, Vol 5, Issue 35   Terrence Katzenbaer
• [swift-evolution] [Pitch] Unifying init parameters with properties   Haravikk
• [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices   Dave Abrahams
• [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices   Dave Abrahams
• [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices   Dave Abrahams
• [swift-evolution] [SR-933] Rename flatten to flattened   Dave Abrahams
• [swift-evolution] [Proposal draft] Enhanced floating-point protocols   Dave Abrahams
• [swift-evolution] [Proposal draft] Enhanced floating-point protocols   Dave Abrahams
• [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements   Douglas Gregor
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Dave Abrahams
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Dave Abrahams
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Brent Royal-Gordon
• [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices   Howard Lovatt
• [swift-evolution] [Proposal draft] Enhanced floating-point protocols   davesweeris at mac.com
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Dave Abrahams
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Dave Abrahams
• [swift-evolution] [Proposal draft] Enhanced floating-point protocols   Howard Lovatt
• [swift-evolution] [Proposal draft] Enhanced floating-point protocols   davesweeris at mac.com
• [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices   plx
• [swift-evolution] [Accepted] SE-0064: Referencing the Objective-C selector of property getters and setters   Robert Schwalbe
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Justin Jia
• [swift-evolution] [Proposal draft] Enhanced floating-point protocols   Howard Lovatt
• [swift-evolution] [Accepted] SE-0064: Referencing the Objective-C selector of property getters and setters   Douglas Gregor
• [swift-evolution] NSDate as struct in Swift Foundation (swift 3)   Emanuel Andrada
• [swift-evolution] [META] Fast Track Reviews   Douglas Gregor
• [swift-evolution] [Proposal] Remove behavior on AnyObject that allows any obj-c method to be called on it   Joe Pamer
• [swift-evolution] [Proposal] Remove behavior on AnyObject that allows any obj-c method to be called on it   Charles Srstka
• [swift-evolution] [Pitch] Fully eliminate implicit bridging conversions in Swift 3   Joe Pamer
• [swift-evolution] [Proposal] Remove behavior on AnyObject that allows any obj-c method to be called on it   Chris Lattner
• [swift-evolution] [Pitch] Fully eliminate implicit bridging conversions in Swift 3   Jacob Bandes-Storch
• [swift-evolution] [Proposal draft] Enhanced floating-point protocols   Greg Parker
• [swift-evolution] [Proposal draft] Enhanced floating-point protocols   Greg Parker
• [swift-evolution] NSDate as struct in Swift Foundation (swift 3)   Vladimir.S
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Haravikk
• [swift-evolution] [Pitch] Unifying init parameters with properties   Vladimir.S
• [swift-evolution] [Accepted] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly   Vladimir.S
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Radosław Pietruszewski
• [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices   Thorsten Seitz
• [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices   Thorsten Seitz
• [swift-evolution] Feature proposal: Range operator with step   Thorsten Seitz
• [swift-evolution] What about a VBA style with Statement?   Thorsten Seitz
• [swift-evolution] What about a VBA style with Statement?   Thorsten Seitz
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Thorsten Seitz
• [swift-evolution] [SR-933] Rename flatten to flattened   Thorsten Seitz
• [swift-evolution] [SR-933] Rename flatten to flattened   Brent Royal-Gordon
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Thorsten Seitz
• [swift-evolution] [Proposal draft] Enhanced floating-point protocols   Thorsten Seitz
• [swift-evolution] [SR-933] Rename flatten to flattened   Haravikk
• [swift-evolution] [Pitch] Fully eliminate implicit bridging conversions in Swift 3   Vladimir.S
• [swift-evolution] [Pitch] Fully eliminate implicit bridging conversions in Swift 3   Haravikk
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Matthew Johnson
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   T.J. Usiyan
• [swift-evolution] [Pitch] Fully eliminate implicit bridging conversions in Swift 3   T.J. Usiyan
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Vladimir.S
• [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges   Thorsten Seitz
• [swift-evolution] [SR-933] Rename flatten to flattened   Patrick Smith
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Patrick Smith
• [swift-evolution] [Pitch] Fully eliminate implicit bridging conversions in Swift 3   Greg Parker
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Vladimir.S
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Alan Skipp
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Erica Sadun
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Sean Heber
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   David Rönnqvist
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Alan Skipp
• [swift-evolution] [Pitch] Fully eliminate implicit bridging conversions in Swift 3   Антон Жилин
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   David Owens II
• [swift-evolution] [SR-933] Rename flatten to flattened   Brent Royal-Gordon
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Erica Sadun
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Brent Royal-Gordon
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Jeremy Pereira
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Gwendal Roué
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Jeremy Pereira
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Vladimir.S
• [swift-evolution] [Pitch] Fully eliminate implicit bridging conversions in Swift 3   Joe Pamer
• [swift-evolution] [SR-933] Rename flatten to flattened   Vladimir.S
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Haravikk
• [swift-evolution] [SR-933] Rename flatten to flattened   Haravikk
• [swift-evolution] [Draft] Expanded min/max algorithms   Dave Abrahams
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   David Owens II
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Michael Peternell
• [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices   Dave Abrahams
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Michael Peternell
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Matthew Johnson
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Justin Jia
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Justin Jia
• [swift-evolution] [Draft] Expanded min/max algorithms   Vladimir.S
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Haravikk
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Sean Heber
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Sean Heber
• [swift-evolution] [Review] SE-0067: Enhanced Floating Point Protocols   Chris Lattner
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Thorsten Seitz
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Thorsten Seitz
• [swift-evolution] [Review] SE-0067: Enhanced Floating Point Protocols   Daniel Vollmer
• [swift-evolution] [Idea] Replace enumerate() with something more explicit   Dave Abrahams
• [swift-evolution] [Idea] Replace enumerate() with something more explicit   Dave Abrahams
• [swift-evolution] [Idea] Replace enumerate() with something more explicit   Dave Abrahams
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Dave Abrahams
• [swift-evolution] [Review] SE-0067: Enhanced Floating Point Protocols   Xiaodi Wu
• [swift-evolution] [META] Fast Track Reviews   Erica Sadun
• [swift-evolution] [Draft] Expanded min/max algorithms   Dave Abrahams
• [swift-evolution] [SR-933] Rename flatten to flattened   Dave Abrahams
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Ricardo Parada
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Jacob Bandes-Storch
• [swift-evolution] [Draft] Expanded min/max algorithms   Karl
• [swift-evolution] [Draft] Expanded min/max algorithms   Karl Wagner
• [swift-evolution] [Review] SE-0067: Enhanced Floating Point Protocols   Howard Lovatt
• [swift-evolution] [Review] SE-0067: Enhanced Floating Point Protocols   Tim Hawkins
• [swift-evolution] [Draft] Expanded min/max algorithms   Dave Abrahams
• [swift-evolution] [Review] SE-0067: Enhanced Floating Point Protocols   davesweeris at mac.com
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Paul Ossenbruggen
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Vladimir.S
• [swift-evolution] [SR-933] Rename flatten to flattened   Vladimir.S
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Vladimir.S
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Vladimir.S
• [swift-evolution] [Draft] Expanded min/max algorithms   Brent Royal-Gordon
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Jeremy Pereira
• [swift-evolution] [Review] SE-0067: Enhanced Floating Point Protocols   Stephen Canon
• [swift-evolution] [Review] SE-0067: Enhanced Floating Point Protocols   Stephen Canon
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Jeremy Pereira
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Jeremy Pereira
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Jeremy Pereira
• [swift-evolution] [Review] SE-0067: Enhanced Floating Point Protocols   Pelaia II, Tom
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Haravikk
• [swift-evolution] [Discussion] Enforce argument labels on tuples   Adrian Zubarev
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Erica Sadun
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Tino Heth
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Alan Skipp
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Dave DeLong
• [swift-evolution] [Pitch] Extend Any.Type to allow construction of bound generic types   Joanna Carter
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   BJ Homer
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   BJ Homer
• [swift-evolution] [Discussion] Enforce argument labels on tuples   Adrian Zubarev
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Dennis Weissmann
• [swift-evolution] [Review] SE-0067: Enhanced Floating Point Protocols   Xiaodi Wu
• [swift-evolution] [Pitch] Extend Any.Type to allow construction of bound generic types   Developer
• [swift-evolution] [Review] SE-0067: Enhanced Floating Point Protocols   Stephen Canon
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Erica Sadun
• [swift-evolution] [Review] SE-0068: Expanding Swift Self to class members and value types   Chris Lattner
• [swift-evolution] [Review] SE-0067: Enhanced Floating Point Protocols   Xiaodi Wu
• [swift-evolution] [Pitch] Extend Any.Type to allow construction of bound generic types   Douglas Gregor
• [swift-evolution] [Review] SE-0068: Expanding Swift Self to class members and value types   Pelaia II, Tom
• [swift-evolution] [Review] SE-0068: Expanding Swift Self to class members and value types   Tino Heth
• [swift-evolution] [Discussion] Enforce argument labels on tuples   Tino Heth
• [swift-evolution] [SR-933] Rename flatten to flattened   Dave Abrahams
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Chris Lattner
• [swift-evolution] [Discussion] Enforce argument labels on tuples   Austin Zheng
• [swift-evolution] [Discussion] Enforce argument labels on tuples   Adrian Zubarev
• [swift-evolution] [Proposal draft] Enhanced floating-point protocols   Dave Abrahams
• [swift-evolution] [Discussion] Enforce argument labels on tuples   Adrian Zubarev
• [swift-evolution] [Discussion] Enforce argument labels on tuples   William Dillon
• [swift-evolution] [Discussion] Enforce argument labels on tuples   Austin Zheng
• [swift-evolution] [Discussion] Enforce argument labels on tuples   Haravikk
• [swift-evolution] [Proposal draft] Enhanced floating-point protocols   Dave Abrahams
• [swift-evolution] [Discussion] Enforce argument labels on tuples   Adrian Zubarev
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Dave Abrahams
• [swift-evolution] [Pitch] Extend Any.Type to allow construction of bound generic types   Dave Abrahams
• [swift-evolution] [Review] SE-0068: Expanding Swift Self to class members and value types   Dave Abrahams
• [swift-evolution] [Discussion] Enforce argument labels on tuples   Tino Heth
• [swift-evolution] [Discussion] Enforce argument labels on tuples   David Owens II
• [swift-evolution] [Review] SE-0067: Enhanced Floating Point Protocols   Dave Abrahams
• [swift-evolution] [Review] SE-0067: Enhanced Floating Point Protocols   Dave Abrahams
• [swift-evolution] [Review] SE-0067: Enhanced Floating Point Protocols   Xiaodi Wu
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Dave Abrahams
• [swift-evolution] [Review] SE-0067: Enhanced Floating Point Protocols   Stephen Canon
• [swift-evolution] [Review] SE-0067: Enhanced Floating Point Protocols   Dave Abrahams
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Slava Pestov
• [swift-evolution] [Review] SE-0068: Expanding Swift Self to class members and value types   Erica Sadun
• [swift-evolution] [Review] SE-0067: Enhanced Floating Point Protocols   plx
• [swift-evolution] [Review] SE-0067: Enhanced Floating Point Protocols   Xiaodi Wu
• [swift-evolution] [Review] SE-0067: Enhanced Floating Point Protocols   Xiaodi Wu
• [swift-evolution] [Proposal draft] Enhanced floating-point protocols   davesweeris at mac.com
• [swift-evolution] [Discussion] Enforce argument labels on tuples   davesweeris at mac.com
• [swift-evolution] [Pitch] Extend Any.Type to allow construction of bound generic types   Patrick Smith
• [swift-evolution] Extensions to add observers   Cody Weaver
• [swift-evolution] [Review] SE-0068: Expanding Swift Self to class members and value types   Chris Lattner
• [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices   Chris Lattner
• [swift-evolution] [Discussion] Enforce argument labels on tuples   Chris Lattner
• [swift-evolution] [Review] SE-0068: Expanding Swift Self to class members and value types   Ergin Bilgin
• [swift-evolution] [Review] SE-0068: Expanding Swift Self to class members and value types   Charles Srstka
• [swift-evolution] [Review] SE-0068: Expanding Swift Self to class members and value types   Brent Royal-Gordon
• [swift-evolution] [Review] SE-0068: Expanding Swift Self to class members and value types   Timothy Wood
• [swift-evolution] [Accepted] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly   Douglas Gregor
• [swift-evolution] [Rejected] SE-0056: Allow trailing closures in `guard` conditions   Douglas Gregor
• [swift-evolution] [Review] SE-0068: Expanding Swift Self to class members and value types   L Mihalkovic
• [swift-evolution] [Discussion] Enforce argument labels on tuples   David Owens II
• [swift-evolution] [Review] SE-0068: Expanding Swift Self to class members and value types   Goffredo Marocchi
• [swift-evolution] [Review] SE-0068: Expanding Swift Self to class members and value types   Vladimir.S
• [swift-evolution] [SR-933] Rename flatten to flattened   Vladimir.S
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Vladimir.S
• [swift-evolution] [Discussion] Enforce argument labels on tuples   Haravikk
• [swift-evolution] [Review] SE-0068: Expanding Swift Self to class members and value types   Vladimir.S
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Vladimir.S
• [swift-evolution] [Review] SE-0068: Expanding Swift Self to class members and value types   Vladimir.S
• [swift-evolution] Localization support for string interpolation   Daniel Höpfl
• [swift-evolution] [swift-evolution-announce] [Review] SE-0068: Expanding Swift Self to class members and value types   Sebastian Hagedorn
• [swift-evolution] String(validatingUTF8:) doesn't   Drew Crawford
• [swift-evolution] [Discussion] Enforce argument labels on tuples   Adrian Zubarev
• [swift-evolution] Localization support for string interpolation   Daniel Höpfl
• [swift-evolution] [Draft] Mixins   Niall Young
• [swift-evolution] [Draft] Mixins   Tim Hawkins
• [swift-evolution] String(validatingUTF8:) doesn't   Vladimir.S
• [swift-evolution] Localization support for string interpolation   Adrian Zubarev
• [swift-evolution] Lazy var and deinit   Alexandr.moq
• [swift-evolution] String(validatingUTF8:) doesn't   Drew Crawford
• [swift-evolution] Localization support for string interpolation   Uli Kusterer
• [swift-evolution] Lazy var and deinit   Vladimir.S
• [swift-evolution] [Draft] Mixins   James Froggatt
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Jeremy Pereira
• [swift-evolution] [Review] SE-0068: Expanding Swift Self to class members and value types   Jeremy Pereira
• [swift-evolution] [Review] SE-0068: Expanding Swift Self to class members and value types   Pelaia II, Tom
• [swift-evolution] [Review] SE-0068: Expanding Swift Self to class members and value types   Tal Atlas
• [swift-evolution] [Draft] Mixins   Tal Atlas
• [swift-evolution] [Review] SE-0068: Expanding Swift Self to class members and value types   Jeremy Pereira
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Jeremy Pereira
• [swift-evolution] [Proposal draft] Enhanced floating-point protocols   Thorsten Seitz
• [swift-evolution] Lazy var and deinit   Vladimir.S
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Jeremy Pereira
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Jeremy Pereira
• [swift-evolution] Localization support for string interpolation   Daniel Höpfl
• [swift-evolution] [Review] SE-0068: Expanding Swift Self to class members and value types   Erica Sadun
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Patrick Smith
• [swift-evolution] Localization support for string interpolation   Daniel Höpfl
• [swift-evolution] [SR-933] Rename flatten to flattened   David Waite
• [swift-evolution] [Draft] Mixins   David Waite
• [swift-evolution] [Draft] Mixins   Wallacy
• [swift-evolution] Notes from Swift core team 2016-04-20 design discussion   Alex Martini
• [swift-evolution] [swift-dev] Lazy var and deinit   John McCall
• [swift-evolution] Localization support for string interpolation   Uli Kusterer
• [swift-evolution] mutating/non-mutating suggestion from a Rubyist   Daniel Steinberg
• [swift-evolution] Notes from Swift core team 2016-04-20 design discussion   Vladimir.S
• [swift-evolution] [Review] SE-0068: Expanding Swift Self to class members and value types   Erica Sadun
• [swift-evolution] [Proposal draft] Enhanced floating-point protocols   Dave Abrahams
• [swift-evolution] [Idea] Passing an Array to Variadic Functions   Dave Abrahams
• [swift-evolution] [Draft Proposal for pre discussion]NS_ENUM's should be considered Open   Joseph Lord
• [swift-evolution] [Proposal draft] Enhanced floating-point protocols   Thorsten Seitz
• [swift-evolution] [Accepted, pending implementation] SE-0054: Abolish ImplicitlyUnwrappedOptional type   Chris Willmore
• [swift-evolution] [Proposal draft] Enhanced floating-point protocols   Dave Abrahams
• [swift-evolution] [Draft] Mixins   Niall Young
• [swift-evolution] [Accepted, pending implementation] SE-0054: Abolish ImplicitlyUnwrappedOptional type   Dave Abrahams
• [swift-evolution] [Draft] Mixins   Niall Young
• [swift-evolution] Notes from Swift core team 2016-04-20 design discussion   David Waite
• [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols   Jordan Rose
• [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols   James Berry
• [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols   Jordan Rose
• [swift-evolution] [Accepted] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly   Vladimir.S
• [swift-evolution] mutating/non-mutating suggestion from a Rubyist   Krishna Kumar
• [swift-evolution] mutating/non-mutating suggestion from a Rubyist   Tyler Cloutier
• [swift-evolution] Localization support for string interpolation   Daniel Höpfl
• [swift-evolution] mutating/non-mutating suggestion from a Rubyist   Tyler Cloutier
• [swift-evolution] [Discussion] "with" statement/method   Vladimir.S
• [swift-evolution] [Draft] Mixins   Антон Жилин
• [swift-evolution] [Draft] Mixins   Антон Жилин
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Антон Жилин
• [swift-evolution] [Discussion] "with" statement/method   Patrick Smith
• [swift-evolution] mutating/non-mutating suggestion from a Rubyist   Daniel Steinberg
• [swift-evolution] [Discussion] "with" statement/method   Vladimir.S
• [swift-evolution] mutating/non-mutating suggestion from a Rubyist   Haravikk
• [swift-evolution] mutating/non-mutating suggestion from a Rubyist   Haravikk
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Vladimir.S
• [swift-evolution] [Review] SE-0067: Enhanced Floating Point Protocols   Dany St-Amant
• [swift-evolution] mutating/non-mutating suggestion from a Rubyist   Vladimir.S
• [swift-evolution] [Discussion] "with" statement/method   Joanna Carter
• [swift-evolution] mutating/non-mutating suggestion from a Rubyist   Haravikk
• [swift-evolution] mutating/non-mutating suggestion from a Rubyist   James Campbell
• [swift-evolution] [Proposal] Safer half-open range operator   Luis Henrique B. Sousa
• [swift-evolution] mutating/non-mutating suggestion from a Rubyist   Patrick Smith
• [swift-evolution] [Discussion] "with" statement/method   Vladimir.S
• [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols   Stephen Canon
• [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols   Xiaodi Wu
• [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols   Stephen Canon
• [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols   Xiaodi Wu
• [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols   Xiaodi Wu
• [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols   Xiaodi Wu
• [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols   Stephen Canon
• [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols   Xiaodi Wu
• [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols   David Sweeris
• [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols   Stephen Canon
• [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols   Stephen Canon
• [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols   Xiaodi Wu
• [swift-evolution] Notes from Swift core team 2016-04-20 design discussion   Thorsten Seitz
• [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols   Stephen Canon
• [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols   Xiaodi Wu
• [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols   Xiaodi Wu
• [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols   Stephen Canon
• [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols   Stephen Canon
• [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols   Dave Abrahams
• [swift-evolution] [Proposal] Safer half-open range operator   Dave Abrahams
• [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols   Stephen Canon
• [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols   Rob Mayoff
• [swift-evolution] multi-line string literals.   John Holdsworth
• [swift-evolution] Notes from Swift core team 2016-04-20 design discussion   David Waite
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Антон Жилин
• [swift-evolution] Mutability for Foundation types in Swift   Tony Parker
• [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols   David Waite
• [swift-evolution] [Proposal] Safer half-open range operator   Vladimir.S
• [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols   Xiaodi Wu
• [swift-evolution] Mutability for Foundation types in Swift   Sean Heber
• [swift-evolution] [Review] SE-0061: Add Generic Result and Error Handling to autoreleasepool()   Dave Abrahams
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Vladimir.S
• [swift-evolution] Mutability for Foundation types in Swift   Vladimir.S
• [swift-evolution] multi-line string literals.   Patrick Gili
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Erica Sadun
• [swift-evolution] Mutability for Foundation types in Swift   Dave Abrahams
• [swift-evolution] [Review] SE-0061: Add Generic Result and Error Handling to autoreleasepool()   Jacob Bandes-Storch
• [swift-evolution] multi-line string literals.   John Holdsworth
• [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols   Dave Abrahams
• [swift-evolution] [Review] SE-0061: Add Generic Result and Error Handling to autoreleasepool()   Michael Peternell
• [swift-evolution] Mutability for Foundation types in Swift   Nate Cook
• [swift-evolution] multi-line string literals.   Kurt Werle
• [swift-evolution] [Idea] custom infix functions   Adrian Zubarev
• [swift-evolution] Mutability for Foundation types in Swift   David Waite
• [swift-evolution] [Idea] custom infix functions   Adrian Zubarev
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   L. Mihalkovic
• [swift-evolution] Mutability for Foundation types in Swift   Tony Parker
• [swift-evolution] [idea] Make functions with @noescape syntax behave like control structures   Michael Peternell
• [swift-evolution] mutating/non-mutating suggestion from a Rubyist   T.J. Usiyan
• [swift-evolution] Mutability for Foundation types in Swift   Tony Parker
• [swift-evolution] multi-line string literals.   Patrick Gili
• [swift-evolution] [Idea] custom infix functions   Vladimir.S
• [swift-evolution] [Idea] custom infix functions   Adrian Zubarev
• [swift-evolution] Notes from Swift core team 2016-04-20 design discussion   Shawn Erickson
• [swift-evolution] Mutability for Foundation types in Swift   Riley Testut
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Vladimir.S
• [swift-evolution] [Idea] custom infix functions   Adrian Zubarev
• [swift-evolution] [Idea] custom infix functions   Vladimir.S
• [swift-evolution] Mutability for Foundation types in Swift   plx
• [swift-evolution] Mutability for Foundation types in Swift   Philippe Hausler
• [swift-evolution] Mutability for Foundation types in Swift   Tony Parker
• [swift-evolution] mutating/non-mutating suggestion from a Rubyist   Dave Abrahams
• [swift-evolution] Mutability for Foundation types in Swift   Charles Srstka
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Антон Жилин
• [swift-evolution] Mutability for Foundation types in Swift   Jose Cheyo Jimenez
• [swift-evolution] Mutability for Foundation types in Swift   Tony Parker
• [swift-evolution] Mutability for Foundation types in Swift   Greg Parker
• [swift-evolution] Mutability for Foundation types in Swift   Philippe Hausler
• [swift-evolution] Mutability for Foundation types in Swift   Michael Buckley
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Vladimir.S
• [swift-evolution] [META] Fast Track Reviews   Douglas Gregor
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Alan Skipp
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Vladimir.S
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Vladimir.S
• [swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only   Douglas Gregor
• [swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only   Xiaodi Wu
• [swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only   Xiaodi Wu
• [swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only   Duan
• [swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only   Douglas Gregor
• [swift-evolution] multi-line string literals.   John Holdsworth
• [swift-evolution] Mutability for Foundation types in Swift   Charles Srstka
• [swift-evolution] ValueEnumerable protocol with derived implementation for enums   Jacob Bandes-Storch
• [swift-evolution] Mutability for Foundation types in Swift   David Smith
• [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access   Brent Royal-Gordon
• [swift-evolution] mutating/non-mutating suggestion from a Rubyist   Daniel Steinberg
• [swift-evolution] ValueEnumerable protocol with derived implementation for enums   Jacob Bandes-Storch
• [swift-evolution] ValueEnumerable protocol with derived implementation for enums   John McCall
• [swift-evolution] ValueEnumerable protocol with derived implementation for enums   Jacob Bandes-Storch
• [swift-evolution] ValueEnumerable protocol with derived implementation for enums   John McCall
• [swift-evolution] ValueEnumerable protocol with derived implementation for enums   Jacob Bandes-Storch
• [swift-evolution] [Idea] implicit protocols and type oriented protocols   Adrian Zubarev
• [swift-evolution] mutating/non-mutating suggestion from a Rubyist   Pyry Jahkola
• [swift-evolution] [Proposal] Safer half-open range operator   Luis Henrique B. Sousa
• [swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only   Michael Peternell
• [swift-evolution] Guaranteed closure execution   Gwendal Roué
• [swift-evolution] SR-1246: Inconsistent naming and declaration of String & NSString derivative properties and functions   Gwendal Roué
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Антон Жилин
• [swift-evolution] Overriding computed properties with let constants?   Roman Zhikharevich
• [swift-evolution] [Discussion] "with" statement/method   Thorsten Seitz
• [swift-evolution] Guaranteed closure execution   Michael Peternell
• [swift-evolution] Improvement proposal: change overflow behavior in successor()/predecessor() methods for Int types   Haravikk
• [swift-evolution] Guaranteed closure execution   Gwendal Roué
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Haravikk
• [swift-evolution] Guaranteed closure execution   Andrew Bennett
• [swift-evolution] Properties with parameters   Tim Vermeulen
• [swift-evolution] Guaranteed closure execution   michael.peternell at gmx.at
• [swift-evolution] Guaranteed closure execution   Gwendal Roué
• [swift-evolution] Guaranteed closure execution   Timothy Wood
• [swift-evolution] Guaranteed closure execution   Timothy Wood
• [swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only   Xiaodi Wu
• [swift-evolution] multi-line string literals.   Patrick Gili
• [swift-evolution] Properties with parameters   Ben Rimmington
• [swift-evolution] [Review] SE-0061: Add Generic Result and Error Handling to autoreleasepool()   Ben Rimmington
• [swift-evolution] Overriding computed properties with let constants?   Adrian Zubarev
• [swift-evolution] Notes from Swift core team 2016-04-20 design discussion   Thorsten Seitz
• [swift-evolution] Overriding computed properties with let constants?   David Sweeris
• [swift-evolution] ValueEnumerable protocol with derived implementation for enums   John McCall
• [swift-evolution] Overriding computed properties with let constants?   Haravikk
• [swift-evolution] multi-line string literals.   Brent Royal-Gordon
• [swift-evolution] Overriding computed properties with let constants?   David Sweeris
• [swift-evolution] multi-line string literals.   Michael Peternell
• [swift-evolution] ValueEnumerable protocol with derived implementation for enums   Howard Lovatt
• [swift-evolution] Carriage Return in Collection Array Literal Initializer   Ivan Oparin
• [swift-evolution] Guaranteed closure execution   Gwendal Roué
• [swift-evolution] multi-line string literals.   Brent Royal-Gordon
• [swift-evolution] [Idea] Repurpose Void   Антон Жилин
• [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols   Brent Royal-Gordon
• [swift-evolution] [Idea] Bringing the partial/total ordering distinction into Comparable   Brent Royal-Gordon
• [swift-evolution] multi-line string literals.   Howard Lovatt
• [swift-evolution] [Proposal] Safer half-open range operator   Vladimir.S
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Chris Eidhof
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Vladimir.S
• [swift-evolution] mutating/non-mutating suggestion from a Rubyist   James Froggatt
• [swift-evolution] [Proposal] Safer half-open range operator   Luis Henrique B. Sousa
• [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols   Nicola Salmoria
• [swift-evolution] [Idea] Bringing the partial/total ordering distinction into Comparable   Haravikk
• [swift-evolution] Mutability for Foundation types in Swift   Brent Royal-Gordon
• [swift-evolution] mutating/non-mutating suggestion from a Rubyist   Patrick Smith
• [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols   Rainer Brockerhoff
• [swift-evolution] multi-line string literals.   John Holdsworth
• [swift-evolution] mutating/non-mutating suggestion from a Rubyist   Tim Vermeulen
• [swift-evolution] Properties with parameters   Tim Vermeulen
• [swift-evolution] mutating/non-mutating suggestion from a Rubyist   James Froggatt
• [swift-evolution] mutating/non-mutating suggestion from a Rubyist   Tim Vermeulen
• [swift-evolution] mutating/non-mutating suggestion from a Rubyist   Xiaodi Wu
• [swift-evolution] [Idea] Bringing the partial/total ordering distinction into Comparable   Xiaodi Wu
• [swift-evolution] Guaranteed closure execution   Gwendal Roué
• [swift-evolution] [Idea] Bringing the partial/total ordering distinction into Comparable   Haravikk
• [swift-evolution] [Proposal] More Powerful Constraints for Associated Types   David Hart
• [swift-evolution] [Idea] Bringing the partial/total ordering distinction into Comparable   Brent Royal-Gordon
• [swift-evolution] [Idea] Bringing the partial/total ordering distinction into Comparable   Chris Lattner
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Chris Lattner
• [swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only   Chris Lattner
• [swift-evolution] Localization support for string interpolation   Chris Lattner
• [swift-evolution] Carriage Return in Collection Array Literal Initializer   Ross O'Brien
• [swift-evolution] Localization support for string interpolation   Chris Lattner
• [swift-evolution] [Accepted, pending implementation] SE-0054: Abolish ImplicitlyUnwrappedOptional type   Chris Lattner
• [swift-evolution] [Idea] Bringing the partial/total ordering distinction into Comparable   Brent Royal-Gordon
• [swift-evolution] [Discussion] Enforce argument labels on tuples   Chris Lattner
• [swift-evolution] multi-line string literals.   Ted F.A. van Gaalen
• [swift-evolution] multi-line string literals.   John Holdsworth
• [swift-evolution] Guaranteed closure execution   Chris Lattner
• [swift-evolution] [Idea] Bringing the partial/total ordering distinction into Comparable   Chris Lattner
• [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"   Chris Lattner
• [swift-evolution] [Idea] Bringing the partial/total ordering distinction into Comparable   Xiaodi Wu
• [swift-evolution] multi-line string literals.   Chris Lattner
• [swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only   Xiaodi Wu
• [swift-evolution] multi-line string literals.   Chris Lattner
• [swift-evolution] Rewrite imported C function signatures   Carlos Rodríguez Domínguez
• [swift-evolution] Mutability for Foundation types in Swift   Ben Rimmington
• [swift-evolution] multi-line string literals.   John Holdsworth
• [swift-evolution] [Idea] Repurpose Void   Brent Royal-Gordon
• [swift-evolution] [swift-evolution-announce] [Review] SE-0068: Expanding Swift Self to class members and value types   Brent Royal-Gordon
• [swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only   Erica Sadun
• [swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only   Douglas Gregor
• [swift-evolution] [Proposal] More Powerful Constraints for Associated Types   Rod Brown
• [swift-evolution] [swift-evolution-announce] [Review] SE-0068: Expanding Swift Self to class members and value types   Erica Sadun
• [swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only   Xiaodi Wu

Last message date: Sun Apr 24 22:04:49 CDT 2016
Archived on: Sun Apr 24 22:08:11 CDT 2016

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