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

Matthew Johnson matthew at anandabits.com
Tue Feb 28 09:51:47 CST 2017


> On Feb 27, 2017, at 9:53 PM, Brent Royal-Gordon <brent at architechies.com> wrote:
> 
> 
> 
> -- 
> Brent Royal-Gordon
> Sent from my iPhone
>> On Feb 27, 2017, at 10:39 AM, Matthew Johnson via swift-evolution <swift-evolution at swift.org> 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



More information about the swift-evolution mailing list