Re: [swift-evolution] extension of AnyObject

> On Dec 29, 2017, at 11:21 PM, Kenny Leung via swift-evolution > wrote: > > Hi All. > > I just discovered that you can’t write an extension on AnyObject. What’s the > reasoning behind this? > > I’m trying to write my own version of KeyValueObserving, and it would

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

> On Dec 31, 2017, at 1:21 PM, Cheyo Jimenez wrote: > > > > On Dec 31, 2017, at 8:59 AM, Ben Rimmington via swift-evolution > wrote: > >>> On 21 Dec 2017, at 03:32, John McCall wrote: >>> > On Dec 20, 2017, at 10:16 PM, Brent

Re: [swift-evolution] Happy new year Swift community.

Happy new year everybody :)! Sent from my iPhone > On 31 Dec 2017, at 23:43, David Hart via swift-evolution > wrote: > > Thank you very much and happy new Swift year to everybody. > >> On 1 Jan 2018, at 00:42, Adrian Zubarev via swift-evolution >>

Re: [swift-evolution] Happy new year Swift community.

Thank you very much and happy new Swift year to everybody. > On 1 Jan 2018, at 00:42, Adrian Zubarev via swift-evolution > wrote: > > Well some of you guys have to wait a little longer, but I can already wish > everyone a happy new year from Germany.  > > --

[swift-evolution] Happy new year Swift community.

Well some of you guys have to wait a little longer, but I can already wish everyone a happy new year from Germany.  -- Adrian Zubarev Sent with Airmail ___ swift-evolution mailing list swift-evolution@swift.org

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

I have been busy over the holidays and have been considering the arguments in this thread so my review is late in coming. > What is your evaluation of the proposal? > I agree that we need a solution to the problem described. I also agree that non-exhaustive is most in keeping with the overall

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

On Dec 31, 2017, at 8:59 AM, Ben Rimmington via swift-evolution wrote: >> On 21 Dec 2017, at 03:32, John McCall wrote: >> On Dec 20, 2017, at 10:16 PM, Brent Royal-Gordon wrote: On Dec 19, 2017, at 2:58 PM, Ted Kremenek wrote: • What

Re: [swift-evolution] [swift-dev] Re-pitch: Deriving collections of enum cases

> On 31. Dec 2017, at 00:12, Jacob Bandes-Storch via swift-evolution > wrote: > > Sorry for the delay. I've just updated the proposal text to incorporate > various changes, some contributed by others. > >

Re: [swift-evolution] [swift-dev] Re-pitch: Deriving collections of enum cases

In addition to what Chris said: enums imported from C and @objc enums can both have extensions and conform to protocols, so IMO it should be legal to write something like `extension Foundation.ComparisonResult: ValueEnumerable {}`. Félix > Le 30 déc. 2017 à 19:00, Jacob Bandes-Storch via

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

> On 21 Dec 2017, at 03:32, John McCall wrote: > >> On Dec 20, 2017, at 10:16 PM, Brent Royal-Gordon wrote: >> >>> On Dec 19, 2017, at 2:58 PM, Ted Kremenek wrote: >>> >>> • What is your evaluation of the proposal? >> >> I am pleased with the broad strokes of this design. I have quibbles

[swift-evolution] [Pre-Pitch] Another go at "strong typedef" / alternative types / reduced-state types

(Warning: rambling stream-of-conscious mode while slightly tired) The names of new keywords and identifiers are subject to bike-shedding. 1. Set-up Protocols protocol HardRawRepresentable: RawRepresentable { init(rawValue: RawValue) } Just like RawRepresentable, but the initializer has to