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

[Brent Royal-Gordon via swift-evolution]

> On Feb 17, 2017, at 7:26 PM, John McCall  wrote:
> 
>   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.

-- 
Brent Royal-Gordon
Architechies

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

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

[Matthew Johnson via swift-evolution]

>   • 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-annou...@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

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

[Daniel Duan via swift-evolution]

Hi Brent,

> On Feb 18, 2017, at 3:49 AM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> On Feb 17, 2017, at 7:26 PM, John McCall  wrote:
>> 
>>  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. 

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

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

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

[Daniel Duan via swift-evolution]

> On Feb 18, 2017, at 8:47 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
>>  • 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? 

>>  • 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-annou...@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

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

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

[Matthew Johnson via swift-evolution]

> On Feb 18, 2017, at 2:55 PM, Daniel Duan  wrote:
> 
>> 
>> On Feb 18, 2017, at 8:47 AM, Matthew Johnson via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>>> • 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!

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

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

[Dave Abrahams via swift-evolution]

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  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-annou...@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

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

[Daniel Duan via swift-evolution]

Hi Dave,

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

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

[Matthew Johnson via swift-evolution]

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

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

> 
> Sent from my moss-covered three-handled family gradunza
> 
> On Feb 17, 2017, at 5:26 PM, John McCall  > 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-normali

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

[Jacob Bandes-Storch via swift-evolution]

On Sat, 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.
>

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

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

[Erica Sadun via swift-evolution]

> On Feb 19, 2017, at 12:49 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
>> 
>> On Feb 18, 2017, at 10:49 PM, Dave Abrahams via swift-evolution 
>> mailto: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.

Dave has a good point here. (Which I'm reading *after* sending feedback to 
John.) If 
the problem with labels is that using them for conditional binding is awkward, 
maybe 
it's not the labels that's the problem. 

Pattern matching with conditional binding is a mess. 

* It's hard to read. 
* It uses inconsistent `let` and `var` both inside and outside the `case` 
syntax.
* It uses inconsistent syntax for switch/case, if/case-guard/case, and regular 
pattern matching.
* Conditional binding is coequal with pattern matching and can be 
mixed-and-matched, 
  for example, `case .foo(var x, 0 ... .max) where  x % 2 == 1`
* It involves inconsistent operators (`=` and `~=`) and awkward syntax. 
* It is hard to teach, to learn, and is one of the overall sore points of the 
language.

Some problems go away if you bind the existing value to a specific case instead 
of
conditionally binding new values. There are some significant issues here, but 
let me 
demonstrate to give a sense of what I'm talking about. An approach something 
like
the following would support this proposal and avoids DRY violations.  (I'm not
sure if this is even possible to accomplish):

```swift
enum Result {
case success(value: T)
case failure(error: Error)
}

if case let returnedResult ~= .success {
// returnedResult is the `success` case.
print(returnedResult.value) // member access
}

guard case var returnedResult ~= .success  else { ...discard error and leave 
scope ... }
// returnedResult is the `success` case for the remainder of this scope
print(returnedResult.value)

switch returnedResult {
   // Something like this
case .success:  // use $0.value
}

switch aDifferentEnum {
case foo(x: _, y: 0 ...max) where $0.x %2 == 1: // use $0.x, $0.y
case foo: // use $0.x, $0.y here
}
```

Can we support labels and re-architect interpretation/binding?

-- E


> 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 

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

[Howard Lovatt via swift-evolution]

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

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

[Daniel Duan via swift-evolution]

> On Feb 19, 2017, at 11:49 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
>> 
>> On Feb 18, 2017, at 10:49 PM, Dave Abrahams via swift-evolution 
>> mailto: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.
> 
> 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...

I can’t speak for Dave obviously. But I think he was merely proposing 
“overloaded” form of enum options, in which multiple options may share the 
compound name but with differently associated types. The name “_” would just be 
a normal identifier in such scenario. So it would also be the contractor’s 
function name.

>> 
>> Sent from my moss-covered three-handled family gradunza
>> 
>> On Feb 17, 2017, at 5:26 PM, John McCall > > 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
>>>  
>>> 

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

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Feb 19, 2017, at 6:52 PM, Daniel Duan  wrote:
> 
> 
>>> On Feb 19, 2017, at 11:49 AM, Matthew Johnson via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> On Feb 18, 2017, at 10:49 PM, Dave Abrahams via swift-evolution 
>>>  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.
>> 
>> 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...
> 
> I can’t speak for Dave obviously. But I think he was merely proposing 
> “overloaded” form of enum options, in which multiple options may share the 
> compound name but with differently associated types. The name “_” would just 
> be a normal identifier in such scenario. So it would also be the contractor’s 
> function name.

So values would be constructed like MyEnum._(42) and matched like ._(let i as 
Int).  Is that what you're thinking?  I suppose that would be a reasonable step 
to take for now.  Making MyEnum a subtype of the case types still seems like a 
more elegant long term goal.

> 
>>> 
>>> Sent from my moss-covered three-handled family gradunza
>>> 
 On Feb 17, 2017, at 5:26 PM, John McCall  wrote:
 
 Hello Swift 

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

[Dave Abrahams via swift-evolution]

I had not intended for _ to be an ordinary identifier, but as a way of spelling 
the empty case name. Ambiguous cases, not distinguished by either full name or 
payload type, would be errors. How to construct anonymous cases?  I guess it 
would be MyEnum(expression)

Sent from my moss-covered three-handled family gradunza

> On Feb 19, 2017, at 2:52 PM, Daniel Duan  wrote:
> 
> 
>>> On Feb 19, 2017, at 11:49 AM, Matthew Johnson via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> On Feb 18, 2017, at 10:49 PM, Dave Abrahams via swift-evolution 
>>>  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.
>> 
>> 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...
> 
> I can’t speak for Dave obviously. But I think he was merely proposing 
> “overloaded” form of enum options, in which multiple options may share the 
> compound name but with differently associated types. The name “_” would just 
> be a normal identifier in such scenario. So it would also be the contractor’s 
> function name.
> 
>>> 
>>> Sent from my moss-covered three-handled family gradunza
>>> 
 On Feb 17, 2017, at 5:26 PM, John McCal

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

[Daniel Duan via swift-evolution]

My apologies for misunderstanding.

Would it be better to add the anonymous case feature in a separate proposal? It 
stands alone as a new addition to enum. The intent for this proposal is 
bringing enum's syntax closure to other part of Swift.

Daniel Duan
Sent from my iPhone

> On Feb 21, 2017, at 1:15 AM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> I had not intended for _ to be an ordinary identifier, but as a way of 
> spelling the empty case name. Ambiguous cases, not distinguished by either 
> full name or payload type, would be errors. How to construct anonymous cases? 
>  I guess it would be MyEnum(expression)
> 
> Sent from my moss-covered three-handled family gradunza
> 
>> On Feb 19, 2017, at 2:52 PM, Daniel Duan  wrote:
>> 
>> 
 On Feb 19, 2017, at 11:49 AM, Matthew Johnson via swift-evolution 
  wrote:
 
 
 On Feb 18, 2017, at 10:49 PM, Dave Abrahams via swift-evolution 
  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.
>>> 
>>> 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 
>>>

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

[John McCall via swift-evolution]

> On Feb 21, 2017, at 4:43 AM, Daniel Duan via swift-evolution 
>  wrote:
> My apologies for misunderstanding.
> 
> Would it be better to add the anonymous case feature in a separate proposal? 
> It stands alone as a new addition to enum. The intent for this proposal is 
> bringing enum's syntax closure to other part of Swift.

The core team met and talked about SE-0155 today, even though we're not quite 
done with the review period, and here's where we stand.

SE-0155 is being returned for revision.  Consensus appears to be strongly in 
favor of requiring argument labels (if provided) to be enforced on "call" 
sites.  However, the core team feels that the proposal needs revision in the 
following ways:
  - Are internal argument names syntactically allowed in a case declaration?
  - Can cases with the same base name be overloaded by argument label?  If so, 
is a pattern match using just the bare name ambiguous or does it match both 
cases?
  - Can cases with the same name (using the same rule as above) be overloaded 
