Swift case conventions for Enums


(Michael Wells) #1

I love that Swift has a published API design guidelines at https://swift.org/documentation/api-design-guidelines.html, but one thing about it bugs me: the use of UpperCamelCase for cases. I know this ship has long sailed, but why didn't the team choose lowerCamelCase for these? The current style seems inconsistent and requires an “instances are lowerCamelCase, aside from Enums” clarification.

-mw


(Joe Groff) #2

Using lowerCamelCase makes sense to me; I've proposed a similar change in the past. Doug, was any decision about enum constant case made as part of the API naming guidelines?

-Joe

···

On Dec 21, 2015, at 3:58 PM, Michael Wells via swift-evolution <swift-evolution@swift.org> wrote:

I love that Swift has a published API design guidelines at https://swift.org/documentation/api-design-guidelines.html, but one thing about it bugs me: the use of UpperCamelCase for cases. I know this ship has long sailed, but why didn't the team choose lowerCamelCase for these? The current style seems inconsistent and requires an “instances are lowerCamelCase, aside from Enums” clarification.


(Dave Abrahams) #3

I love that Swift has a published API design guidelines at https://swift.org/documentation/api-design-guidelines.html, but one thing about it bugs me: the use of UpperCamelCase for cases. I know this ship has long sailed,

It has not sailed at all. This is totally open for discussion.

but why didn't the team choose lowerCamelCase for these? The current style seems inconsistent and requires an “instances are lowerCamelCase, aside from Enums” clarification.

-mw

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

-Dave

···

On Dec 21, 2015, at 3:58 PM, Michael Wells via swift-evolution <swift-evolution@swift.org> wrote:


(Charles Kissinger) #4

Some differences of opinion here might arise from the fact that simple enums act as constants, but enums with associated values seem (to me anyway) to function much more like subtypes with RTTI built in. lowerCamelCase makes sense for the former, but UpperCamelCase for the latter.

-ck

···

On Dec 21, 2015, at 3:58 PM, Michael Wells via swift-evolution <swift-evolution@swift.org> wrote:

I love that Swift has a published API design guidelines at https://swift.org/documentation/api-design-guidelines.html, but one thing about it bugs me: the use of UpperCamelCase for cases. I know this ship has long sailed, but why didn't the team choose lowerCamelCase for these? The current style seems inconsistent and requires an “instances are lowerCamelCase, aside from Enums” clarification.

-mw

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


(Joe Groff) #5

Another reason to change the convention is that it's common to want to name cases the same as their payload type. When both use the UpperCamelCase convention, you have to disambiguate the name collision:

enum JSON {
  case String(Swift.String)
  case Array(Swift.Array<JSON>)
  /* etc. */
}

Using lowerCamelCase would avoid the collision.

-Joe

···

On Dec 21, 2015, at 3:58 PM, Michael Wells via swift-evolution <swift-evolution@swift.org> wrote:

I love that Swift has a published API design guidelines at https://swift.org/documentation/api-design-guidelines.html, but one thing about it bugs me: the use of UpperCamelCase for cases. I know this ship has long sailed, but why didn't the team choose lowerCamelCase for these? The current style seems inconsistent and requires an “instances are lowerCamelCase, aside from Enums” clarification.


(Paul Cantrell) #6

I’d support this in principle.

The current uppercase convention is widespread enough that I’d really want some sort of alias-and-deprecate mechanism if the guideline were to change.

Cheers, P

···

On Dec 21, 2015, at 5:58 PM, Michael Wells via swift-evolution <swift-evolution@swift.org> wrote:

I love that Swift has a published API design guidelines at https://swift.org/documentation/api-design-guidelines.html, but one thing about it bugs me: the use of UpperCamelCase for cases. I know this ship has long sailed, but why didn't the team choose lowerCamelCase for these? The current style seems inconsistent and requires an “instances are lowerCamelCase, aside from Enums” clarification.


(Erica Sadun) #7

I'm a camelCapsaPhile, and not ashamed to pronounce my preference for it for enum cases, for global functions, and global constants.

-- E

···

On Dec 21, 2015, at 5:23 PM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

On Dec 21, 2015, at 3:58 PM, Michael Wells via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I love that Swift has a published API design guidelines at https://swift.org/documentation/api-design-guidelines.html, but one thing about it bugs me: the use of UpperCamelCase for cases. I know this ship has long sailed, but why didn't the team choose lowerCamelCase for these? The current style seems inconsistent and requires an “instances are lowerCamelCase, aside from Enums” clarification.

Using lowerCamelCase makes sense to me; I've proposed a similar change in the past. Doug, was any decision about enum constant case made as part of the API naming guidelines?

-Joe

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


(Douglas Gregor) #8

No, we haven’t made a decision here. Thanks for the nudge!

  - Doug

···

On Dec 21, 2015, at 4:23 PM, Joe Groff <jgroff@apple.com> wrote:

