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
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.
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:
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
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.
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.
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
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?
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-evolutionSome 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.
-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
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. :)
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
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
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?