by argument type?  If so, how are they disambiguated in pattern matches?
  - Do pattern matches require argument labels to be given along with value 
patterns, e.g. "case .valid(value: let value)", or is there some way to shorten 
this?  If the latter, what are the rules for that?
  - Are you proposing anonymous cases, and if so, what are the language rules 
for them?
  - The proposal makes a claim about layout efficiency; please either discuss 
this claim or remove it.

John.

> 
> Daniel Duan
> Sent from my iPhone
> 
> On Feb 21, 2017, at 1:15 AM, Dave Abrahams via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>> I had not intended for _ to be an ordinary identifier, but as a way of 
>> spelling the empty case name. Ambiguous cases, not distinguished by either 
>> full name or payload type, would be errors. How to construct anonymous 
>> cases?  I guess it would be MyEnum(expression)
>> 
>> Sent from my moss-covered three-handled family gradunza
>> 
>> On Feb 19, 2017, at 2:52 PM, Daniel Duan > > wrote:
>> 
>>> 
 On Feb 19, 2017, at 11:49 AM, Matthew Johnson via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
> 
> On Feb 18, 2017, at 10:49 PM, Dave Abrahams via swift-evolution 
> mailto: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.
 
 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 na

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

[Daniel Duan via swift-evolution]

Thanks. I already planned to do a revision to address these questions, which 
all came up during the review.
> On Feb 22, 2017, at 11:27 AM, John McCall  wrote:
> 
>> On Feb 21, 2017, at 4:43 AM, Daniel Duan via swift-evolution 
>>  wrote:
>> My apologies for misunderstanding.
>> 
>> Would it be better to add the anonymous case feature in a separate proposal? 
>> It stands alone as a new addition to enum. The intent for this proposal is 
>> bringing enum's syntax closure to other part of Swift.
> 
> The core team met and talked about SE-0155 today, even though we're not quite 
> done with the review period, and here's where we stand.
> 
> SE-0155 is being returned for revision.  Consensus appears to be strongly in 
> favor of requiring argument labels (if provided) to be enforced on "call" 
> sites.  However, the core team feels that the proposal needs revision in the 
> following ways:
>   - Are internal argument names syntactically allowed in a case declaration?
>   - Can cases with the same base name be overloaded by argument label?  If 
> so, is a pattern match using just the bare name ambiguous or does it match 
> both cases?
>   - Can cases with the same name (using the same rule as above) be overloaded 
> by argument type?  If so, how are they disambiguated in pattern matches?
>   - Do pattern matches require argument labels to be given along with value 
> patterns, e.g. "case .valid(value: let value)", or is there some way to 
> shorten this?  If the latter, what are the rules for that?
>   - Are you proposing anonymous cases, and if so, what are the language rules 
> for them?
>   - The proposal makes a claim about layout efficiency; please either discuss 
> this claim or remove it.
> 
> John.
> 
>> 
>> Daniel Duan
>> Sent from my iPhone
>> 
>>> On Feb 21, 2017, at 1:15 AM, Dave Abrahams via swift-evolution 
>>>  wrote:
>>> 
>>> I had not intended for _ to be an ordinary identifier, but as a way of 
>>> spelling the empty case name. Ambiguous cases, not distinguished by either 
>>> full name or payload type, would be errors. How to construct anonymous 
>>> cases?  I guess it would be MyEnum(expression)
>>> 
>>> Sent from my moss-covered three-handled family gradunza
>>> 
 On Feb 19, 2017, at 2:52 PM, Daniel Duan  wrote:
 
 
>> On Feb 19, 2017, at 11:49 AM, Matthew Johnson via swift-evolution 
>>  wrote:
>> 
>> 
>> On Feb 18, 2017, at 10:49 PM, Dave Abrahams via swift-evolution 
>>  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.
> 
> 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 p

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

[Russ Bishop via swift-evolution]

> On Feb 22, 2017, at 11:27 AM, John McCall via swift-evolution 
>  wrote:
> 
>> On Feb 21, 2017, at 4:43 AM, Daniel Duan via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> My apologies for misunderstanding.
>> 
>> Would it be better to add the anonymous case feature in a separate proposal? 
>> It stands alone as a new addition to enum. The intent for this proposal is 
>> bringing enum's syntax closure to other part of Swift.
> 
> The core team met and talked about SE-0155 today, even though we're not quite 
> done with the review period, and here's where we stand.
> 
> SE-0155 is being returned for revision.  Consensus appears to be strongly in 
> favor of requiring argument labels (if provided) to be enforced on "call" 
> sites.  

Does this mean pattern matches as well? That adds a lot of verbosity for no 
gain.


Russ

> However, the core team feels that the proposal needs revision in the 
> following ways:
>   - Are internal argument names syntactically allowed in a case declaration?
>   - Can cases with the same base name be overloaded by argument label?  If 
> so, is a pattern match using just the bare name ambiguous or does it match 
> both cases?
>   - Can cases with the same name (using the same rule as above) be overloaded 
> by argument type?  If so, how are they disambiguated in pattern matches?
>   - Do pattern matches require argument labels to be given along with value 
> patterns, e.g. "case .valid(value: let value)", or is there some way to 
> shorten this?  If the latter, what are the rules for that?
>   - Are you proposing anonymous cases, and if so, what are the language rules 
> for them?
>   - The proposal makes a claim about layout efficiency; please either discuss 
> this claim or remove it.
> 
> John.
> 
>> 
>> Daniel Duan
>> Sent from my iPhone
>> 
>> On Feb 21, 2017, at 1:15 AM, Dave Abrahams via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>>> I had not intended for _ to be an ordinary identifier, but as a way of 
>>> spelling the empty case name. Ambiguous cases, not distinguished by either 
>>> full name or payload type, would be errors. How to construct anonymous 
>>> cases?  I guess it would be MyEnum(expression)
>>> 
>>> Sent from my moss-covered three-handled family gradunza
>>> 
>>> On Feb 19, 2017, at 2:52 PM, Daniel Duan >> > wrote:
>>> 
 
> On Feb 19, 2017, at 11:49 AM, Matthew Johnson via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>> 
>> On Feb 18, 2017, at 10:49 PM, Dave Abrahams via swift-evolution 
>> mailto: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.
> 
> 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 us

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

[Daniel Duan via swift-evolution]

Before I start revising this proposal, there are a couple of open questions I’d 
like to discuss with the community and the core team.

The first question relates to the purpose of having a “internal” argument name. 
There are applications of such names in GADT (if we ever get there) and perhaps 
the case-as-subtype-of-the-enum stories on the list right now. Out side of 
these scenarios, however, such names has few chances to be used. The one I can 
come up with, which is also the “open” part of the question, is this: we can 
use the internal names in pattern matching, as opposed to using the labels. 
This seems to align with the subtyping/GADT use cases. Is this a desirable 
outcome?

The second open question is the syntax for “overloaded” cases. If we decide to 
allow them, what should the patterns matching them look like? I can think of 
one obvious-ish design where we make the pattern look like the declaration and 
require types for disambiguation. So the most verbose form of pattern would 
look something like

```
case let .baseName(label0 name0: Type0, label1 name1: Type1)
```

Even in this design, there are the choice of forcing name0/name1 to match the 
“internal” name in declaration and letting users choose whatever they want. 
There maybe way elegant syntax that I haven’t thought of. Since my experience 
with languages with pattern matching syntax is pretty much limited to SML and 
Haskell, I must admit my inadequacy here. Any help is appreciated here!


