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

[Daniel Duan via swift-evolution]

I prefer patterns and matching cases have a many-to-one relation.

Keep in mind, our goal is to make match site more readable/teachable. I’d 
venture to say that given the definition of “Color”, this pattern is really 
unreadable. So is this kind of attempt to disambiguate, if we allow mixture of 
long/short forms:

case .color(hue: _, _, let alpha): // yuck


> On Apr 2, 2017, at 11:46 PM, Brent Royal-Gordon  
> wrote:
> 
>> On Apr 2, 2017, at 11:17 PM, Daniel Duan via swift-evolution 
>> > wrote:
>> 
>>> On Apr 2, 2017, at 11:10 PM, Xiaodi Wu >> > wrote:
>>> 
>>> This rule cannot hold. You cannot have the shorthand syntax you propose, 
>>> disallow mixing of shorthand syntax and the longer form, *and* allow `_` to 
>>> substitute for any pattern without a label.
>>> 
>>> ```
>>> enum E {
>>>   case foo(a: Int, b: Int, c: Int)
>>>   case foo(a: String, c: String, e: String)
>>> }
>>> 
>>> let e = /* instance of E */
>>> 
>>> switch e {
>>> case foo(let a, _, _):
>>>   // what type is `a` here?
>>>   break
>>> default:
>>>   fatalError()
>>> }
>>> ```
> 
>> 
> 
>> That seems like straight up ambiguity with or without restriction on the 
>> label though? This kind of usability problem should and is discouraged by 
>> the proposed solution.
> 
> Let's make it a little more reasonable:
> 
>   enum Color {
>   case color(red: CGFloat, green: CGFloat, blue: CGFloat, alpha: 
> CGFloat)
>   case color(hue: CGFloat, saturation: CGFloat, value: CGFloat, 
> alpha: CGFloat)
>   }
> 
>   let c: Color = …
>   
>   switch c {
>   case .color(_, _, _, let alpha):
>   …
>   }
> 
> Interestingly, in this example it would probably be appropriate to match both 
> cases. I wonder if that's true in the general case.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 

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

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

[Brent Royal-Gordon via swift-evolution]

> On Apr 2, 2017, at 11:17 PM, Daniel Duan via swift-evolution 
>  wrote:
> 
>> On Apr 2, 2017, at 11:10 PM, Xiaodi Wu > > wrote:
>> 
>> This rule cannot hold. You cannot have the shorthand syntax you propose, 
>> disallow mixing of shorthand syntax and the longer form, *and* allow `_` to 
>> substitute for any pattern without a label.
>> 
>> ```
>> enum E {
>>   case foo(a: Int, b: Int, c: Int)
>>   case foo(a: String, c: String, e: String)
>> }
>> 
>> let e = /* instance of E */
>> 
>> switch e {
>> case foo(let a, _, _):
>>   // what type is `a` here?
>>   break
>> default:
>>   fatalError()
>> }
>> ```

> 

> That seems like straight up ambiguity with or without restriction on the 
> label though? This kind of usability problem should and is discouraged by the 
> proposed solution.

Let's make it a little more reasonable:

enum Color {
case color(red: CGFloat, green: CGFloat, blue: CGFloat, alpha: 
CGFloat)
case color(hue: CGFloat, saturation: CGFloat, value: CGFloat, 
alpha: CGFloat)
}

let c: Color = …

switch c {
case .color(_, _, _, let alpha):
…
}

Interestingly, in this example it would probably be appropriate to match both 
cases. I wonder if that's true in the general case.

-- 
Brent Royal-Gordon
Architechies

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

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

[Daniel Duan via swift-evolution]

That seems like straight up ambiguity with or without restriction on the label 
though? This kind of usability problem should and is discouraged by the 
proposed solution.

> On Apr 2, 2017, at 11:10 PM, Xiaodi Wu  wrote:
> 
> On Sat, Apr 1, 2017 at 3:38 PM, Daniel Duan  > wrote:
> 
> 
>> 4.
>> The proposal does not explore what happens when the proposed prohibition on 
>> "mixing and matching" the proposed sugared and unsugared pattern matching 
>> runs up against associated values that have a mix of labeled and unlabeled 
>> parameters, and pattern matching user cases where the user does not wish to 
>> bind all of the arguments.
>> 
>> Given `case foo(a: Int, String, b: Int, String)`, the only sensible 
>> interpretation of the rules for sugared syntax would allow the user to 
>> choose any name for some but not all of the labels. If the user wishes to 
>> bind only `b`, however, he or she will need to navigate a puzzling set of 
>> rules that are not spelled out in the proposal:
>> 
>> ```
>> case foo(a: _, _, b: let b, _)
>> // this is definitely allowed
>> 
>> case foo(a: _, _, b: let myVar, _)
>> // this is also definitely allowed
>> 
>> // but...
>> case foo(_, _, b: let myVar, _)
>> // is this allowed, or must the user explicitly state and not bind `a`?
>> 
>> // ...and with respect to the sugared version...
>> case foo(_, _, let b, _)
>> // is this allowed, or must the user explicitly state and not bind `a`?
>> ```
>> 
> 
> Good point. To make up for this: `_` can substitute any sub pattern, which is 
> something that this proposal doesn’t change but definitely worth spelling 
> out.  
> 
> This rule cannot hold. You cannot have the shorthand syntax you propose, 
> disallow mixing of shorthand syntax and the longer form, *and* allow `_` to 
> substitute for any pattern without a label.
> 
> ```
> enum E {
>   case foo(a: Int, b: Int, c: Int)
>   case foo(a: String, c: String, e: String)
> }
> 
> let e = /* instance of E */
> 
> switch e {
> case foo(let a, _, _):
>   // what type is `a` here?
>   break
> default:
>   fatalError()
> }
> ```
> 

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

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

[Xiaodi Wu via swift-evolution]

On Sat, Apr 1, 2017 at 3:38 PM, Daniel Duan  wrote:



