[Review] SE-0155: Normalize Enum Case Representation


(John McCall) #1

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

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


(Slava Pestov) #2

+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?
- 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 <swift-evolution@swift.org> 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

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 mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Brent Royal-Gordon) #3

  Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md

  • What is your evaluation of the proposal?

I'm torn. Being able to handle the associated value as a tuple is very convenient, but I also want the argument list features described here. In practice, my own enums tend to end up using argument-like parameter labels, which works better when constructing and pattern-matching, but worse when extracting values.

I think I'd like to ask for two changes. One is probably easy; the other is a bit of a stretch.

Easy: Cases should allow internal names for documentation and autocompletion.

  enum SQLError: Error {
    …
    case valueInvalid(_ underlying: Error, for key: SQLColumnKey, in statement: SQLStatement)
    …
  }
  …
  throw SQLError.valueInvalid(error, for: key, in: statement)
  …
  switch sqlError {
  case let .valueInvalid(<#underlying#>, for: <#key#>, in: <#statement#>):
    …
  }
  …

Stretch: There should be a way to extract the associated values during a pattern match as a tuple. Sketch (with strawman syntax):

  // Different forms of the same case statement:
  case let .valueInvalid(underlying, for: key, in: statement):
  
  case let params in . valueInvalid:

  case let params in . valueInvalid(_:for:in:):

  case let (underlying, key, statement) in . valueInvalid:

  case let (underlying, key, statement) in . valueInvalid(_:for:in:):

Other than these things, I'm pretty happy with this proposal. I agree with the ideas of treating the labels as part of the case name, making them more usable as functions, and supporting default values.

  • Is the problem being addressed significant enough to warrant a change to Swift?

Yes—the issues described in the "Motivation" section are pretty ugly.

  • 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?

Not really in-depth, but I did put some thought into it.

···

On Feb 17, 2017, at 7:26 PM, John McCall <rjmccall@apple.com> wrote:

--
Brent Royal-Gordon
Architechies


(Rien) #4

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

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?

It simplifies the usage of swift, while also extending the expressive capabilities.

  • Is the problem being addressed significant enough to warrant a change to Swift?

IMO everything that simplifies a language is well worth the effort.

  • 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?

No

  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick reading.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl

···

On 18 Feb 2017, at 04:26, John McCall via swift-evolution <swift-evolution@swift.org> wrote:

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 mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Matthew Johnson) #5

  • What is your evaluation of the proposal?

+1. I am extremely confident that this is the right direction to go in.

I really like Brent’s idea for allowing us to distinguish the parameter label from what he calls the “internal name”.

In the value subtyping manifesto I recently posted I showed how we can assign a unique type to each enum case which is a subtype of the enum itself. The “internal name” Brent mentions would be the name of the stored property holding the value if that idea were introduced in the future. It has value beyond just documentation and autocompletion.

  • Is the problem being addressed significant enough to warrant a change to Swift?

Yes. Several years of experience with Swift are showing that there are many reasons for this to change.

  • Does this proposal fit well with the feel and direction of Swift?

Very much so.

  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I have not. The approach Swift takes to compound names is unique in my experience and is a very nice design.

  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce


(Dave Abrahams) #6

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.

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@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/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
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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce


(Howard Lovatt) #7

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

• What is your evaluation of the proposal?

Well worth while

• Is the problem being addressed significant enough to warrant a change to
Swift?

Yes, it is confusing to have different rules

• Does this proposal fit well with the feel and direction of Swift?

Yes, unification of concepts is part of the updating of Swift

• If you have used other languages or libraries with a similar feature,
how do you feel that this proposal compares to those?

No

• How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?

Quick read of the proposal

--

-- Howard.


(Tino) #8

Maybe I'm missing something obvious (or maybe I'm just generally in favour for case classes ;-), but as the main motivation for the proposal seems to be that enum cases should be more function-like: Why is this desirable?


(Daniel Duan) #9

Hi Slava,

+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?

An error.

- What are the memory layout optimizations described here? From a first glance this looks purely syntactic.

