> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution
> wrote:
>
> The review of "SE 0192 - Non-Exhaustive Enums" begins now and runs through
> January 3, 2018.
>
> The proposal is available here:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive
> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution
> wrote:
> The review of "SE 0192 - Non-Exhaustive Enums" begins now and runs through
> January 3, 2018.The proposal is available here:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md
> On 21 Dec 2017, at 05:16, Brent Royal-Gordon via swift-evolution
> wrote:
>
>> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution
>> wrote:
>>
>> • What is your evaluation of the proposal?
>
> I am pleased with the broad strokes of this design. I have quibbles with
> thr
+1 on @frozen and John’s reasoning.
> On 21. Dec 2017, at 04:32, John McCall via swift-evolution
> wrote:
>
>>
>> On Dec 20, 2017, at 10:16 PM, Brent Royal-Gordon via swift-evolution
>> mailto:swift-evolution@swift.org>> wrote:
>>
>>> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evol
FWIW also +1 for @frozen
(and actually +1 for everything Brent said)
On 21.12.2017 14:28, Jonathan Hull via swift-evolution wrote:
+1 for @frozen
On Dec 20, 2017, at 7:16 PM, Brent Royal-Gordon via swift-evolution
wrote:
On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution
wrote
> On 20 Dec 2017, at 9:58 am, Ted Kremenek via swift-evolution
> wrote:
>
> The review of "SE 0192 - Non-Exhaustive Enums" begins now and runs through
> January 3, 2018.
>
> The proposal is available here:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive
+1 for @frozen
> On Dec 20, 2017, at 7:16 PM, Brent Royal-Gordon via swift-evolution
> wrote:
>
>> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution
>> wrote:
>>
>> • What is your evaluation of the proposal?
>
> I am pleased with the broad strokes of this design. I have qui
> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution
> wrote:
>
> The review of "SE 0192 - Non-Exhaustive Enums" begins now and runs through
> January 3, 2018.
>
> The proposal is available here:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhausti
> On Dec 20, 2017, at 10:16 PM, Brent Royal-Gordon via swift-evolution
> wrote:
>
>> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution
>> wrote:
>>
>> • What is your evaluation of the proposal?
>
> I am pleased with the broad strokes of this design. I have quibbles with
>
> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution
> wrote:
>
> • What is your evaluation of the proposal?
I am pleased with the broad strokes of this design. I have quibbles with three
areas:
1. The `@exhaustive` attribute may be confusing because the term doesn't
suggest
> On Dec 20, 2017, at 12:54 PM, Charlie Monroe via swift-evolution
> wrote:
>
> the choice to make them non-exhaustive by default is not in line with
> everything else in Swift - everything else is generally closed by default -
> public (-> final in other modules), no access modified (-> inter
I think that the main confusion here stems from the word library as we are
addressing something that can be divided further (and this is IMHO as many
macOS/iOS devs see it):
- libraries that come with the OS - here, it absolutely makes sense to make the
enums non-exhaustive as the apps are link
> On Dec 20, 2017, at 1:36 PM, Jordan Rose wrote:
>
> Thanks for the links, Colin. I think neither of these approaches are
> appropriate for Swift, largely for the same reason: they can't be used to
> define a library's API. Polymorphic variants are ad-hoc union types (much
> like tuples are
> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution
> wrote:
> When reviewing a proposal, here are some questions to consider:
>
> What is your evaluation of the proposal?
>
Strong -1 as is.
I think I would support having an explicit ‘futureCase’ which is different from
‘default’
> On 20. Dec 2017, at 19:54, Jordan Rose wrote:
>
>
>
>> On Dec 20, 2017, at 05:36, Karl Wagner via swift-evolution
>> mailto:swift-evolution@swift.org>> wrote:
>>
>>
>>
>>> On 19. Dec 2017, at 23:58, Ted Kremenek via swift-evolution
>>> mailto:swift-evolution@swift.org>> wrote:
>>>
>>>
Proposal link:
https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md
What is your evaluation of the proposal?
-1.
Is the problem being addressed significant enough to warrant a change to Swift?
I’m afraid not.
>From my perspective as a Swift user, this ch
Thanks for the feedback, Dave! Responses inline.
> On Dec 20, 2017, at 09:23, Dave DeLong via swift-evolution
> wrote:
>
>
>
>> On Dec 19, 2017, at 3:58 PM, Ted Kremenek via swift-evolution
>> mailto:swift-evolution@swift.org>> wrote:
>>
>> The review of "SE 0192 - Non-Exhaustive Enums" beg
> On Dec 20, 2017, at 05:36, Karl Wagner via swift-evolution
> wrote:
>
>
>
>> On 19. Dec 2017, at 23:58, Ted Kremenek via swift-evolution
>> mailto:swift-evolution@swift.org>> wrote:
>>
>> The review of "SE 0192 - Non-Exhaustive Enums" begins now and runs through
>> January 3, 2018.
>>
Thanks for the links, Colin. I think neither of these approaches are
appropriate for Swift, largely for the same reason: they can't be used to
define a library's API. Polymorphic variants are ad-hoc union types (much like
tuples are ad-hoc structs) which—apart from having other problems in Swift
I very much agree with the motivations for this proposal. It identifies a
clear, urgent need.
I disagree that the proposed solution is a good solution. It makes a very
significant, and confusing, change to the language that does not have much
precedent in other languages. This goes against the
> On Dec 19, 2017, at 3:58 PM, Ted Kremenek via swift-evolution
> wrote:
>
> The review of "SE 0192 - Non-Exhaustive Enums" begins now and runs through
> January 3, 2018.
>
> The proposal is available here:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhausti
On 20.12.2017 1:58, Ted Kremenek via swift-evolution wrote:
The review of "SE 0192 - Non-Exhaustive Enums" begins now and runs through
*January 3, 2018*.
The proposal is available here:
https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md
Reviews ar
> On 20. Dec 2017, at 14:36, Karl Wagner wrote:
>
>
>
>> On 19. Dec 2017, at 23:58, Ted Kremenek via swift-evolution
>> mailto:swift-evolution@swift.org>> wrote:
>>
>> The review of "SE 0192 - Non-Exhaustive Enums" begins now and runs through
>> January 3, 2018.
>>
>> The proposal is avai
> On 19. Dec 2017, at 23:58, Ted Kremenek via swift-evolution
> wrote:
>
> The review of "SE 0192 - Non-Exhaustive Enums" begins now and runs through
> January 3, 2018.
>
> The proposal is available here:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive
>
> What is your evaluation of the proposal?
>
>
+1 it solves an important problem in our ecosystem.
> Is the problem being addressed significant enough to warrant a change to
> Swift?
>
>
Yes
> Does this proposal fit well with the feel and direction of Swift?
>
>
This is weird because I f
101 - 125 of 125 matches
Mail list logo
