> On Feb 20, 2017, at 12:31 PM, Christopher Kornher via swift-evolution
> <[email protected]> wrote:
>
>>
>> On Feb 18, 2017, at 6:16 AM, David Rönnqvist via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>> On 18 Feb 2017, at 09:30, Slava Pestov via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>>> +1, two small questions:
>>>
>>> - If two cases have the same base name but different full names, will
>>> matching on the base name match both cases, or will it be an error?
>>
>> I feel that it would be safer if it was an error. If the developer intends
>> to match both cases, requiring both explicitly is a (slight) inconvenience
>> but it's also very clear about what's going to match.
>
> I disagree. It is simple enough to use different base names if you don’t want
> the cases to match. An example of why it should not be an error: I intend to
> for errors with same base names to be handled in the same way and I don’t
> want to enumerate all the similar cases and change code every time I add a
> new way to construct an error. I understand that other people want the
> equivalent of function overloading. Code that needs to access values must
> deal with unique cases, so type safety is assured in any case.
>
> Java enums have arguments and match on “base names” (they are quite
> different, but the precedent exists) and I don’t think that matching on the
> base name would be confusing. I also do not believe that it is worth adding
> this feature if all cases are completely unique.The pain of forcing a
> (probably small) subset of developers to use unique names is preferable to
> complicating the language for no functional benefit, in my opinion.
A possible compromise: specify that all base names should be matched with a new
keyword (or?) Here the keyword ```all``` is used to match all base names.
```
enum MyError : Error
{
case e( a: String )
case e( a: Int )
}
func handleError( error: MyError )
{
switch error {
case all .e :
break
}
}
```
>
>
>>
>>> - What are the memory layout optimizations described here? From a first
>>> glance this looks purely syntactic.
>>>
>>> Slava
>>>
>>>> On Feb 17, 2017, at 7:26 PM, John McCall via swift-evolution
>>>> <[email protected] <mailto:[email protected]>> wrote:
>>>>
>>>> Hello Swift community,
>>>>
>>>> The review of "SE-0155: Normalize Enum Case Representation" begins now and
>>>> runs through next Friday, February 26th. The proposal is available here:
>>>>
>>>> https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md
>>>>
>>>> <https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md>
>>>>
>>>> Reviews are an important part of the Swift evolution process. All reviews
>>>> should be sent to the swift-evolution mailing list at
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> <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/0155-normalize-enum-case-representation.md
>>>>
>>>> <https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md>
>>>>
>>>> Reply text
>>>>
>>>> Other replies
>>>>
>>>> What goes into a review?
>>>>
>>>> The goal of the review process is to improve the proposal under review
>>>> through constructive criticism and, eventually, determine the direction of
>>>> Swift. When writing your review, here are some questions you might want to
>>>> answer in your review:
>>>>
>>>> • What is your evaluation of the proposal?
>>>> • Is the problem being addressed significant enough to warrant a change
>>>> to Swift?
>>>> • Does this proposal fit well with the feel and direction of Swift?
>>>> • If you have used other languages or libraries with a similar feature,
>>>> how do you feel that this proposal compares to those?
>>>> • How much effort did you put into your review? A glance, a quick
>>>> reading, or an in-depth study?
>>>>
>>>> More information about the Swift evolution process is available at
>>>> https://github.com/apple/swift-evolution/blob/master/process.md
>>>> <https://github.com/apple/swift-evolution/blob/master/process.md>
>>>>
>>>> Thank you,
>>>>
>>>> John McCall
>>>> Review Manager
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> [email protected] <mailto:[email protected]>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> [email protected] <mailto:[email protected]>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
