[swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

[Jacob Bandes-Storch]

On Sat, Feb 18, 2017 at 8:49 PM, Dave Abrahams via swift-evolution <
swift-evolution at swift.org> wrote:

> I'm on vacation and don't have time for a full review right now, but I am
> concerned that wild this proposal would make enums more general and uniform
> with the rest of the language , they also would become much more awkward
> for common use cases. I have recently been very pleased that I didn't have
> to supply labels in switch statements where the label name would simply
> have matched the name of the variable to be bound.  This looks needlessly
> verbose:
>
>   case .valid(value: let value, resumptionPoint: let resumptionPoint):
>
> I cannot imagine a real life use case where one would have labels in the
> case and desire to bind associated values to variables having different
> names than the labels.
>

What about something like this? It's a bit contrived, but the point is you
could easily expect to work with more than one value of the same enum type
at the same time.

enum Color {
  case rgb(red: Double, green: Double, blue: Double)
  ...

  func interpolated(to other: Color, by fraction: Double) -> Color {
    switch (self, other) {
    case (.rgb(red: let red, blue: let blue, green: let green),
          .rgb(red: let otherRed, blue: let otherBlue, green: let
otherGreen)):
      return .rgb(
        red: lerp(from: red, to: otherRed, by: fraction),
        ...)
    ...
    }
  }
}


Your point, though, reminds me of ES6 destructuring assignment, e.g. "let
{red, green} = color", and inversely a syntax whose name I don't know, "let
color = {red, green}", which are indeed quite convenient when variable
names match object key names.



> Secondly, I can't imagine a case where one would want to use the same case
> basename and different labels. The very common use case where the types of
> associated values completely distinguish the case and one would rather not
> have to supply a case name at all is completely unaddressed. If my quick
> read is not mistaken, this proposal makes it legal for cases to have
> different *complete names* (including base name and labels), but doesn't
> make it legal to have the same full name (which I would love to be "_" or
> missing in some cases) with different associated value types. If we were
> truly following the precedent set by function signatures, wouldn't that be
> possible too?
>
> Sent from my moss-covered three-handled family gradunza
>
> On Feb 17, 2017, at 5:26 PM, John McCall <rjmccall at apple.com> 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/proposa
> ls/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
> 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
>
> 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
>
> Thank you,
>
> John McCall
> Review Manager
>
> _______________________________________________
> swift-evolution-announce mailing list
> swift-evolution-announce at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170219/f035d465/attachment.html>