> 4.
> The proposal does not explore what happens when the proposed prohibition
> on "mixing and matching" the proposed sugared and unsugared pattern
> matching runs up against associated values that have a mix of labeled and
> unlabeled parameters, and pattern matching user cases where the user does
> not wish to bind all of the arguments.
>
> Given `case foo(a: Int, String, b: Int, String)`, the only sensible
> interpretation of the rules for sugared syntax would allow the user to
> choose any name for some but not all of the labels. If the user wishes to
> bind only `b`, however, he or she will need to navigate a puzzling set of
> rules that are not spelled out in the proposal:
>
> ```
> case foo(a: _, _, b: let b, _)
> // this is definitely allowed
>
> case foo(a: _, _, b: let myVar, _)
> // this is also definitely allowed
>
> // but...
> case foo(_, _, b: let myVar, _)
> // is this allowed, or must the user explicitly state and not bind `a`?
>
> // ...and with respect to the sugared version...
> case foo(_, _, let b, _)
> // is this allowed, or must the user explicitly state and not bind `a`?
> ```
>
>
> Good point. To make up for this: `_` can substitute any sub pattern, which
> is something that this proposal doesn’t change but definitely worth
> spelling out.
>

This rule cannot hold. You cannot have the shorthand syntax you propose,
disallow mixing of shorthand syntax and the longer form, *and* allow `_` to
substitute for any pattern without a label.

```
enum E {
  case foo(a: Int, b: Int, c: Int)
  case foo(a: String, c: String, e: String)
}

let e = /* instance of E */

switch e {
case foo(let a, _, _):
  // what type is `a` here?
  break
default:
  fatalError()
}
```
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

The contract is not merely or principally between you, the author of the
type, and the author of the protocol. In fact, the author of the protocol
doesn't have to know or care that your type exists.

The key and salient contract is between you, author of the type, and the
users of the type. You are the vendor of an API, and by stating a
conformance, you are making a guarantee to your users about the API of your
type.


On Sun, Apr 2, 2017 at 19:58 Daniel Duan  wrote:

> On Apr 2, 2017, at 5:12 PM, Xiaodi Wu  wrote:
>
> On Sun, Apr 2, 2017 at 6:30 PM, Daniel Duan  wrote:
>
> 
>
> The key distinction we need to decide here is whether case labels are
> “cosmetic”. We don’t allow declaration of separate parameter name and
> internal name for associated values. I interpret that as we are enforcing
> the syntax sugar in function declaration where user can use one symbol to
> represent both:
>
> func f(x: Int) // is the same as func f(x x: Int)
>
> It’s tempting to treat matching an enum value against a pattern as
> assigning a function value to a variable.
>
>
> Sorry, I am not sure I understand this sentence.
>
>
> Aka viewing the case pattern as simply an compound variable assignment as
> envisioned in the SE-0111 commentary. This way of the labels would be
> "cosmetic".
>
>
> I'm sorry. Still don't understand :(
>
> I have a very simple understanding of what makes something "cosmetic."
> Simply, it's something that the API author can write, which the API
> consumer can choose to read but is never (or, at least, rarely) required to
> write.
>
>
> If that’s what we are doing, it makes perfect sense to say we get
> “ultimate glory” here with patterns. Meaning, as you suggested, we consider
> the case labels “cosmetic”. It’s really just tho parameter name in a
> function (the first of the two “x” in code comment above.
>
> But that’s kind of a stretch isn’t it? An enum value is very different
> compared to a function value. Yes, there happen to be a function that
> constructs this enum value that’s declared when user declare a case, that
> function gets as much resemblance as any other. But the enum value it self
> deserves more consideration. Telling the user “do these things that you do
> with a function value” just makes pattern matching harder to explain,
> because we are *not* assigning nor invoking function values.
>
>
> Ah, I see. You think of the associated value as something distinct from
> the declaration used to initialize it. However, there is no spelling for an
> associated value other than what is used to initialize it. Given `case
> foo(bar: Int, baz: Int, boo: Int)`, previously, the full name of the case
> was `foo` and the associated value was `(bar: Int, baz: Int, boo: Int)`.
> Your proposal causes the full name of the case instead to be
> `foo(bar:baz:boo:)` and the associated value to be `(Int, Int, Int)`. Is
> that not your understanding of it?
>
>
> Yes
>
> Pattern matching is just a matter of (a) indicating what case you want to
> identify with the pattern; and (b) what parts of the associated value you
> wish to match or to bind to variables. Part (a) is done by writing the
> name, either the base name or in full (i.e. either `foo` or
> `foo(bar:baz:boo:)`). Part (b) is done by writing `let myVariableName` in
> the intended positions.
>
>
> What I left out is that the internal/parameter names of a function are
> non-optional part of its signature (one must use exact parameter names to
> implement a method in a protocol, for example).
>
>
> That's not true, and if we change Swift's rules to make it true, my own
> code would become pervasively broken, and I suspect many others' code too.
>
> My apologies, not sure where I got that impression.
>
> ```
> protocol P {
> func foo(_ bar: Int, _ baz: Int)
> }
>
> extension P {
> func foo(_ a: Int, _ b: Int) {
> print("Hello from P!")
> }
> }
>
> struct S : P {
> func foo(_ x: Int, _ y: Int) {
> print("Hello world!")
> }
> }
>
> struct T : P { }
>
> let p: P = S()
> p.foo(42, 42) // "Hello world!"
> let q: P = T()
> q.foo(42, 42) // "Hello from P!"
> ```
>
> I prefer treating labels in case pattern matching the same way we treat
> parameter names in protocol method implementation (due to  the symmetry
> between constructing/deconstructing body mentioned in my previous comments).
>
>
> Independent of the how internal names of a function are handled, I would
> strongly disagree with this idea as well. Implementing a protocol is the
> act of an API author--i.e., you are opting a type into a contract about its
> API. Pattern matching is the act of an API user. Swift has always observed
> a sharp differentiation between these two activities; it is, in essence,
> the dividing line between internal and not internal. We absolutely should
> not design pattern matching to parallel rules for API contracts.
>
> I’m not satisfied by your definition of API author/user. When I conform my
> type to, say, 

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

[Xiaodi Wu via swift-evolution]

On Sun, Apr 2, 2017 at 1:03 AM, Daniel Duan  wrote:

>
> On Apr 1, 2017, at 2:54 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Sat, Apr 1, 2017 at 3:38 PM, Daniel Duan  wrote:
>
>> Thanks again for a detailed review. I have a few comments inline.
>>
>> On Apr 1, 2017, at 9:50 AM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> • Does this proposal fit well with the feel and direction of Swift?
>>>
>>
>> The "Pattern consistency" section does not align well with the feel and
>> direction of Swift. Specifically, it does not explore some of the
>> difficulties that arise from the proposed rules, adopts some of the same
>> shortcomings that required revision for SE-0111, and deviates from some of
>> the anticipated fixes for those shortcomings outlined in the core team's
>> "update and commentary" to SE-0111.
>>
>> It is not the case that the design proposed is "a consequence of no
>> longer relying on tuple patterns," in that it is not the inevitable result
>> that falls out of that decision.
>>
>>
>> The text in this revision may be poorly phrased. The connection, as I
>> pointed out in an previous thread, is that we need to define syntax for
>> enum pattern matching because the one we’ve been using in Swift 3 is tuple
>> pattern’s syntax, which is now distinct and separate.
>>
>
> What I'm saying here is that, although _some_ change becomes necessary,
> the particular changes proposed here are not themselves "a consequence of
> no longer relying on tuple patterns."
>
> Put another way, given `enum E { case foo(bar: Int, baz: Int) }`, not
> being allowed to write `switch e { case foo(let a, let b): break }` is
> *not* an inevitable consequence of moving away from tuple patterns. Since
> the particular proposed changes break more existing source code than is
> strictly necessary for moving away from tuple-based pattern matching, those
> choices require stringent justification.
>
> I will detail the alternative design that requires the fewest deviations
>> or special rules, and breaks the least code extant today, later on. First,
>> the shortcomings:
>>
>> 1.
>> The proposed rules for pattern matching are a source-breaking change, and
>> are *not* the most minimal such change given the abandoning of tuples (see
>> alternative below). However, the proposal does not engage with the core
>> team's Swift 4 criteria for source-breaking changes with respect to the
>> proposed "stricter rules" for pattern matching. There is no text at all
>> about why specifically having the compiler encourage local _variable_ names
>> to match argument labels resolves an active harm that outweighs the goal of
>> preserving the greatest possible source compatibility.
>>
>>
>> With this proposal, user can still use local variable names. It is true
>> that if there are many ways to achieve the same thing, the compiler would
>> be encouraging user to do that thing. But that puts a cost on the compiler,
>> new users and experienced readers in unfamiliar codebases. This is (albeit
>> not to a satisfactory degree, it seems) pointed out in the motivation
>> section.
>>
>> As for source compatibility, Swift 3 code should continue to work with
>> warnings. Swift 4 mode would issue errors along with fix-its, which the
>> migrator can leverage. Depends on core team/community’s implementor
>> resource, there’s even a chance that this change would roll out one version
>> later (warning in 4.X, error in 5.Y). In theory, the migration hurdle can
>> be minimized.
>>
>
> Many syntactic changes can be migrated in this way, but for Swift 4, that
> would only be justified when the existing syntax meets a high bar for being
> harmful. Again, the overarching theme of my response is that I don't think
> the proposed "stricter rules" offer much more harm mitigation than
> significantly less source-breaking designs for pattern matching, and I
> don't see anything in the proposal text that discusses the issue or
> justifies the particular design over less source-breaking alternatives.
>
>
>> OTOH, the proposal does outline a major use case for a local variable
>> name that does not match the argument label: `param` vs `parameter`.
>> Widely-respected style guides in various languages encourage unabbreviated
>> and descriptive API names but much more concise local variable names. This
>> is a legitimate and good practice being actively discouraged by the sugared
>> rules.
>>
>>
>> This not a counterpoint, but I personally think using shortened names is
>> not something to be encouraged. A (admittedly quirky) practice some of us
>> inherited from the Cocoa style guideline is to use real, complete words for
>> variable names. I’d like to think that The Swift API Design Guidelines are
>> aligned in spirit on this matter - “clarity is more important than
>> brevity”. (incidentally, the guidelines’s code samples don’t contain
>> partial-word variables anywhere).
>>
>
> 

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

[Daniel Duan via swift-evolution]

> On Apr 1, 2017, at 2:54 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> On Sat, Apr 1, 2017 at 3:38 PM, Daniel Duan  > wrote:
> Thanks again for a detailed review. I have a few comments inline.
> 
>> On Apr 1, 2017, at 9:50 AM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>>  • Does this proposal fit well with the feel and direction of Swift?
>> 
>> The "Pattern consistency" section does not align well with the feel and 
>> direction of Swift. Specifically, it does not explore some of the 
>> difficulties that arise from the proposed rules, adopts some of the same 
>> shortcomings that required revision for SE-0111, and deviates from some of 
>> the anticipated fixes for those shortcomings outlined in the core team's 
>> "update and commentary" to SE-0111.
>> 
>> It is not the case that the design proposed is "a consequence of no longer 
>> relying on tuple patterns," in that it is not the inevitable result that 
>> falls out of that decision. 
> 
> The text in this revision may be poorly phrased. The connection, as I pointed 
> out in an previous thread, is that we need to define syntax for enum pattern 
> matching because the one we’ve been using in Swift 3 is tuple pattern’s 
> syntax, which is now distinct and separate.
> 
> What I'm saying here is that, although _some_ change becomes necessary, the 
> particular changes proposed here are not themselves "a consequence of no 
> longer relying on tuple patterns."
> 
> Put another way, given `enum E { case foo(bar: Int, baz: Int) }`, not being 
> allowed to write `switch e { case foo(let a, let b): break }` is *not* an 
> inevitable consequence of moving away from tuple patterns. Since the 
> particular proposed changes break more existing source code than is strictly 
> necessary for moving away from tuple-based pattern matching, those choices 
> require stringent justification.
> 
>> I will detail the alternative design that requires the fewest deviations or 
>> special rules, and breaks the least code extant today, later on. First, the 
>> shortcomings:
>> 
>> 1.
>> The proposed rules for pattern matching are a source-breaking change, and 
>> are *not* the most minimal such change given the abandoning of tuples (see 
>> alternative below). However, the proposal does not engage with the core 
>> team's Swift 4 criteria for source-breaking changes with respect to the 
>> proposed "stricter rules" for pattern matching. There is no text at all 
>> about why specifically having the compiler encourage local _variable_ names 
>> to match argument labels resolves an active harm that outweighs the goal of 
>> preserving the greatest possible source compatibility.
> 
> With this proposal, user can still use local variable names. It is true that 
> if there are many ways to achieve the same thing, the compiler would be 
> encouraging user to do that thing. But that puts a cost on the compiler, new 
> users and experienced readers in unfamiliar codebases. This is (albeit not to 
> a satisfactory degree, it seems) pointed out in the motivation section. 
> 
> As for source compatibility, Swift 3 code should continue to work with 
> warnings. Swift 4 mode would issue errors along with fix-its, which the 
> migrator can leverage. Depends on core team/community’s implementor resource, 
> there’s even a chance that this change would roll out one version later 
> (warning in 4.X, error in 5.Y). In theory, the migration hurdle can be 
> minimized.
> 
> Many syntactic changes can be migrated in this way, but for Swift 4, that 
> would only be justified when the existing syntax meets a high bar for being 
> harmful. Again, the overarching theme of my response is that I don't think 
> the proposed "stricter rules" offer much more harm mitigation than 
> significantly less source-breaking designs for pattern matching, and I don't 
> see anything in the proposal text that discusses the issue or justifies the 
> particular design over less source-breaking alternatives.
> 
>> 
>> OTOH, the proposal does outline a major use case for a local variable name 
>> that does not match the argument label: `param` vs `parameter`. 
>> Widely-respected style guides in various languages encourage unabbreviated 
>> and descriptive API names but much more concise local variable names. This 
>> is a legitimate and good practice being actively discouraged by the sugared 
>> rules.
> 
> This not a counterpoint, but I personally think using shortened names is not 
> something to be encouraged. A (admittedly quirky) practice some of us 
> inherited from the Cocoa style guideline is to use real, complete words for 
> variable names. I’d like to think that The Swift API Design Guidelines are 
> aligned in spirit on this matter - “clarity is more important than brevity”. 
> (incidentally, the guidelines’s code samples don’t contain partial-word 
> variables 

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

[Xiaodi Wu via swift-evolution]

On Sat, Apr 1, 2017 at 3:38 PM, Daniel Duan  wrote:

> Thanks again for a detailed review. I have a few comments inline.
>
> On Apr 1, 2017, at 9:50 AM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> • Does this proposal fit well with the feel and direction of Swift?
>>
>
> The "Pattern consistency" section does not align well with the feel and
> direction of Swift. Specifically, it does not explore some of the
> difficulties that arise from the proposed rules, adopts some of the same
> shortcomings that required revision for SE-0111, and deviates from some of
> the anticipated fixes for those shortcomings outlined in the core team's
> "update and commentary" to SE-0111.
>
> It is not the case that the design proposed is "a consequence of no longer
> relying on tuple patterns," in that it is not the inevitable result that
> falls out of that decision.
>
>
> The text in this revision may be poorly phrased. The connection, as I
> pointed out in an previous thread, is that we need to define syntax for
> enum pattern matching because the one we’ve been using in Swift 3 is tuple
> pattern’s syntax, which is now distinct and separate.
>

What I'm saying here is that, although _some_ change becomes necessary, the
particular changes proposed here are not themselves "a consequence of no
longer relying on tuple patterns."

Put another way, given `enum E { case foo(bar: Int, baz: Int) }`, not being
allowed to write `switch e { case foo(let a, let b): break }` is *not* an
inevitable consequence of moving away from tuple patterns. Since the
particular proposed changes break more existing source code than is
strictly necessary for moving away from tuple-based pattern matching, those
choices require stringent justification.

I will detail the alternative design that requires the fewest deviations or
> special rules, and breaks the least code extant today, later on. First, the
> shortcomings:
>
> 1.
> The proposed rules for pattern matching are a source-breaking change, and
> are *not* the most minimal such change given the abandoning of tuples (see
> alternative below). However, the proposal does not engage with the core
> team's Swift 4 criteria for source-breaking changes with respect to the
> proposed "stricter rules" for pattern matching. There is no text at all
> about why specifically having the compiler encourage local _variable_ names
> to match argument labels resolves an active harm that outweighs the goal of
> preserving the greatest possible source compatibility.
>
>
> With this proposal, user can still use local variable names. It is true
> that if there are many ways to achieve the same thing, the compiler would
> be encouraging user to do that thing. But that puts a cost on the compiler,
> new users and experienced readers in unfamiliar codebases. This is (albeit
> not to a satisfactory degree, it seems) pointed out in the motivation
> section.
>
> As for source compatibility, Swift 3 code should continue to work with
> warnings. Swift 4 mode would issue errors along with fix-its, which the
> migrator can leverage. Depends on core team/community’s implementor
> resource, there’s even a chance that this change would roll out one version
> later (warning in 4.X, error in 5.Y). In theory, the migration hurdle can
> be minimized.
>

Many syntactic changes can be migrated in this way, but for Swift 4, that
would only be justified when the existing syntax meets a high bar for being
harmful. Again, the overarching theme of my response is that I don't think
the proposed "stricter rules" offer much more harm mitigation than
significantly less source-breaking designs for pattern matching, and I
don't see anything in the proposal text that discusses the issue or
justifies the particular design over less source-breaking alternatives.


> OTOH, the proposal does outline a major use case for a local variable name
> that does not match the argument label: `param` vs `parameter`.
> Widely-respected style guides in various languages encourage unabbreviated
> and descriptive API names but much more concise local variable names. This
> is a legitimate and good practice being actively discouraged by the sugared
> rules.
>
>
> This not a counterpoint, but I personally think using shortened names is
> not something to be encouraged. A (admittedly quirky) practice some of us
> inherited from the Cocoa style guideline is to use real, complete words for
> variable names. I’d like to think that The Swift API Design Guidelines are
> aligned in spirit on this matter - “clarity is more important than
> brevity”. (incidentally, the guidelines’s code samples don’t contain
> partial-word variables anywhere).
>

We're talking _local_ variables: local variables aren't API. There are
many, many examples of single-letter variables in the design guidelines.
For example, `x = y.union(z)` has three of them.


>
> This would be merely annoying and not harmful if we could guarantee that
> it only means 

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

[Daniel Duan via swift-evolution]

Thanks again for a detailed review. I have a few comments inline.

> On Apr 1, 2017, at 9:50 AM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
>   • Does this proposal fit well with the feel and direction of Swift?
> 
> The "Pattern consistency" section does not align well with the feel and 
> direction of Swift. Specifically, it does not explore some of the 
> difficulties that arise from the proposed rules, adopts some of the same 
> shortcomings that required revision for SE-0111, and deviates from some of 
> the anticipated fixes for those shortcomings outlined in the core team's 
> "update and commentary" to SE-0111.
> 
> It is not the case that the design proposed is "a consequence of no longer 
> relying on tuple patterns," in that it is not the inevitable result that 
> falls out of that decision.

The text in this revision may be poorly phrased. The connection, as I pointed 
out in an previous thread, is that we need to define syntax for enum pattern 
matching because the one we’ve been using in Swift 3 is tuple pattern’s syntax, 
which is now distinct and separate.

> I will detail the alternative design that requires the fewest deviations or 
> special rules, and breaks the least code extant today, later on. First, the 
> shortcomings:
> 
> 1.
> The proposed rules for pattern matching are a source-breaking change, and are 
> *not* the most minimal such change given the abandoning of tuples (see 
> alternative below). However, the proposal does not engage with the core 
> team's Swift 4 criteria for source-breaking changes with respect to the 
> proposed "stricter rules" for pattern matching. There is no text at all about 
> why specifically having the compiler encourage local _variable_ names to 
> match argument labels resolves an active harm that outweighs the goal of 
> preserving the greatest possible source compatibility.

With this proposal, user can still use local variable names. It is true that if 
there are many ways to achieve the same thing, the compiler would be 
encouraging user to do that thing. But that puts a cost on the compiler, new 
users and experienced readers in unfamiliar codebases. This is (albeit not to a 
satisfactory degree, it seems) pointed out in the motivation section. 

As for source compatibility, Swift 3 code should continue to work with 
warnings. Swift 4 mode would issue errors along with fix-its, which the 
migrator can leverage. Depends on core team/community’s implementor resource, 
there’s even a chance that this change would roll out one version later 
(warning in 4.X, error in 5.Y). In theory, the migration hurdle can be 
minimized. 

> 
> OTOH, the proposal does outline a major use case for a local variable name 
> that does not match the argument label: `param` vs `parameter`. 
> Widely-respected style guides in various languages encourage unabbreviated 
> and descriptive API names but much more concise local variable names. This is 
> a legitimate and good practice being actively discouraged by the sugared 
> rules.

This not a counterpoint, but I personally think using shortened names is not 
something to be encouraged. A (admittedly quirky) practice some of us inherited 
from the Cocoa style guideline is to use real, complete words for variable 
names. I’d like to think that The Swift API Design Guidelines are aligned in 
spirit on this matter - “clarity is more important than brevity”. 
(incidentally, the guidelines’s code samples don’t contain partial-word 
variables anywhere).

> 
> This would be merely annoying and not harmful if we could guarantee that it 
> only means the API user will have to use longer local names, but the natural 
> impulse on the part of thoughtful API authors would be to limit the 
> expressiveness of their labels to help out their users.
> 
> This puts API authors in an impossible bind: they need to choose labels that 
> are not too short lest it collide frequently with existing local variable 
> names (`x` and `y` would be suboptimal, for example, but there are good 
> reasons why an associated value might have arguments labeled `x` and `y`),

API authors are already in this impossible bind: whenever they export a type 
name, a method signature in an open class or a protocol, risk of collision come 
up.

When a local variable does collide with a payload label, it would be bad if the 
user accidentally used the variable _in stead of_ the actual payload value. 
Forcing users to proactively rebind the variable would make them more mindful 
for this type of mistake.

> but they also need to choose labels that are not too verbose. The safest bet 
> in this case would be not to label at all, but then they lose the 
> communicative aspect of argument labels (see point 2 below).

A more realistic version of the story: API author choose labels that make the 
most sense for the declaration and user accept the risk of collision as they 
use the API. Most of those who choose to skip labels would not 

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

[Xiaodi Wu via swift-evolution]

On Fri, Mar 31, 2017 at 12:33 PM, John McCall via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello Swift community,
>
> The review of "SE-0155: Normalize Enum Case Representation" begins now and
> runs through the Monday after next, April 10th. The proposal is available
> here:
> https://github.com/apple/swift-evolution/blob/master/
> proposals/0155-normalize-enum-case-representation.md
>
> This is the second review of this proposal.  A previous version of this
> proposal was returned for revision based on some significant concerns from
> the community.  Because this is a continuation of an existing proposal, the
> core team is still willing to consider it, despite the fact that the review
> period will end after the formal end of Phase 2.
>
> 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?
>

The general direction is, of course, correct. However, I continue to be
concerned about the details of pattern matching. I will detail those below.

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

Yes

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

The "Pattern consistency" section does not align well with the feel and
direction of Swift. Specifically, it does not explore some of the
difficulties that arise from the proposed rules, adopts some of the same
shortcomings that required revision for SE-0111, and deviates from some of
the anticipated fixes for those shortcomings outlined in the core team's
"update and commentary" to SE-0111.

It is not the case that the design proposed is "a consequence of no longer
relying on tuple patterns," in that it is not the inevitable result that
falls out of that decision. I will detail the alternative design that
requires the fewest deviations or special rules, and breaks the least code
extant today, later on. First, the shortcomings:

1.
The proposed rules for pattern matching are a source-breaking change, and
are *not* the most minimal such change given the abandoning of tuples (see
alternative below). However, the proposal does not engage with the core
team's Swift 4 criteria for source-breaking changes with respect to the
proposed "stricter rules" for pattern matching. There is no text at all
about why specifically having the compiler encourage local _variable_ names
to match argument labels resolves an active harm that outweighs the goal of
preserving the greatest possible source compatibility.

OTOH, the proposal does outline a major use case for a local variable name
that does not match the argument label: `param` vs `parameter`.
Widely-respected style guides in various languages encourage unabbreviated
and descriptive API names but much more concise local variable names. This
is a legitimate and good practice being actively discouraged by the sugared
rules.

This would be merely annoying and not harmful if we could guarantee that it
only means the API user will have to use longer local names, but the
natural impulse on the part of thoughtful API authors would be to limit the
expressiveness of their labels to help out their users.

This puts API authors in an impossible bind: they need to choose labels
that are not too short lest it collide frequently with existing local
variable names (`x` and `y` would be suboptimal, for example, but there are
good reasons why an associated value might have arguments labeled `x` and
`y`), but they also need to choose labels that are not too verbose. The
safest bet in this case would be not to label at all, but then they lose
the communicative aspect of argument labels (see point 2 below).

2.
In the "update and commentary" revising SE-0111, it was acknowledged that
"cosmetic" labels have a significant use case. Thus, the rules were changed
to allow `(_ foo: Int, _ bar: Int) -> ()` to communicate to the reader of
code that the first argument serves some purpose "foo" without forcing that
name to be part of the API, pending further revisions.

Because enum cases are currently tuples, labels can be dropped freely, and
therefore these labels are effectively "optional" parts of the API that can
be seen by the user but, at their discretion, not used. That fulfills the
use case of 

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

[Matthew Johnson via swift-evolution]

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

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

> 
>> On Feb 25, 2017, at 12:10 PM, Tino Heth via swift-evolution 
>>  wrote:
>> 
>> Maybe I'm missing something obvious (or maybe I'm just generally in favour 
>> for case classes ;-), but as the main motivation for the proposal seems to 
>> be that enum cases should be more function-like: Why is this desirable?
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[Daniel Duan via swift-evolution]

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

> On Feb 25, 2017, at 12:10 PM, Tino Heth via swift-evolution 
>  wrote:
> 
> Maybe I'm missing something obvious (or maybe I'm just generally in favour 
> for case classes ;-), but as the main motivation for the proposal seems to be 
> that enum cases should be more function-like: Why is this desirable?
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[Tino Heth via swift-evolution]

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

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

[Xiaodi Wu via swift-evolution]

That is certainly a pragmatic solution. However, it would seem to me that
it defeats the raison d'etre for the proposal. As I understand it, the
whole idea here is that enum associated values work like argument lists,
but the syntax is subtly different. Therefore, let's make the rules the
same.

If we have to introduce new keywords to make that workable, then instead of
simplifying and streamlining the language we've just added more rules to
it. In some ways, that's taking us to a very different end result. Given
recent discussion on this list over concerns that too much syntactic sugar
is being proposed that weigh down the language, we should be wary of this.


On Mon, Feb 20, 2017 at 1:53 PM, Christopher Kornher via swift-evolution <
swift-evolution@swift.org> wrote:

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

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

[Christopher Kornher via swift-evolution]

> On Feb 20, 2017, at 12:31 PM, Christopher Kornher via swift-evolution 
>  wrote:
> 
>> 
>> On Feb 18, 2017, at 6:16 AM, David Rönnqvist via swift-evolution 
>> > wrote:
>> 
>> On 18 Feb 2017, at 09:30, Slava Pestov via swift-evolution 
>> > wrote:
>> 
>>> +1, two small questions:
>>> 
>>> - If two cases have the same base name but different full names, will 
>>> matching on the base name match both cases, or will it be an error?
>> 
>> I feel that it would be safer if it was an error. If the developer intends 
>> to match both cases, requiring both explicitly is a (slight) inconvenience 
>> but it's also very clear about what's going to match. 
> 
> I disagree. It is simple enough to use different base names if you don’t want 
> the cases to match. An example of why it should not be an error: I intend to 
> for errors with same base names to be handled in the same way and I don’t 
> want to enumerate all the similar cases and change code every time I add a 
> new way to construct an error. I understand that other people want the 
> equivalent of function overloading. Code that needs to access values must 
> deal with unique cases, so type safety is assured in any case.
> 
> Java enums have arguments and match on “base names” (they are quite 
> different, but the precedent exists) and I don’t think that matching on the 
> base name would be confusing. I also do not believe that it is worth adding 
> this feature if all cases are completely unique.The pain of forcing a 
> (probably small) subset of developers to use unique names is preferable to 
> complicating the language for no functional benefit, in my opinion.

A possible compromise: specify that all base names should be matched with a new 
keyword (or?) Here the keyword ```all``` is used to match all base names.

```
enum MyError : Error
{
case e( a: String )
case e( a: Int )
}

func handleError( error: MyError )
{
switch error {
case all .e :
break
}
}
```

> 
> 
>> 
>>> - What are the memory layout optimizations described here? From a first 
>>> glance this looks purely syntactic.
>>> 
>>> Slava
>>> 
 On Feb 17, 2017, at 7:26 PM, John McCall via swift-evolution 
 > wrote:
 
 Hello Swift community,
 
 The review of "SE-0155: Normalize Enum Case Representation" begins now and 
 runs through next Friday, February 26th. The proposal is available here:

 https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md
  
 
 
 Reviews are an important part of the Swift evolution process. All reviews 
 should be sent to the swift-evolution mailing list at
https://lists.swift.org/mailman/listinfo/swift-evolution 
 
 or, if you would like to keep your feedback private, directly to the 
 review manager. When replying, please try to keep the proposal link at the 
 top of the message:
 
Proposal link: 
 https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md
  
 
 
Reply text
 
Other replies
 
 What goes into a review?
 
 The goal of the review process is to improve the proposal under review 
 through constructive criticism and, eventually, determine the direction of 
 Swift. When writing your review, here are some questions you might want to 
 answer in your review:
 
• What is your evaluation of the proposal?
• Is the problem being addressed significant enough to warrant a change 
 to Swift?
• Does this proposal fit well with the feel and direction of Swift?
• If you have used other languages or libraries with a similar feature, 
 how do you feel that this proposal compares to those?
• How much effort did you put into your review? A glance, a quick 
 reading, or an in-depth study?
 
 More information about the Swift evolution process is available at 
 https://github.com/apple/swift-evolution/blob/master/process.md 
 
 
 Thank you,
 
 John McCall
 Review Manager
 ___
 swift-evolution mailing list
 swift-evolution@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-evolution 
 
>>> 
>>> 

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

[Christopher Kornher via swift-evolution]

> On Feb 18, 2017, at 6:16 AM, David Rönnqvist via swift-evolution 
>  wrote:
> 
> On 18 Feb 2017, at 09:30, Slava Pestov via swift-evolution 
> > wrote:
> 
>> +1, two small questions:
>> 
>> - If two cases have the same base name but different full names, will 
>> matching on the base name match both cases, or will it be an error?
> 
> I feel that it would be safer if it was an error. If the developer intends to 
> match both cases, requiring both explicitly is a (slight) inconvenience but 
> it's also very clear about what's going to match. 

I disagree. It is simple enough to use different base names if you don’t want 
the cases to match. An example of why it should not be an error: I intend to 
for errors with same base names to be handled in the same way and I don’t want 
to enumerate all the similar cases and change code every time I add a new way 
to construct an error. I understand that other people want the equivalent of 
function overloading. Code that needs to access values must deal with unique 
cases, so type safety is assured in any case.

Java enums have arguments and match on “base names” (they are quite different, 
but the precedent exists) and I don’t think that matching on the base name 
would be confusing. I also do not believe that it is worth adding this feature 
if all cases are completely unique.The pain of forcing a (probably small) 
subset of developers to use unique names is preferable to complicating the 
language for no functional benefit, in my opinion.


> 
>> - What are the memory layout optimizations described here? From a first 
>> glance this looks purely syntactic.
>> 
>> Slava
>> 
>>> On Feb 17, 2017, at 7:26 PM, John McCall via swift-evolution 
>>> > wrote:
>>> 
>>> Hello Swift community,
>>> 
>>> The review of "SE-0155: Normalize Enum Case Representation" begins now and 
>>> runs through next Friday, February 26th. The proposal is available here:
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md
>>>  
>>> 
>>> 
>>> Reviews are an important part of the Swift evolution process. All reviews 
>>> should be sent to the swift-evolution mailing list at
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>>> or, if you would like to keep your feedback private, directly to the review 
>>> manager. When replying, please try to keep the proposal link at the top of 
>>> the message:
>>> 
>>> Proposal link: 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md
>>>  
>>> 
>>> 
>>> Reply text
>>> 
>>> Other replies
>>> 
>>> What goes into a review?
>>> 
>>> The goal of the review process is to improve the proposal under review 
>>> through constructive criticism and, eventually, determine the direction of 
>>> Swift. When writing your review, here are some questions you might want to 
>>> answer in your review:
>>> 
>>> • What is your evaluation of the proposal?
>>> • Is the problem being addressed significant enough to warrant a change 
>>> to Swift?
>>> • Does this proposal fit well with the feel and direction of Swift?
>>> • If you have used other languages or libraries with a similar feature, 
>>> how do you feel that this proposal compares to those?
>>> • How much effort did you put into your review? A glance, a quick 
>>> reading, or an in-depth study?
>>> 
>>> More information about the Swift evolution process is available at 
>>> https://github.com/apple/swift-evolution/blob/master/process.md 
>>> 
>>> 
>>> Thank you,
>>> 
>>> John McCall
>>> Review Manager
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[Daniel Duan via swift-evolution]

Hi Slava,

> On Feb 18, 2017, at 12:30 AM, Slava Pestov via swift-evolution 
>  wrote:
> 
> +1, two small questions:
> 
> - If two cases have the same base name but different full names, will 
> matching on the base name match both cases, or will it be an error?

An error.

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

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

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

> 
> Slava
> 
>> On Feb 17, 2017, at 7:26 PM, John McCall via swift-evolution 
>> > wrote:
>> 
>> Hello Swift community,
>> 
>> The review of "SE-0155: Normalize Enum Case Representation" begins now and 
>> runs through next Friday, February 26th. The proposal is available here:
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md
>>  
>> 
>> 
>> Reviews are an important part of the Swift evolution process. All reviews 
>> should be sent to the swift-evolution mailing list at
>>  https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
>> or, if you would like to keep your feedback private, directly to the review 
>> manager. When replying, please try to keep the proposal link at the top of 
>> the message:
>> 
>>  Proposal link: 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md
>>  
>> 
>> 
>>  Reply text
>> 
>>  Other replies
>> 
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and, eventually, determine the direction of 
>> Swift. When writing your review, here are some questions you might want to 
>> answer in your review:
>> 
>>  • What is your evaluation of the proposal?
>>  • Is the problem being addressed significant enough to warrant a change 
>> to Swift?
>>  • Does this proposal fit well with the feel and direction of Swift?
>>  • If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
>>  • How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
>> 
>> More information about the Swift evolution process is available at 
>> https://github.com/apple/swift-evolution/blob/master/process.md 
>> 
>> 
>> Thank you,
>> 
>> John McCall
>> Review Manager
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[Karl Wagner via swift-evolution]

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

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

(crude example)

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

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

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

- Karl

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

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

[Rien via swift-evolution]

> On 18 Feb 2017, at 14:16, David Rönnqvist via swift-evolution 
>  wrote:
> 
> On 18 Feb 2017, at 09:30, Slava Pestov via swift-evolution 
>  wrote:
> 
>> +1, two small questions:
>> 
>> - If two cases have the same base name but different full names, will 
>> matching on the base name match both cases, or will it be an error?
> 
> I feel that it would be safer if it was an error. If the developer intends to 
> match both cases, requiring both explicitly is a (slight) inconvenience but 
> it's also very clear about what's going to match. 

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

Rien. 

> 
>> - What are the memory layout optimizations described here? From a first 
>> glance this looks purely syntactic.
>> 
>> Slava
>> 
>>> On Feb 17, 2017, at 7:26 PM, John McCall via swift-evolution 
>>>  wrote:
>>> 
>>> Hello Swift community,
>>> 
>>> The review of "SE-0155: Normalize Enum Case Representation" begins now and 
>>> runs through next Friday, February 26th. The proposal is available here:
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md
>>> 
>>> Reviews are an important part of the Swift evolution process. All reviews 
>>> should be sent to the swift-evolution mailing list at
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> or, if you would like to keep your feedback private, directly to the review 
>>> manager. When replying, please try to keep the proposal link at the top of 
>>> the message:
>>> 
>>> Proposal link: 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md
>>> 
>>> Reply text
>>> 
>>> Other replies
>>> 
>>> What goes into a review?
>>> 
>>> The goal of the review process is to improve the proposal under review 
>>> through constructive criticism and, eventually, determine the direction of 
>>> Swift. When writing your review, here are some questions you might want to 
>>> answer in your review:
>>> 
>>> • What is your evaluation of the proposal?
>>> • Is the problem being addressed significant enough to warrant a change 
>>> to Swift?
>>> • Does this proposal fit well with the feel and direction of Swift?
>>> • If you have used other languages or libraries with a similar feature, 
>>> how do you feel that this proposal compares to those?
>>> • How much effort did you put into your review? A glance, a quick 
>>> reading, or an in-depth study?
>>> 
>>> More information about the Swift evolution process is available at 
>>> https://github.com/apple/swift-evolution/blob/master/process.md
>>> 
>>> Thank you,
>>> 
>>> John McCall
>>> Review Manager
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[David Rönnqvist via swift-evolution]

> On 18 Feb 2017, at 09:30, Slava Pestov via swift-evolution 
>  wrote:
> 
> +1, two small questions:
> 
> - If two cases have the same base name but different full names, will 
> matching on the base name match both cases, or will it be an error?

I feel that it would be safer if it was an error. If the developer intends to 
match both cases, requiring both explicitly is a (slight) inconvenience but 
it's also very clear about what's going to match. 

> - What are the memory layout optimizations described here? From a first 
> glance this looks purely syntactic.
> 
> Slava
> 
>> On Feb 17, 2017, at 7:26 PM, John McCall via swift-evolution 
>>  wrote:
>> 
>> Hello Swift community,
>> 
>> The review of "SE-0155: Normalize Enum Case Representation" begins now and 
>> runs through next Friday, February 26th. The proposal is available here:
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md
>> 
>> Reviews are an important part of the Swift evolution process. All reviews 
>> should be sent to the swift-evolution mailing list at
>>  https://lists.swift.org/mailman/listinfo/swift-evolution
>> or, if you would like to keep your feedback private, directly to the review 
>> manager. When replying, please try to keep the proposal link at the top of 
>> the message:
>> 
>>  Proposal link: 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md
>> 
>>  Reply text
>> 
>>  Other replies
>> 
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and, eventually, determine the direction of 
>> Swift. When writing your review, here are some questions you might want to 
>> answer in your review:
>> 
>>  • What is your evaluation of the proposal?
>>  • Is the problem being addressed significant enough to warrant a change 
>> to Swift?
>>  • Does this proposal fit well with the feel and direction of Swift?
>>  • If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
>>  • How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
>> 
>> More information about the Swift evolution process is available at 
>> https://github.com/apple/swift-evolution/blob/master/process.md
>> 
>> Thank you,
>> 
>> John McCall
>> Review Manager
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Slava Pestov via swift-evolution]

+1, two small questions:

- If two cases have the same base name but different full names, will matching 
on the base name match both cases, or will it be an error?
- What are the memory layout optimizations described here? From a first glance 
this looks purely syntactic.

Slava

> On Feb 17, 2017, at 7:26 PM, John McCall via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0155: Normalize Enum Case Representation" begins now and 
> runs through next Friday, February 26th. The proposal is available here:
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md
>  
> 
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
>   https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
> 
>   Proposal link: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md
>  
> 
> 
>   Reply text
> 
>   Other replies
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
>   • What is your evaluation of the proposal?
>   • Is the problem being addressed significant enough to warrant a change 
> to Swift?
>   • Does this proposal fit well with the feel and direction of Swift?
>   • If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>   • How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at 
> https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> 
> Thank you,
> 
> John McCall
> Review Manager
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[Rien via swift-evolution]

> On 18 Feb 2017, at 04:26, John McCall via swift-evolution 
>  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?

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

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

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

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

Yes.

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

No

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

Quick reading.

> 

Regards,
Rien

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

> More information about the Swift evolution process is available at 
> https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> John McCall
> Review Manager
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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