> On Feb 22, 2017, at 11:27 AM, John McCall via swift-evolution 
>  wrote:
> 
>> On Feb 21, 2017, at 4:43 AM, Daniel Duan via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> My apologies for misunderstanding.
>> 
>> Would it be better to add the anonymous case feature in a separate proposal? 
>> It stands alone as a new addition to enum. The intent for this proposal is 
>> bringing enum's syntax closure to other part of Swift.
> 
> The core team met and talked about SE-0155 today, even though we're not quite 
> done with the review period, and here's where we stand.
> 
> SE-0155 is being returned for revision.  Consensus appears to be strongly in 
> favor of requiring argument labels (if provided) to be enforced on "call" 
> sites.  However, the core team feels that the proposal needs revision in the 
> following ways:
>   - Are internal argument names syntactically allowed in a case declaration?
>   - Can cases with the same base name be overloaded by argument label?  If 
> so, is a pattern match using just the bare name ambiguous or does it match 
> both cases?
>   - Can cases with the same name (using the same rule as above) be overloaded 
> by argument type?  If so, how are they disambiguated in pattern matches?
>   - Do pattern matches require argument labels to be given along with value 
> patterns, e.g. "case .valid(value: let value)", or is there some way to 
> shorten this?  If the latter, what are the rules for that?
>   - Are you proposing anonymous cases, and if so, what are the language rules 
> for them?
>   - The proposal makes a claim about layout efficiency; please either discuss 
> this claim or remove it.
> 
> John.
> 
>> 
>> Daniel Duan
>> Sent from my iPhone
>> 
>> On Feb 21, 2017, at 1:15 AM, Dave Abrahams via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>>> I had not intended for _ to be an ordinary identifier, but as a way of 
>>> spelling the empty case name. Ambiguous cases, not distinguished by either 
>>> full name or payload type, would be errors. How to construct anonymous 
>>> cases?  I guess it would be MyEnum(expression)
>>> 
>>> Sent from my moss-covered three-handled family gradunza
>>> 
>>> On Feb 19, 2017, at 2:52 PM, Daniel Duan >> > wrote:
>>> 
 
> On Feb 19, 2017, at 11:49 AM, Matthew Johnson via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>> 
>> On Feb 18, 2017, at 10:49 PM, Dave Abrahams via swift-evolution 
>> mailto: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.
> 
> 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

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

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Feb 24, 2017, at 11:26 PM, Daniel Duan via swift-evolution 
>  wrote:
> 
> Before I start revising this proposal, there are a couple of open questions 
> I’d like to discuss with the community and the core team.
> 
> The first question relates to the purpose of having a “internal” argument 
> name. There are applications of such names in GADT (if we ever get there) and 
> perhaps the case-as-subtype-of-the-enum stories on the list right now. Out 
> side of these scenarios, however, such names has few chances to be used. The 
> one I can come up with, which is also the “open” part of the question, is 
> this: we can use the internal names in pattern matching, as opposed to using 
> the labels. This seems to align with the subtyping/GADT use cases. Is this a 
> desirable outcome?

This is what I suggested.  I think of it like this: the case includes a static 
factory method that produces values.  We obviously want the external label 
here.  The pattern is like matching a labeled tuple.  When we think of the 
cases as a labeled tuple (or synthesized struct in the case-as-subtype world) 
it is clear (to me at least) that we want to use the internal name.  To avoid 
the noise, I suggest allowing patterns to elide the label if they bind to an 
identical name, which is often what they will do.

> 
> The second open question is the syntax for “overloaded” cases. If we decide 
> to allow them, what should the patterns matching them look like? I can think 
> of one obvious-ish design where we make the pattern look like the declaration 
> and require types for disambiguation. So the most verbose form of pattern 
> would look something like
> 
> ```
> case let .baseName(label0 name0: Type0, label1 name1: Type1)
> ```

We don't need new syntax for this.  Cast patterns in the associated value slots 
should work just fine:

case let .baseName(name0 as Type0, name1 as Type1)

Here, `name0` and `name1` are the internal names of the pattern.  If the 
pattern had different internal names the label must be used:

case let .baseName(internalName1: name0 as Type0, internalName2: name1 as Type1)

Note: the syntactic sugar of eliding the label should also be allowed in cases 
that don't don't distinguish the internal and external names.

> 
> Even in this design, there are the choice of forcing name0/name1 to match the 
> “internal” name in declaration and letting users choose whatever they want. 
> There maybe way elegant syntax that I haven’t thought of. Since my experience 
> with languages with pattern matching syntax is pretty much limited to SML and 
> Haskell, I must admit my inadequacy here. Any help is appreciated here!
> 
> 
>>> On Feb 22, 2017, at 11:27 AM, John McCall via swift-evolution 
>>>  wrote:
>>> 
>>> On Feb 21, 2017, at 4:43 AM, Daniel Duan via swift-evolution 
>>>  wrote:
>>> My apologies for misunderstanding.
>>> 
>>> Would it be better to add the anonymous case feature in a separate 
>>> proposal? It stands alone as a new addition to enum. The intent for this 
>>> proposal is bringing enum's syntax closure to other part of Swift.
>> 
>> The core team met and talked about SE-0155 today, even though we're not 
>> quite done with the review period, and here's where we stand.
>> 
>> SE-0155 is being returned for revision.  Consensus appears to be strongly in 
>> favor of requiring argument labels (if provided) to be enforced on "call" 
>> sites.  However, the core team feels that the proposal needs revision in the 
>> following ways:
>>   - Are internal argument names syntactically allowed in a case declaration?
>>   - Can cases with the same base name be overloaded by argument label?  If 
>> so, is a pattern match using just the bare name ambiguous or does it match 
>> both cases?
>>   - Can cases with the same name (using the same rule as above) be 
>> overloaded by argument type?  If so, how are they disambiguated in pattern 
>> matches?
>>   - Do pattern matches require argument labels to be given along with value 
>> patterns, e.g. "case .valid(value: let value)", or is there some way to 
>> shorten this?  If the latter, what are the rules for that?
>>   - Are you proposing anonymous cases, and if so, what are the language 
>> rules for them?
>>   - The proposal makes a claim about layout efficiency; please either 
>> discuss this claim or remove it.
>> 
>> John.
>> 
>>> 
>>> Daniel Duan
>>> Sent from my iPhone
>>> 
 On Feb 21, 2017, at 1:15 AM, Dave Abrahams via swift-evolution 
  wrote:
 
 I had not intended for _ to be an ordinary identifier, but as a way of 
 spelling the empty case name. Ambiguous cases, not distinguished by either 
 full name or payload type, would be errors. How to construct anonymous 
 cases?  I guess it would be MyEnum(expression)
 
 Sent from my moss-covered three-handled family gradunza
 
> On Feb 19, 2017, at 2:52 PM, Daniel Duan  wrote:
> 
> 
>>> On Feb 19, 2017, at 11:49 AM, Matthew Johnson via

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

[Daniel Duan via swift-evolution]

> On Feb 25, 2017, at 6:13 AM, Matthew Johnson  wrote:
> 
> 
> 
> Sent from my iPad
> 
> On Feb 24, 2017, at 11:26 PM, Daniel Duan via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>> Before I start revising this proposal, there are a couple of open questions 
>> I’d like to discuss with the community and the core team.
>> 
>> The first question relates to the purpose of having a “internal” argument 
>> name. There are applications of such names in GADT (if we ever get there) 
>> and perhaps the case-as-subtype-of-the-enum stories on the list right now. 
>> Out side of these scenarios, however, such names has few chances to be used. 
>> The one I can come up with, which is also the “open” part of the question, 
>> is this: we can use the internal names in pattern matching, as opposed to 
>> using the labels. This seems to align with the subtyping/GADT use cases. Is 
>> this a desirable outcome?
> 
> This is what I suggested.  I think of it like this: the case includes a 
> static factory method that produces values.  We obviously want the external 
> label here.  The pattern is like matching a labeled tuple.  When we think of 
> the cases as a labeled tuple (or synthesized struct in the case-as-subtype 
> world) it is clear (to me at least) that we want to use the internal name.  
> To avoid the noise, I suggest allowing patterns to elide the label if they 
> bind to an identical name, which is often what they will do.
> 
>> 
>> The second open question is the syntax for “overloaded” cases. If we decide 
>> to allow them, what should the patterns matching them look like? I can think 
>> of one obvious-ish design where we make the pattern look like the 
>> declaration and require types for disambiguation. So the most verbose form 
>> of pattern would look something like
>> 
>> ```
>> case let .baseName(label0 name0: Type0, label1 name1: Type1)
>> ```
> 
> We don't need new syntax for this.  Cast patterns in the associated value 
> slots should work just fine:
> 
> case let .baseName(name0 as Type0, name1 as Type1)
> 
> Here, `name0` and `name1` are the internal names of the pattern.  If the 
> pattern had different internal names the label must be used:
> 
> case let .baseName(internalName1: name0 as Type0, internalName2: name1 as 
> Type1)
> 
> Note: the syntactic sugar of eliding the label should also be allowed in 
> cases that don't don't distinguish the internal and external names.

