[swift-evolution] [Review] SE-0023 API Design Guidelines

[David Waite]

> On Jan 23, 2016, at 11:45 AM, Kevin Lundberg via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Jan 23, 2016, at 1:24 PM, Trent Nadeau via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> I think it makes sense for enum cases to be UpperCamelCase as they can be thought of as scoped types (singleton types in the case of cases with no associated types).
> 
> This reasoning makes sense to me. It's also a convention that I've seen on other languages like Java and C# where enum cases are capitalized even though they aren't strictly types of their own.

In Java they are final, singleton class instances. If Boolean for example had been retrofitted to be an enum, there would be a single instance of Boolean.False in the system.

In Swift, enums are a union value type. Every “false” in swift is a new instance of the Bool enum. Bool.False is effectively a static read-only property. For enum cases like Optional.Some  which have associated data, Optional.Some is effectively a static factory method.

> 
> I think of option set elements in the same way as enums here, where each option set option can behave as an individual singleton type that represents a specific value. The way they're used reminds me a lot of how enums are typically used, just with multiple instances at once in a set instead of a single enum case.


Having static properties and methods be lower camel case and enum cases be upper camel case is inconsistent. There really is nothing special about enum cases over static members, except that switch statements know how to be comprehensive.

-DW