> On Dec 25, 2017, at 9:14 AM, Cheyo Jimenez via swift-evolution
> <[email protected]> wrote:
>
>
>
>> 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?
I would also expect case _ to only match known cases since _ acts like a wild
char.
switch x { // x is non-exhaustive here.
case _ : fatalError("compile time error when missing cases ") // known cases
at compile time
default: fatalError("runtime error when missing cases") // unknown cases.
}
It makes sense for default and case _ to do the same thing for exhaustive enums
but not for non exhaustive.
Could this be addressed in the proposal too? Thanks in advance.
>
>>>> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