Nice!

> 
>> 
>> Even in this design, there are the choice of forcing name0/name1 to match 
>> the “internal” name in declaration and letting users choose whatever they 
>> want. There maybe way elegant syntax that I haven’t thought of. Since my 
>> experience with languages with pattern matching syntax is pretty much 
>> limited to SML and Haskell, I must admit my inadequacy here. Any help is 
>> appreciated here!
>> 
>> 
>>> On Feb 22, 2017, at 11:27 AM, John McCall via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
 On Feb 21, 2017, at 4:43 AM, Daniel Duan via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 My apologies for misunderstanding.
 
 Would it be better to add the anonymous case feature in a separate 
 proposal? It stands alone as a new addition to enum. The intent for this 
 proposal is bringing enum's syntax closure to other part of Swift.
>>> 
>>> The core team met and talked about SE-0155 today, even though we're not 
>>> quite done with the review period, and here's where we stand.
>>> 
>>> SE-0155 is being returned for revision.  Consensus appears to be strongly 
>>> in favor of requiring argument labels (if provided) to be enforced on 
>>> "call" sites.  However, the core team feels that the proposal needs 
>>> revision in the following ways:
>>>   - Are internal argument names syntactically allowed in a case declaration?
>>>   - Can cases with the same base name be overloaded by argument label?  If 
>>> so, is a pattern match using just the bare name ambiguous or does it match 
>>> both cases?
>>>   - Can cases with the same name (using the same rule as above) be 
>>> overloaded by argument type?  If so, how are they disambiguated in pattern 
>>> matches?
>>>   - Do pattern matches require argument labels to be given along with value 
>>> patterns, e.g. "case .valid(value: let value)", or is there some way to 
>>> shorten this?  If the latter, what are the rules for that?
>>>   - Are you proposing anonymous cases, and if so, what are the language 
>>> rules for them?
>>>   - The proposal makes a claim about layout efficiency; please either 
>>> discuss this claim or remove it.
>>> 
>>> John.
>>> 
 
 Daniel Duan
 Sent from my iPhone
 
 On Feb 21, 2017, at 1:15 AM, Dave Abrahams via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
> I had not intended for _ to be an ordinary identifier, but as a way of 
> spelling the empty case name. Ambiguous cases, not distinguished by 

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

[Joe Groff via swift-evolution]

> On Feb 24, 2017, at 9:26 PM, Daniel Duan  wrote:
> 
> Before I start revising this proposal, there are a couple of open questions 
> I’d like to discuss with the community and the core team.
> 
> The first question relates to the purpose of having a “internal” argument 
> name. There are applications of such names in GADT (if we ever get there) and 
> perhaps the case-as-subtype-of-the-enum stories on the list right now. Out 
> side of these scenarios, however, such names has few chances to be used. The 
> one I can come up with, which is also the “open” part of the question, is 
> this: we can use the internal names in pattern matching, as opposed to using 
> the labels. This seems to align with the subtyping/GADT use cases. Is this a 
> desirable outcome?

Why would GADTs make internal argument names useful? They seem completely 
useless to me. Their "internal"-ness is compromised if you try to hang 
semantics off of them—they shouldn't have any impact on use sites.

> The second open question is the syntax for “overloaded” cases. If we decide 
> to allow them, what should the patterns matching them look like? I can think 
> of one obvious-ish design where we make the pattern look like the declaration 
> and require types for disambiguation. So the most verbose form of pattern 
> would look something like
> 
> ```
> case let .baseName(label0 name0: Type0, label1 name1: Type1)
> ```

By "overloaded", do you mean "same name different types", or "same base name, 
different argument names"? I think we should have a consistent naming model 
where the latter is never considered overloading. As an affordance to make 
pattern matching more concise, it seems reasonable to me to maybe say that a 
binding pattern matches a label with the same name, so that `case .foo(let bar, 
let bas)` can match `.foo(bar:bas:)`.

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

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

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Feb 27, 2017, at 12:00 PM, Joe Groff via swift-evolution 
>  wrote:
> 
> 
>> On Feb 24, 2017, at 9:26 PM, Daniel Duan  wrote:
>> 
>> Before I start revising this proposal, there are a couple of open questions 
>> I’d like to discuss with the community and the core team.
>> 
>> The first question relates to the purpose of having a “internal” argument 
>> name. There are applications of such names in GADT (if we ever get there) 
>> and perhaps the case-as-subtype-of-the-enum stories on the list right now. 
>> Out side of these scenarios, however, such names has few chances to be used. 
>> The one I can come up with, which is also the “open” part of the question, 
>> is this: we can use the internal names in pattern matching, as opposed to 
>> using the labels. This seems to align with the subtyping/GADT use cases. Is 
>> this a desirable outcome?
> 
> Why would GADTs make internal argument names useful? They seem completely 
> useless to me. Their "internal"-ness is compromised if you try to hang 
> semantics off of them—they shouldn't have any impact on use sites.

Internal is probably a bad name.  Imagine if the case is a subtype of the enum 
and thus a struct or struct-like type.  We would usually want the property to 
be named similarly to the name we would use for an argument in a function 
implementation, not the label used when calling the function.

Here is an example of the kind of thing I have in mind:

enum PlayerState {
   case stopped
   sub case playing(with track: Track)

// type of the playing case looks something like this:
struct Playing { let track: Track }

// the case value constructor looks something like this
static func playing(with track: Track) -> Playing {
return Playing(track: track)
}
}

let foo = Foo.playing(with: makeTrack())
let track = foo.track

switch foo {
case .stopped: break
// we get to match with the name that is argument / property-like
// `with` would be a terrible variable name 
case .playing(let track): // do something with the track

 // this label would be used when the user wants to use a *different* name
// case .playing(with: let someOtherName)
}


> 
>> The second open question is the syntax for “overloaded” cases. If we decide 
>> to allow them, what should the patterns matching them look like? I can think 
>> of one obvious-ish design where we make the pattern look like the 
>> declaration and require types for disambiguation. So the most verbose form 
>> of pattern would look something like
>> 
>> ```
>> case let .baseName(label0 name0: Type0, label1 name1: Type1)
>> ```
> 
> By "overloaded", do you mean "same name different types", or "same base name, 
> different argument names"? I think we should have a consistent naming model 
> where the latter is never considered overloading. As an affordance to make 
> pattern matching more concise, it seems reasonable to me to maybe say that a 
> binding pattern matches a label with the same name, so that `case .foo(let 
> bar, let bas)` can match `.foo(bar:bas:)`.

I agree as far as names go, but I think this was talking about same name 
different types. I believe the overloading sub-topic began with Dave A's 
comments about anonymous cases for enums where the associated value is all that 
matters. 

My suggestion was to allow overloading on types and use cast patterns to 
disambiguate when matching.  This increases consistency with functions and 
enables that important use case.


> 
> -Joe
> ___
> 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

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

[Daniel Duan via swift-evolution]

Daniel Duan
Sent from my iPhone
> On Feb 27, 2017, at 10:00 AM, Joe Groff  wrote:
> 
> 
>> On Feb 24, 2017, at 9:26 PM, Daniel Duan  wrote:
>> 
>> Before I start revising this proposal, there are a couple of open questions 
>> I’d like to discuss with the community and the core team.
>> 
>> The first question relates to the purpose of having a “internal” argument 
>> name. There are applications of such names in GADT (if we ever get there) 
>> and perhaps the case-as-subtype-of-the-enum stories on the list right now. 
>> Out side of these scenarios, however, such names has few chances to be used. 
>> The one I can come up with, which is also the “open” part of the question, 
>> is this: we can use the internal names in pattern matching, as opposed to 
>> using the labels. This seems to align with the subtyping/GADT use cases. Is 
>> this a desirable outcome?
> 
> Why would GADTs make internal argument names useful? They seem completely 
> useless to me. Their "internal"-ness is compromised if you try to hang 
> semantics off of them—they shouldn't have any impact on use sites.