On Dec 21, 2015, at 3:58 PM, Michael Wells via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I love that Swift has a published API design guidelines at https://swift.org/documentation/api-design-guidelines.html, but one thing about it bugs me: the use of UpperCamelCase for cases. I know this ship has long sailed, but why didn't the team choose lowerCamelCase for these? The current style seems inconsistent and requires an “instances are lowerCamelCase, aside from Enums” clarification.

Using lowerCamelCase makes sense to me; I've proposed a similar change in the past. Doug, was any decision about enum constant case made as part of the API naming guidelines?


(Joe Groff) #9

For non-enum constants, we use lowerCamelCase, for example Int.max, or UIColor.redColor.

-Joe

···

On Dec 21, 2015, at 9:04 PM, Charles Kissinger via swift-evolution <swift-evolution@swift.org> wrote:

On Dec 21, 2015, at 3:58 PM, Michael Wells via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I love that Swift has a published API design guidelines at https://swift.org/documentation/api-design-guidelines.html, but one thing about it bugs me: the use of UpperCamelCase for cases. I know this ship has long sailed, but why didn't the team choose lowerCamelCase for these? The current style seems inconsistent and requires an “instances are lowerCamelCase, aside from Enums” clarification.

-mw

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

Some differences of opinion here might arise from the fact that simple enums act as constants, but enums with associated values seem (to me anyway) to function much more like subtypes with RTTI built in. lowerCamelCase makes sense for the former, but UpperCamelCase for the latter.


(Jonathan Hise Kaldma) #10

-1.

Please don't change the guideline. It's good as it is.

First, there's an important precedent for UpperCamelCase enums in other languages that Swift has some kinship with, e.g. C#, Rust, and Scala. People coming to Swift from these languages immediately feel at home with the current guideline.

Second, there's an even bigger precedent for treating enums differently from other identifiers. In languages where UpperCamelCase isn't the rule, e.g. C, C++, and Java, the practice is often to name enums using UPPERCASE. This says something about how people see enums: as something that should stand out. Making them lowerCamelCase goes against this.

Finally, using UpperCamelCase makes enums much more readable when used with Swifts's ability to infer the enum type. It's immediately clear that this is an enum:

suit = .Hearts

But it's not so clear what this is:

suit = .hearts

What is hearts? Is it a property? Where does it come from? This makes the language harder to learn and harder to read.

Consistency should be a goal when it aids clarity and readability. In this case, it would make code less clear and less readable, and it would go against established practice.

/Jonathan

···

22 dec. 2015 kl. 03:38 skrev Dave Abrahams via swift-evolution <swift-evolution@swift.org>:

On Dec 21, 2015, at 3:58 PM, Michael Wells via swift-evolution <swift-evolution@swift.org> wrote:

I love that Swift has a published API design guidelines at https://swift.org/documentation/api-design-guidelines.html, but one thing about it bugs me: the use of UpperCamelCase for cases. I know this ship has long sailed,

It has not sailed at all. This is totally open for discussion.

but why didn't the team choose lowerCamelCase for these? The current style seems inconsistent and requires an “instances are lowerCamelCase, aside from Enums” clarification.

-mw

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

-Dave

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


(Sean Heber) #11

I’ve run into a few situations where the reverse is true, for example:

enum Priority {
    case Low, Default, High
}

I would not be able to use the word “default” if it was lowercase since it would conflict with the keyword. In fact, in this one project, I have at least 2 enums that would have cases that conflict with language keywords if the convention were lowercase. Just throwing this out there. :slight_smile:

l8r
Sean

···

On Dec 22, 2015, at 10:41 AM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

On Dec 21, 2015, at 3:58 PM, Michael Wells via swift-evolution <swift-evolution@swift.org> wrote:

I love that Swift has a published API design guidelines at https://swift.org/documentation/api-design-guidelines.html, but one thing about it bugs me: the use of UpperCamelCase for cases. I know this ship has long sailed, but why didn't the team choose lowerCamelCase for these? The current style seems inconsistent and requires an “instances are lowerCamelCase, aside from Enums” clarification.

Another reason to change the convention is that it's common to want to name cases the same as their payload type. When both use the UpperCamelCase convention, you have to disambiguate the name collision:

enum JSON {
  case String(Swift.String)
  case Array(Swift.Array<JSON>)
  /* etc. */
}

Using lowerCamelCase would avoid the collision.

-Joe

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


(Michel Fortin) #12

What about option sets?

···

Le 22 déc. 2015 à 10:27, Joe Groff via swift-evolution <swift-evolution@swift.org> a écrit :

For non-enum constants, we use lowerCamelCase, for example Int.max, or UIColor.redColor.

--
Michel Fortin
michel.fortin@michelf.ca
https://michelf.ca


(Joe Groff) #13

Option sets reuse the C importer logic shared with other C enum types, which we would change if we changed the enum naming convention.

-Joe

···

On Dec 22, 2015, at 8:19 AM, Michel Fortin <michel.fortin@michelf.ca> wrote:

Le 22 déc. 2015 à 10:27, Joe Groff via swift-evolution <swift-evolution@swift.org> a écrit :

For non-enum constants, we use lowerCamelCase, for example Int.max, or UIColor.redColor.

What about option sets?