> On Dec 22, 2017, at 8:49 AM, Cheyo Jose Jimenez <[email protected]> wrote:
>
>
>
>> On Dec 20, 2017, at 11:12 PM, Cheyo Jimenez <[email protected]> wrote:
>>
>>
>>
>>> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution
>>> <[email protected]> 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 are an important part of the Swift evolution process. All review
>>> feedback should be sent to the swift-evolution mailing list at:
>>>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> or, if you would like to keep your feedback private, directly to the review
>>> manager.
>>>
>>> When replying, please try to keep the proposal link at the top of the
>>> message:
>>>
>>> Proposal link:
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md
>>> ...
>>> Reply text
>>> ...
>>> Other replies
>>> What goes into a review of a proposal?
>>>
>>> The goal of the review process is to improve the proposal under review
>>> through constructive criticism and, eventually, determine the direction of
>>> Swift.
>>>
>>> When reviewing a proposal, here are some questions to consider:
>>>
>>> What is your evaluation of the proposal?
>>>
>> +1 except for the name. @frozenExposed @fixedMembers @frozenMembers.
>> preferably something that aligns with the other notion of not being able to
>> add public members to structs. This will help treat structs with static
>> members in the same way which would be ideal. I don't think enums should
>> have their own attitude.
>>> Is the problem being addressed significant enough to warrant a change to
>>> Swift?
>>>
>> don't know. im not a library author. ill defer to other library authors.
>
> I want to revise my review here. While I am not a library author I am a
> library consumer.
>
> Having the ability treat a non exhaustive enum as exhaustive should be
> introduced with this. I like the idea of a
> `final switch`
>
> I think it communicate clearly that I want this to be treated as exhaustive
> even if it is already exhaustive. Having something like future, unknowns
> would be weird to me.
>
> Another option would be being able to cast a enum as exhaustive. I am not
> sure how that would work. I do not like switch!
Preferably I’d like to say:
switch (@exhaustive x){...}
Would this be allowed?
let @exhaustive myEnum= x
typealias @exhaustive Y = X
if let @exhaustive x = x {
switch x {...} // exhaustive here.
}
Could this be addressed in the proposal?
>>> Does this proposal fit well with the feel and direction of Swift?
>>>
>> yes.
>>> If you have used other languages or libraries with a similar feature, how
>>> do you feel that this proposal compares to those?
>>>
>> n/a
>>> How much effort did you put into your review? A glance, a quick reading, or
>>> an in-depth study?
>>>
>> followed the previous discussion. read the proposal.
>>> Thanks,
>>> Ted Kremenek
>>> Review Manager
>>> _______________________________________________
>>> swift-evolution mailing list
>>> [email protected]
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