Interesting. 

I was reaching for any possible use cases there. The theory is these names 
would be how one refers to a "property" of the case in, say, extension methods 
for the case.

But yeah, I considered this internal name thing during first draft and decided 
that they weren't necessary 🤷‍♀️
> 
>> The second open question is the syntax for “overloaded” cases. If we decide 
>> to allow them, what should the patterns matching them look like? I can think 
>> of one obvious-ish design where we make the pattern look like the 
>> declaration and require types for disambiguation. So the most verbose form 
>> of pattern would look something like
>> 
>> ```
>> case let .baseName(label0 name0: Type0, label1 name1: Type1)
>> ```
> 
> By "overloaded", do you mean "same name different types", or "same base name, 
> different argument names"? I think we should have a consistent naming model 
> where the latter is never considered overloading.

Same name different type is what "overloading" was meant here. "Same base name" 
is already in the first revision and wouldn't fit in this "open question" 
discussion.

> As an affordance to make pattern matching more concise, it seems reasonable 
> to me to maybe say that a binding pattern matches a label with the same name, 
> so that `case .foo(let bar, let bas)` can match `.foo(bar:bas:)`.

Good idea.

> -Joe

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

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

[Joe Groff via swift-evolution]

> On Feb 27, 2017, at 10:39 AM, Matthew Johnson  wrote:
> 
> 
> 
> Sent from my iPad
> 
>> On Feb 27, 2017, at 12:00 PM, Joe Groff via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Feb 24, 2017, at 9:26 PM, Daniel Duan  wrote:
>>> 
>>> Before I start revising this proposal, there are a couple of open questions 
>>> I’d like to discuss with the community and the core team.
>>> 
>>> The first question relates to the purpose of having a “internal” argument 
>>> name. There are applications of such names in GADT (if we ever get there) 
>>> and perhaps the case-as-subtype-of-the-enum stories on the list right now. 
>>> Out side of these scenarios, however, such names has few chances to be 
>>> used. The one I can come up with, which is also the “open” part of the 
>>> question, is this: we can use the internal names in pattern matching, as 
>>> opposed to using the labels. This seems to align with the subtyping/GADT 
>>> use cases. Is this a desirable outcome?
>> 
>> Why would GADTs make internal argument names useful? They seem completely 
>> useless to me. Their "internal"-ness is compromised if you try to hang 
>> semantics off of them—they shouldn't have any impact on use sites.
> 
> Internal is probably a bad name.  Imagine if the case is a subtype of the 
> enum and thus a struct or struct-like type.  We would usually want the 
> property to be named similarly to the name we would use for an argument in a 
> function implementation, not the label used when calling the function.
> 
> Here is an example of the kind of thing I have in mind:
> 
> enum PlayerState {
>   case stopped
>   sub case playing(with track: Track)
> 
>// type of the playing case looks something like this:
>struct Playing { let track: Track }
> 
>// the case value constructor looks something like this
>static func playing(with track: Track) -> Playing {
>return Playing(track: track)
>}
> }
> 
> let foo = Foo.playing(with: makeTrack())
> let track = foo.track
> 
> switch foo {
>case .stopped: break
>// we get to match with the name that is argument / property-like
>// `with` would be a terrible variable name 
>case .playing(let track): // do something with the track
> 
> // this label would be used when the user wants to use a *different* name
>// case .playing(with: let someOtherName)
> }

That still feels like it's going against the behavior of the binding name in 
other declarations. Personally, `case .playing(with: let x)` doesn't bother me 
that much, especially since the IDE ought to be able to splat that out for you.

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

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

[John McCall via swift-evolution]

> On Feb 27, 2017, at 1:39 PM, Daniel Duan  wrote:
>> On Feb 27, 2017, at 10:00 AM, Joe Groff  wrote:
>> 
>> 
>>> On Feb 24, 2017, at 9:26 PM, Daniel Duan  wrote:
>>> 
>>> Before I start revising this proposal, there are a couple of open questions 
>>> I’d like to discuss with the community and the core team.
>>> 
>>> The first question relates to the purpose of having a “internal” argument 
>>> name. There are applications of such names in GADT (if we ever get there) 
>>> and perhaps the case-as-subtype-of-the-enum stories on the list right now. 
>>> Out side of these scenarios, however, such names has few chances to be 
>>> used. The one I can come up with, which is also the “open” part of the 
>>> question, is this: we can use the internal names in pattern matching, as 
>>> opposed to using the labels. This seems to align with the subtyping/GADT 
>>> use cases. Is this a desirable outcome?
>> 
>> Why would GADTs make internal argument names useful? They seem completely 
>> useless to me. Their "internal"-ness is compromised if you try to hang 
>> semantics off of them—they shouldn't have any impact on use sites.
> 
> Interesting. 
> 
> I was reaching for any possible use cases there. The theory is these names 
> would be how one refers to a "property" of the case in, say, extension 
> methods for the case.
> 
> But yeah, I considered this internal name thing during first draft and 
> decided that they weren't necessary 🤷‍♀️

I think the strongest argument here is that internal names already have an 
accepted meaning, which is just that they name the argument variables in the 
following code.  Today, cases don't have any following code, but if/when we add 
that in SE-, people will obviously expect internal names to name those 
argument variables.  Even if the SE- proposers decide that, actually, using 
internal names for case arguments isn't a good idea, they will still need to do 
something about that natural user expectation, and they shouldn't be limited by 
us having carelessly given internal names some random other meaning way back in 
SE-0155.

John.

>> 
>>> The second open question is the syntax for “overloaded” cases. If we decide 
>>> to allow them, what should the patterns matching them look like? I can 
>>> think of one obvious-ish design where we make the pattern look like the 
>>> declaration and require types for disambiguation. So the most verbose form 
>>> of pattern would look something like
>>> 
>>> ```
>>> case let .baseName(label0 name0: Type0, label1 name1: Type1)
>>> ```
>> 
>> By "overloaded", do you mean "same name different types", or "same base 
>> name, different argument names"? I think we should have a consistent naming 
>> model where the latter is never considered overloading.
> 
> Same name different type is what "overloading" was meant here. "Same base 
> name" is already in the first revision and wouldn't fit in this "open 
> question" discussion.
> 
>> As an affordance to make pattern matching more concise, it seems reasonable 
>> to me to maybe say that a binding pattern matches a label with the same 
>> name, so that `case .foo(let bar, let bas)` can match `.foo(bar:bas:)`.
> 
> Good idea.
> 
>> -Joe
> 

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

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

[Matthew Johnson via swift-evolution]

> On Feb 27, 2017, at 12:46 PM, Joe Groff  wrote:
> 
> 
>> On Feb 27, 2017, at 10:39 AM, Matthew Johnson  wrote:
>> 
>> 
>> 
>> Sent from my iPad
>> 
>>> On Feb 27, 2017, at 12:00 PM, Joe Groff via swift-evolution 
>>>  wrote:
>>> 
>>> 
 On Feb 24, 2017, at 9:26 PM, Daniel Duan  wrote:
 
 Before I start revising this proposal, there are a couple of open 
 questions I’d like to discuss with the community and the core team.
 
 The first question relates to the purpose of having a “internal” argument 
 name. There are applications of such names in GADT (if we ever get there) 
 and perhaps the case-as-subtype-of-the-enum stories on the list right now. 
 Out side of these scenarios, however, such names has few chances to be 
 used. The one I can come up with, which is also the “open” part of the 
 question, is this: we can use the internal names in pattern matching, as 
 opposed to using the labels. This seems to align with the subtyping/GADT 
 use cases. Is this a desirable outcome?
