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

David Waite david at alkaline-solutions.com
Fri Jan 29 01:33:20 CST 2016


Java enums are actually new subclasses (with a singleton instance).

However, the problem is one of consistency. How do you explain to developers the intuition behind these statements and the choice of UpperCamelCase vs lowerCamelCase?

import Foundation
import UIKit

let w:NSComparisonResult    = .OrderedAscending
let x:UnicodeDecodingResult = .Result("☃")
let y:UIRectEdge            = .Top
let z:CGPoint               = .zero


-DW
> On Jan 28, 2016, at 4:28 PM, Ricardo Parada via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> I am used to enum cases being UpperCamelCase from Java, although sometimes I’ve seen them in all caps.  I think of enum cases as their own type even though they are a member of the enum type.  
> 
> It is similar to inner classes in Java for example.  I would not like enum cases to be lowerCamelCase.
> 
> 
>> On Jan 23, 2016, at 1:45 PM, 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.
>> 
>>> Option set elements, on the other hand, I think really are values so it may make sense for those to be lowerCamelCase.
>> 
>> 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.
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160129/7314494e/attachment.html>


More information about the swift-evolution mailing list