Nothing has stopped us from optimizing the layout further by stop using a tuple. In that sense this proposal is purely syntactic indeed. I got this idea from Joe. So I’ll just quote him here :stuck_out_tongue:

“...makes it easier to allow layout optimization, since the layout of each payload would be unique to the enum instead of having to play double duty as a tuple. Since tuples are structural types and can be dynamically passed into generic contexts we're constrained by the limitations of value witness tables in laying them out; no overlapping spare bits or anything like that."

···

On Feb 18, 2017, at 12:30 AM, Slava Pestov via swift-evolution <swift-evolution@swift.org> wrote:

Slava

On Feb 17, 2017, at 7:26 PM, John McCall via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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

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 mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Daniel Duan) #10

Hi Brent,

  Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md

  • What is your evaluation of the proposal?

I'm torn. Being able to handle the associated value as a tuple is very convenient, but I also want the argument list features described here. In practice, my own enums tend to end up using argument-like parameter labels, which works better when constructing and pattern-matching, but worse when extracting values.

I think I'd like to ask for two changes. One is probably easy; the other is a bit of a stretch.

Easy: Cases should allow internal names for documentation and autocompletion.

  enum SQLError: Error {
    …
    case valueInvalid(_ underlying: Error, for key: SQLColumnKey, in statement: SQLStatement)
    …
  }
  …
  throw SQLError.valueInvalid(error, for: key, in: statement)
  …
  switch sqlError {
  case let .valueInvalid(<#underlying#>, for: <#key#>, in: <#statement#>):
    …
  }
  …

A very natural conclusion if one wants to use enum constructors like real functions. When I considered this, my reaction to it myself was that the internal name may not be very useful in a meaningful way. In pattern matching, for example, the variables declared in the pattern are the counterpart of internal name. Using the would-be external labels for associated values’ labels (hey, they are both called “labels”!). The last thing to note: we can add internal name later without making a breaking change.

IMO this is worth considering if the community consider it valuable.

Stretch: There should be a way to extract the associated values during a pattern match as a tuple. Sketch (with strawman syntax):

  // Different forms of the same case statement:
  case let .valueInvalid(underlying, for: key, in: statement):
  
  case let params in . valueInvalid:

  case let params in . valueInvalid(_:for:in:):

  case let (underlying, key, statement) in . valueInvalid:

  case let (underlying, key, statement) in . valueInvalid(_:for:in:):

Someone brought this up in the draft discussion as well. I prefer to delay this feature until we have a clearer story on “splats”. Since this is “splat” in reverse, the syntax could be related.

···

On Feb 18, 2017, at 3:49 AM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

On Feb 17, 2017, at 7:26 PM, John McCall <rjmccall@apple.com> wrote:

Other than these things, I'm pretty happy with this proposal. I agree with the ideas of treating the labels as part of the case name, making them more usable as functions, and supporting default values.

  • Is the problem being addressed significant enough to warrant a change to Swift?

Yes—the issues described in the "Motivation" section are pretty ugly.

  • 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?

Not really in-depth, but I did put some thought into it.

--
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Daniel Duan) #11

  • What is your evaluation of the proposal?

+1. I am extremely confident that this is the right direction to go in.

I really like Brent’s idea for allowing us to distinguish the parameter label from what he calls the “internal name”.

In the value subtyping manifesto I recently posted I showed how we can assign a unique type to each enum case which is a subtype of the enum itself. The “internal name” Brent mentions would be the name of the stored property holding the value if that idea were introduced in the future. It has value beyond just documentation and autocompletion.

Intriguing! I wish I had read this before I replied to Brent’s. Would it be better to include the internal name addition in the subtyping proposal?

···

On Feb 18, 2017, at 8:47 AM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

  • Is the problem being addressed significant enough to warrant a change to Swift?

Yes. Several years of experience with Swift are showing that there are many reasons for this to change.

  • Does this proposal fit well with the feel and direction of Swift?

Very much so.

  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I have not. The approach Swift takes to compound names is unique in my experience and is a very nice design.

  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

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@swift.org <mailto:swift-evolution-announce@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(David Rönnqvist) #12