>>> 
>>> Why would GADTs make internal argument names useful? They seem completely 
>>> useless to me. Their "internal"-ness is compromised if you try to hang 
>>> semantics off of them—they shouldn't have any impact on use sites.
>> 
>> Internal is probably a bad name.  Imagine if the case is a subtype of the 
>> enum and thus a struct or struct-like type.  We would usually want the 
>> property to be named similarly to the name we would use for an argument in a 
>> function implementation, not the label used when calling the function.
>> 
>> Here is an example of the kind of thing I have in mind:
>> 
>> enum PlayerState {
>>  case stopped
>>  sub case playing(with track: Track)
>> 
>>   // type of the playing case looks something like this:
>>   struct Playing { let track: Track }
>> 
>>   // the case value constructor looks something like this
>>   static func playing(with track: Track) -> Playing {
>>   return Playing(track: track)
>>   }
>> }
>> 
>> let foo = Foo.playing(with: makeTrack())
>> let track = foo.track
>> 
>> switch foo {
>>   case .stopped: break
>>   // we get to match with the name that is argument / property-like
>>   // `with` would be a terrible variable name 
>>   case .playing(let track): // do something with the track
>> 
>>// this label would be used when the user wants to use a *different* name
>>   // case .playing(with: let someOtherName)
>> }
> 
> That still feels like it's going against the behavior of the binding name in 
> other declarations. Personally, `case .playing(with: let x)` doesn't bother 
> me that much, especially since the IDE ought to be able to splat that out for 
> you.

It depends on how verbose the label is.  :)  

What did you think of the subtype example using the “internal” name as the 
property name?  Does that make sense?

I definitely don’t think we would want to allow eliding the *external* label by 
binding a name: `case .playing(let with)` is a bit absurd! :)

Personally, I think eliding would be a useful shorthand and if we allow it 
along with internal names (which I also think is a good idea) then we would 
want eliding to use the internal / property name.  

The primary goal should be clarity at the site of the pattern.  Sometimes a 
label adds clarity, but other times it will just add clutter.  Allowing label 
elision ensures a reader sees a name that lines up with the meaning of the 
associated value with less clutter.  I think this would often increase clarity. 
 That said, it is a rather minor piece of syntactic sugar.


> 
> -Joe

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

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

[Dave Abrahams via swift-evolution]

on Mon Feb 27 2017, Joe Groff  wrote:

>> On Feb 24, 2017, at 9:26 PM, Daniel Duan  wrote:
>> 
>> Before I start revising this proposal, there are a couple of open questions 
>> I’d like to discuss
> with the community and the core team.
>> 
>> The first question relates to the purpose of having a “internal”
>> argument name. There are applications of such names in GADT (if we
>> ever get there) and perhaps the case-as-subtype-of-the-enum stories
>> on the list right now. Out side of these scenarios, however, such
>> names has few chances to be used. The one I can come up with, which
>> is also the “open” part of the question, is this: we can use the
>> internal names in pattern matching, as opposed to using the
>> labels. This seems to align with the subtyping/GADT use cases. Is
>> this a desirable outcome?
>
> Why would GADTs make internal argument names useful? 

I'll probably never win this fight, but I'm trying to get people to use
“parameter name” and “argument label” as the preferred terms.

> They seem completely useless to me. Their "internal"-ness is
> compromised if you try to hang semantics off of them—they shouldn't
> have any impact on use sites.
>
>> The second open question is the syntax for “overloaded” cases. If we
>> decide to allow them, what should the patterns matching them look
>> like? I can think of one obvious-ish design where we make the
>> pattern look like the declaration and require types for
>> disambiguation. So the most verbose form of pattern would look
>> something like
>> 
>> ```
>> case let .baseName(label0 name0: Type0, label1 name1: Type1)
>> ```
>
> By "overloaded", do you mean "same name different types", or "same
> base name, different argument names"? 

When you write "argument name," do you mean parameter name or argument
label?  This is an example of why I'd like us to settle on the other
terminology.

> I think we should have a consistent naming model where the latter is
> never considered overloading. As an affordance to make pattern
> matching more concise, it seems reasonable to me to maybe say that a
> binding pattern matches a label with the same name, so that `case
> .foo(let bar, let bas)` can match `.foo(bar:bas:)`.

SGTM

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

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

[Dave Abrahams via swift-evolution]

on Mon Feb 27 2017, Matthew Johnson  wrote:

>> On Feb 27, 2017, at 12:46 PM, Joe Groff  wrote:
>> 
>> That still feels like it's going against the behavior of the binding
>> name in other declarations. Personally, `case .playing(with: let x)`
>> doesn't bother me that much, especially since the IDE ought to be
>> able to splat that out for you.
>
> It depends on how verbose the label is.  :)  

Yeah, how hard something is to type is very rarely more important than
how hard it is to read.

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

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

[Matthew Johnson via swift-evolution]

> On Feb 27, 2017, at 4:07 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Mon Feb 27 2017, Joe Groff  wrote:
> 
>>> On Feb 24, 2017, at 9:26 PM, Daniel Duan  wrote:
>>> 
>>> Before I start revising this proposal, there are a couple of open questions 
>>> I’d like to discuss
>> with the community and the core team.
>>> 
>>> The first question relates to the purpose of having a “internal”
>>> argument name. There are applications of such names in GADT (if we
>>> ever get there) and perhaps the case-as-subtype-of-the-enum stories
>>> on the list right now. Out side of these scenarios, however, such
>>> names has few chances to be used. The one I can come up with, which
>>> is also the “open” part of the question, is this: we can use the
>>> internal names in pattern matching, as opposed to using the
>>> labels. This seems to align with the subtyping/GADT use cases. Is
>>> this a desirable outcome?
>> 
>> Why would GADTs make internal argument names useful? 
> 
> I'll probably never win this fight, but I'm trying to get people to use
> “parameter name” and “argument label” as the preferred terms.

I like this terminology.  I’ll start using it.  Thanks for making an attempt to 
get everyone on the same page!  :)

> 
>> They seem completely useless to me. Their "internal"-ness is
>> compromised if you try to hang semantics off of them—they shouldn't
>> have any impact on use sites.
>> 
>>> The second open question is the syntax for “overloaded” cases. If we
>>> decide to allow them, what should the patterns matching them look
>>> like? I can think of one obvious-ish design where we make the
>>> pattern look like the declaration and require types for
>>> disambiguation. So the most verbose form of pattern would look
>>> something like
>>> 
>>> ```
>>> case let .baseName(label0 name0: Type0, label1 name1: Type1)
>>> ```
>> 
>> By "overloaded", do you mean "same name different types", or "same
>> base name, different argument names"? 
> 
> When you write "argument name," do you mean parameter name or argument
> label?  This is an example of why I'd like us to settle on the other
> terminology.
> 
>> I think we should have a consistent naming model where the latter is
>> never considered overloading. As an affordance to make pattern
>> matching more concise, it seems reasonable to me to maybe say that a
>> binding pattern matches a label with the same name, so that `case
>> .foo(let bar, let bas)` can match `.foo(bar:bas:)`.
> 
> SGTM
> 
> -- 
> -Dave
> ___
> 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

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

[Xiaodi Wu via swift-evolution]

Having watched this conversation from the sidelines, I just wanted to chime
in from a more distant view:

Originally, I thought this proposal was very nice because it made a good
argument as to why enum cases would benefit from being function-like. It
follows naturally that form should follow function, and therefore it's hard
to argue that the syntax shouldn't be "rectified."

But, given the latest discussions, it seems that there's a bunch of
round-peg-square-hole efforts going on precisely because enum cases
*aren't* very function-like in some key respects:

- John McCall gives a cogent reason why parameter names and argument labels
would be inconsistently used if they are put to the purpose that some have
proposed here for enum cases.

- There's a lot of bikeshedding as to pattern matching with argument
labels, as it seems that people generally agree that always requiring them
in that scenario would make the experience of using enums worse rather than
better. In fact, it seems that what's cited as a shortcoming in the
original proposal ("labels in patterns aren't enforced") is precisely what
we're trying to invent new sugar to duplicate.

Now, since we clearly want enum cases to be tuple-like in some respects
(pattern matching) but function-like in other respects, is swinging from
one extreme ("cases are tuples!") to the other ("cases are functions!") the
right thing to do? Does it really make the language more "consistent"?


