> On Feb 27, 2017, at 9:53 PM, Brent Royal-Gordon <br...@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@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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