+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.

···

On 18 Feb 2017, at 09:30, Slava Pestov via swift-evolution <swift-evolution@swift.org> wrote:

- 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 <swift-evolution@swift.org> 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

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 mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Karl) #13

- What are the memory layout optimizations described here? From a first glance this looks purely syntactic.

The compiler could “refactor” the payloads among all enum cases to maximise overlapping. If you know that an enum’s payload always contains a reference-counted or shared object, or that a element is always at a given position in the payload, you can operate on the payload’s elements without needing to switch.

(crude example)

enum EditorMode {
    case .textEditor(UIViewController)
    case .imageEditor(UIViewController)

// This would reduce to just returning the payload without switching.
// We could even think about generating a “EditorMode.0 : UIViewController” accessor

    var editorController: UIViewController {
      switch self {
  case .textEditor(let t): return t
  case .imageEditor(let i): return i
}
    }
}

- Karl


(Daniel Duan) #14

Hi Dave,

···

On Feb 18, 2017, at 8:49 PM, Dave Abrahams via swift-evolution <swift-evolution@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

The degraded authoring experience is a legitimate concern. Here’s my attempt to make it *seems* better:

1. Perhaps it’d be a good style to treat labels similar to argument labels and variables in patterns as argument names:

    case let .value(validated: value, resumingAt: point) // or more descriptive variable names, depends on usage

We’ve came to expect some repetition between a argument label and its name, so typing a few more characters for the label in patterns shouldn’t seem totally bad, maybe. From a code reader's point of view, especially for those who haven’t seen the case declaration, more labels should be an easy win.

2. The creator of the enum dictates style at use site. When one prefers no not have labels, they can use comments as documentation at the declaration.

***

That being said, the idea of matching without field name appeals to me because I’m used to it from other languages.

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?

Love it. I think this should be part of this proposal. (man, if you squint, those cases named “_" make the whole declaration look like a C union).

Sent from my moss-covered three-handled family gradunza

On Feb 17, 2017, at 5:26 PM, John McCall <rjmccall@apple.com <mailto:rjmccall@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/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
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@swift.org <mailto:swift-evolution-announce@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Jacob Bandes-Storch) #15

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.

···

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

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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Matthew Johnson) #16

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.

I agree with this, but I think it’s an issue we can solve (perhaps as an amendment to this proposal).

First, I think Brent’s idea of introducing an argument label that can be distinct from the “property” name of the case is a good one. I think we should do this. It takes the parallel with function signatures even further.

Second, we should allow the “property” name to be `_`. This would mean no label can be used when matching:

case valid(value _: ValueType, resumptionPoint _: PointType)

Third, I think we should also allow suers to elide the label if they either discard the value with `_` or bind a name that is identical to the label, so we might have:

// declaration:
case valid(externalCasConstructorLabel value: ValueType, externalCaseConstructorLabel resumptionPoint: PointType)

// match ok:
case .valid(let value, let resumptionPoint):

// error, names do not match:
case .valid(let foo, let bar):

// ok, label is used:
case .valid(value: let foo, resumptionPoint: let bar):

This follows the behavior of function signatures very closely. The external label is used to provide context for the argument at the call site (of the case constructor). The internal name is used to bind a name to the value that is used by code that works with the value.

The only exception here is that because the usage site is distant from the case declaration it may wish to use a different name. We allow that, but only if the “internal name” is also used in the pattern. This preserves the ability of a reader of the code to see the name / meaning of the associated value as it was declared by the enum in addition to the name that might make more sense for use in the local context.

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?

+1. I think this makes a lot of sense. It completes the parallel of cases with overloaded functions.

I think anonymous cases are a really good idea. I discuss those quite a bit in the value subtyping manifesto I shared last week (I’d love to hear your thoughts on it if / when you have time to take a look).

How would you propose that values of anonymous cases be constructed and matched? My solution is to allow them to be constructed by implicit conversion from the associated value type to the enum type and matched by a cast pattern. Is that what you have in mind? I would *really* love to see this someday...

···

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

Sent from my moss-covered three-handled family gradunza