On Mon, Feb 27, 2017 at 4:10 PM, Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Feb 27, 2017, at 4:07 PM, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >
> > on Mon Feb 27 2017, Joe Groff  wrote:
> >
> >>> On Feb 24, 2017, at 9:26 PM, Daniel Duan  wrote:
> >>>
> >>> Before I start revising this proposal, there are a couple of open
> questions I’d like to discuss
> >> with the community and the core team.
> >>>
> >>> The first question relates to the purpose of having a “internal”
> >>> argument name. There are applications of such names in GADT (if we
> >>> ever get there) and perhaps the case-as-subtype-of-the-enum stories
> >>> on the list right now. Out side of these scenarios, however, such
> >>> names has few chances to be used. The one I can come up with, which
> >>> is also the “open” part of the question, is this: we can use the
> >>> internal names in pattern matching, as opposed to using the
> >>> labels. This seems to align with the subtyping/GADT use cases. Is
> >>> this a desirable outcome?
> >>
> >> Why would GADTs make internal argument names useful?
> >
> > I'll probably never win this fight, but I'm trying to get people to use
> > “parameter name” and “argument label” as the preferred terms.
>
> I like this terminology.  I’ll start using it.  Thanks for making an
> attempt to get everyone on the same page!  :)
>
> >
> >> They seem completely useless to me. Their "internal"-ness is
> >> compromised if you try to hang semantics off of them—they shouldn't
> >> have any impact on use sites.
> >>
> >>> The second open question is the syntax for “overloaded” cases. If we
> >>> decide to allow them, what should the patterns matching them look
> >>> like? I can think of one obvious-ish design where we make the
> >>> pattern look like the declaration and require types for
> >>> disambiguation. So the most verbose form of pattern would look
> >>> something like
> >>>
> >>> ```
> >>> case let .baseName(label0 name0: Type0, label1 name1: Type1)
> >>> ```
> >>
> >> By "overloaded", do you mean "same name different types", or "same
> >> base name, different argument names"?
> >
> > When you write "argument name," do you mean parameter name or argument
> > label?  This is an example of why I'd like us to settle on the other
> > terminology.
> >
> >> I think we should have a consistent naming model where the latter is
> >> never considered overloading. As an affordance to make pattern
> >> matching more concise, it seems reasonable to me to maybe say that a
> >> binding pattern matches a label with the same name, so that `case
> >> .foo(let bar, let bas)` can match `.foo(bar:bas:)`.
> >
> > SGTM
> >
> > --
> > -Dave
> > ___
> > 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

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

[Brent Royal-Gordon via swift-evolution]

-- 
Brent Royal-Gordon
Sent from my iPhone
> On Feb 27, 2017, at 10:39 AM, Matthew Johnson via swift-evolution 
>  wrote:

> 
> Here is an example of the kind of thing I have in mind:
> 
> enum PlayerState {
>   case stopped
>   sub case playing(with track: Track)
> 
>// type of the playing case looks something like this:
>struct Playing { let track: Track }
> 
>// the case value constructor looks something like this
>static func playing(with track: Track) -> Playing {
>return Playing(track: track)
>}
> }

Consider a different desugaring that leads to a different conclusion:

enum PlayerState {
  case struct stopped {
init() {}
// I have some truly remarkable thoughts 
// on types like this one, which this margin
// is too narrow to contain.
  }
  case struct playing {
let track: Track
init(track: Track) {
  self.track = track
}
}

In this design, because the associated values on a case are really defining an 
initializer on a type, it would be against Swift conventions to use a parameter 
label like `with` instead of the actually-meaningful `track`. So the solution 
to this kind of problem is simply "Don't do that". 

-- 
Brent Royal-Gordon
Sent from my iPhone
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

> On Feb 27, 2017, at 9:17 PM, Xiaodi Wu  wrote:
> 
> Having watched this conversation from the sidelines, I just wanted to chime 
> in from a more distant view:
> 
> Originally, I thought this proposal was very nice because it made a good 
> argument as to why enum cases would benefit from being function-like. It 
> follows naturally that form should follow function, and therefore it's hard 
> to argue that the syntax shouldn't be "rectified."
> 
> But, given the latest discussions, it seems that there's a bunch of 
> round-peg-square-hole efforts going on precisely because enum cases *aren't* 
> very function-like in some key respects:
> 
> - John McCall gives a cogent reason why parameter names and argument labels 
> would be inconsistently used if they are put to the purpose that some have 
> proposed here for enum cases.
> 
> - There's a lot of bikeshedding as to pattern matching with argument labels, 
> as it seems that people generally agree that always requiring them in that 
> scenario would make the experience of using enums worse rather than better. 
> In fact, it seems that what's cited as a shortcoming in the original proposal 
> ("labels in patterns aren't enforced") is precisely what we're trying to 
> invent new sugar to duplicate.

I didn’t write the proposal so I won’t comment directly on the motivation 
section.  The reason I think not enforcing labels is a problem in the current 
rules is because allowing this does not convey the meaning of the associated 
value to a reader of the pattern.  The suggestions for syntactic sugar to allow 
eliding a label avoids this problem altogether.  I don’t think label elision is 
that complicated rule to teach and it could improve clarity of code 
nontrivially.  

I have personally found a tension between using labels and having patterns that 
are quite unfortunately verbose.  One can avoid this today by leaving off the 
label and being responsible with the name you assign.  I would like to keep the 
concise nature of leaving off the labels while being assured that a reasonable 
name is used.

> 
> Now, since we clearly want enum cases to be tuple-like in some respects 
> (pattern matching) but function-like in other respects, is swinging from one 
> extreme ("cases are tuples!") to the other ("cases are functions!") the right 
> thing to do? Does it really make the language more "consistent”?

My view is that it is a mistake to try to pidgeonhole enum cases into *one* of 
the roles they play.  They actually play a couple of roles and we should 
acknowledge and consider each of these in designing the language.  

The way I view enum cases is as a static factory method that produces a value 
which may be structurally matched using a pattern accessible via the base name 
of the case.  I don’t see any reason why we should have to adopt one view or 
the other.  Both are true and should be embraced.  

enum Foo {
   case bar(argumentLabel propertyName: Int)
}

Is a lot like this in a hypothetical Swift with value subtyping and structural 
decomposition / matching of structs:

struct Foo {
   struct Bar: Foo { let propertyName: Int }
   static func bar(argumentLabel parameterName: Int) -> Bar {
  return Bar(propertyName: parameterName)
   }
}

switch Foo.bar(argumentLabel: 42) as Foo {
   case let (propertyName: let propertyValue): print(“value is 
\(propertyValue)”) as Bar
}

The only important differences are that this *requires* subtyping, and it does 
not allow the pattern to be accessed on Foo.  One can even imaging syntax 
allowing the pattern to be accessible on `Foo` using a name `bar`:

extension Foo {
   pattern bar = // syntax which sets up a structural match of Bar values 
inside the parens when users type `.bar(structural match of Bar value here)`
}


> 
> 
> On Mon, Feb 27, 2017 at 4:10 PM, Matthew Johnson via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> > On Feb 27, 2017, at 4:07 PM, Dave Abrahams via swift-evolution 
> > mailto:swift-evolution@swift.org>> wrote:
> >
> >
> > on Mon Feb 27 2017, Joe Groff  wrote:
> >
> >>> On Feb 24, 2017, at 9:26 PM, Daniel Duan  >>> > wrote:
> >>>
> >>> Before I start revising this proposal, there are a couple of open 
> >>> questions I’d like to discuss
> >> with the community and the core team.
> >>>
> >>> The first question relates to the purpose of having a “internal”
> >>> argument name. There are applications of such names in GADT (if we
> >>> ever get there) and perhaps the case-as-subtype-of-the-enum stories
> >>> on the list right now. Out side of these scenarios, however, such
> >>> names has few chances to be used. The one I can come up with, which
> >>> is also the “open” part of the question, is this: we can use the
> >>> internal names in pattern matching, as opposed to using the
> >>> labels. This seems to align with the subtyping/GADT use cases. Is
> >>> this a desirable outcome?
> >>
> >> Why would GADTs make internal argument names useful?
>

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

[Matthew Johnson via swift-evolution]

> On Feb 27, 2017, at 9:53 PM, Brent Royal-Gordon  
> wrote:
> 
> 
> 
> -- 
> Brent Royal-Gordon
> Sent from my iPhone
>> On Feb 27, 2017, at 10:39 AM, Matthew Johnson via swift-evolution 
>>  wrote:
> 
>> 
>> Here is an example of the kind of thing I have in mind:
>> 
>> enum PlayerState {
>>  case stopped
>>  sub case playing(with track: Track)
>> 
>>   // type of the playing case looks something like this:
>>   struct Playing { let track: Track }
>> 
>>   // the case value constructor looks something like this
>>   static func playing(with track: Track) -> Playing {
>>   return Playing(track: track)
>>   }
>> }
> 
> Consider a different desugaring that leads to a different conclusion:
> 
> enum PlayerState {
>  case struct stopped {
>init() {}
>// I have some truly remarkable thoughts 
>// on types like this one, which this margin
>// is too narrow to contain.
>  }
>  case struct playing {
>let track: Track
>init(track: Track) {
>  self.track = track
>}
> }
> 
> In this design, because the associated values on a case are really defining 
> an initializer on a type, it would be against Swift conventions to use a 
> parameter label like `with` instead of the actually-meaningful `track`. So 
> the solution to this kind of problem is simply "Don't do that". 

This example isn’t great.  It was the first reasonable thing that came to mind 
to try and illustrate how I see argument labels and parameter / property names 
fitting in here.

I don’t agree with this perspective because enum cases are not accessed using a 
type name.  When you use a type name to directly call an initializer it makes 
sense to use the property names for the labels.  

When we have a static factory method that uses a private initializer to 
construct a value we *do not* necessarily follow this convention of using 
property names directly.  We use a more sentence-like structure with external 
labels.  Enum cases more closely match the way static factory methods are used 
so I think this is the proper way to conceptualize them when we are talking 
about using them to construct values.

> 
> -- 
> Brent Royal-Gordon
> Sent from my iPhone

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

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

[Joe Groff via swift-evolution]

> On Feb 27, 2017, at 7:17 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> Having watched this conversation from the sidelines, I just wanted to chime 
> in from a more distant view:
> 
> Originally, I thought this proposal was very nice because it made a good 
> argument as to why enum cases would benefit from being function-like. It 
> follows naturally that form should follow function, and therefore it's hard 
> to argue that the syntax shouldn't be "rectified."
> 
> But, given the latest discussions, it seems that there's a bunch of 
> round-peg-square-hole efforts going on precisely because enum cases *aren't* 
> very function-like in some key respects:
> 
> - John McCall gives a cogent reason why parameter names and argument labels 
> would be inconsistently used if they are put to the purpose that some have 
> proposed here for enum cases.
> 
> - There's a lot of bikeshedding as to pattern matching with argument labels, 
> as it seems that people generally agree that always requiring them in that 
> scenario would make the experience of using enums worse rather than better. 
> In fact, it seems that what's cited as a shortcoming in the original proposal 
> ("labels in patterns aren't enforced") is precisely what we're trying to 
> invent new sugar to duplicate.
> 
> Now, since we clearly want enum cases to be tuple-like in some respects 
> (pattern matching) but function-like in other respects, is swinging from one 
> extreme ("cases are tuples!") to the other ("cases are functions!") the right 
> thing to do? Does it really make the language more "consistent"?

It would absolutely make the implementation more consistent, since cases in 
expressions are the last vestige keeping a lot of damaged code in the 
type-checker alive to deal with argument label/tuple label ambiguity. 
Personally, I don't think that requiring labels in pattern matching is an undue 
burden, and I agree it's not a good idea to try to make up sugar to 
"un-require" them:

- It's totally self-imposed verbosity—nobody *has* to label their case 
payloads, and if you feel compelled to, it must be for a good reason. In my 
mind, those reasons shouldn't come up that often in practice, since enums with 
compound payloads are often better factored into a combination of enums and 
structs, and single-element payloads are best left unlabeled, like `some` or 
`string`/`number`/`array`/`object`.
- In general, pattern-matching syntax ought to behave as a mirror image of the 
expression that constructs a matching value, with holes punched into it via '_' 
or 'let' subpatterns. A lot of people already struggle with the concept, and 
unnecessary divergence from the behavior of expressions is added complexity. We 
already have too many inconsistencies in this area (implicit conversions in 
expressions don't fire in patterns; some pattern forms are artificially 
hardcoded to only look up enum cases; there are weird and technically redundant 
forms like "is T") that make learning patterns difficult.

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

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

[Matthew Johnson via swift-evolution]

> On Feb 28, 2017, at 10:39 AM, Joe Groff  wrote:
> 
> 
>> On Feb 27, 2017, at 7:17 PM, Xiaodi Wu via swift-evolution 
>>  wrote:
>> 
>> Having watched this conversation from the sidelines, I just wanted to chime 
>> in from a more distant view:
>> 
>> Originally, I thought this proposal was very nice because it made a good 
>> argument as to why enum cases would benefit from being function-like. It 
>> follows naturally that form should follow function, and therefore it's hard 
>> to argue that the syntax shouldn't be "rectified."
>> 
>> But, given the latest discussions, it seems that there's a bunch of 
>> round-peg-square-hole efforts going on precisely because enum cases *aren't* 
>> very function-like in some key respects:
>> 
>> - John McCall gives a cogent reason why parameter names and argument labels 
>> would be inconsistently used if they are put to the purpose that some have 
>> proposed here for enum cases.
>> 
>> - There's a lot of bikeshedding as to pattern matching with argument labels, 
>> as it seems that people generally agree that always requiring them in that 
>> scenario would make the experience of using enums worse rather than better. 
>> In fact, it seems that what's cited as a shortcoming in the original 
>> proposal ("labels in patterns aren't enforced") is precisely what we're 
>> trying to invent new sugar to duplicate.
>> 
>> Now, since we clearly want enum cases to be tuple-like in some respects 
>> (pattern matching) but function-like in other respects, is swinging from one 
>> extreme ("cases are tuples!") to the other ("cases are functions!") the 
>> right thing to do? Does it really make the language more "consistent"?
> 
> It would absolutely make the implementation more consistent, since cases in 
> expressions are the last vestige keeping a lot of damaged code in the 
> type-checker alive to deal with argument label/tuple label ambiguity. 
> Personally, I don't think that requiring labels in pattern matching is an 
> undue burden, and I agree it's not a good idea to try to make up sugar to 
> "un-require" them:
> 
> - It's totally self-imposed verbosity—nobody *has* to label their case 
> payloads, and if you feel compelled to, it must be for a good reason. In my 
> mind, those reasons shouldn't come up that often in practice, since enums 
> with compound payloads are often better factored into a combination of enums 
> and structs, and single-element payloads are best left unlabeled, like `some` 
> or `string`/`number`/`array`/`object`.

I agree with you about factoring out compound payloads.  If we could pattern 
match structs as well as declare and use a `case struct` with lightweight 
syntax I’m not sure I would use compound cases at all anymore.

> - In general, pattern-matching syntax ought to behave as a mirror image of 
> the expression that constructs a matching value, with holes punched into it 
> via '_' or 'let' subpatterns. A lot of people already struggle with the 
> concept, and unnecessary divergence from the behavior of expressions is added 
> complexity. We already have too many inconsistencies in this area (implicit 
> conversions in expressions don't fire in patterns; some pattern forms are 
> artificially hardcoded to only look up enum cases; there are weird and 
> technically redundant forms like "is T") that make learning patterns 
> difficult.

This is a fair point.

> 
> -Joe

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

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

[Matthew Johnson via swift-evolution]

>   • What is your evaluation of the proposal?

+1.  I am very happy with the tradeoffs made in the revision of this proposal.  
It feels like the right step for Swift 4.  It updates enum cases to align with 
the general direction Swift has taken.  This improves consistency now and 
provides the right foundation for the future enhancements.

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

Yes, enum cases as they exist in Swift 3.1 are a bit out of sync with the rest 
of the language.  This proposal addresses this directly.

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

Yes, very much.

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

I have followed all of the relevant threads and drafts closely and provided 
feedback regularly.  The final draft shows that the authors have done great job 
of listening to the community and incorporating feedback.  Thank you very much 
for continuing to push this forward!

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