On Feb 17, 2017, at 5:26 PM, John McCall <rjmccall@apple.com <mailto:rjmccall@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/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
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@swift.org <mailto:swift-evolution-announce@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Daniel Duan) #17

Not sure which “this” you were referring to. The anonymous case part is something that I consider out-of-scope for this proposal as well. It came up during review and is posted as one of the core team’s request. There are two possibilities regarding this feature: I can put it in future considerations and defer it to a different proposal. Alternatively, I can write a 2-part proposal with the 2nd part being this feature. Each part would be reviewed separately.

···

On Feb 25, 2017, at 12:10 PM, Tino Heth via swift-evolution <swift-evolution@swift.org> wrote:

Maybe I'm missing something obvious (or maybe I'm just generally in favour for case classes ;-), but as the main motivation for the proposal seems to be that enum cases should be more function-like: Why is this desirable?
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Matthew Johnson) #18

Not sure which “this” you were referring to. The anonymous case part is something that I consider out-of-scope for this proposal as well. It came up during review and is posted as one of the core team’s request. There are two possibilities regarding this feature: I can put it in future considerations and defer it to a different proposal. Alternatively, I can write a 2-part proposal with the 2nd part being this feature. Each part would be reviewed separately.

Once we specify how overloaded patterns are matched (with casting) it becomes pretty straightforward that anonymous cases are matched with `(let s as String)`. I think it would good to include anonymous cases but make it clear that you view it as an “optional” enhancement that the core team is free to omit in the accepted version. I believe Dave A was the one who first mentioned it so it probably has a reasonable shot at being accepted,

···

On Feb 25, 2017, at 6:07 PM, Daniel Duan via swift-evolution <swift-evolution@swift.org> wrote:

On Feb 25, 2017, at 12:10 PM, Tino Heth via swift-evolution <swift-evolution@swift.org> wrote:

Maybe I'm missing something obvious (or maybe I'm just generally in favour for case classes ;-), but as the main motivation for the proposal seems to be that enum cases should be more function-like: Why is this desirable?
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Rien) #19

+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.

Full name matching would also allow a kind of “overloading” which can be very desirable in many cases.
Besides full-name matching seems more intuitive correct (compare for example case sensitivity).

Rien.

···

On 18 Feb 2017, at 14:16, David Rönnqvist via swift-evolution <swift-evolution@swift.org> wrote:
On 18 Feb 2017, at 09:30, Slava Pestov via swift-evolution <swift-evolution@swift.org> wrote:

- 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 <swift-evolution@swift.org> 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

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 mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Matthew Johnson) #20

  • What is your evaluation of the proposal?

+1. I am extremely confident that this is the right direction to go in.

I really like Brent’s idea for allowing us to distinguish the parameter label from what he calls the “internal name”.

In the value subtyping manifesto I recently posted I showed how we can assign a unique type to each enum case which is a subtype of the enum itself. The “internal name” Brent mentions would be the name of the stored property holding the value if that idea were introduced in the future. It has value beyond just documentation and autocompletion.

Intriguing! I wish I had read this before I replied to Brent’s. Would it be better to include the internal name addition in the subtyping proposal?

Yes, I will update it to reflect this as soon as I have a chance.

Keep in mind that the value subtyping manifesto is not a proposal or proposal draft. It is intended to be a map of possible future proposals which would need to be specified in more detail. If you think any of the topics in that manifesto might be relevant to consider in Swift 4 now that we’re in phase 2, please reply to that thread. I’d love to hear your feedback!

···

On Feb 18, 2017, at 2:55 PM, Daniel Duan <daniel@duan.org> wrote:

On Feb 18, 2017, at 8:47 AM, Matthew Johnson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

  • Is the problem being addressed significant enough to warrant a change to Swift?

Yes. Several years of experience with Swift are showing that there are many reasons for this to change.

  • Does this proposal fit well with the feel and direction of Swift?

Very much so.

  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I have not. The approach Swift takes to compound names is unique in my experience and is a very nice design.

  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

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@swift.org <mailto:swift-evolution-announce@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution