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

Erica Sadun erica at ericasadun.com
Sat Jan 23 18:43:39 CST 2016

I am a fan of uppercasing global constants and functions. However, you are the only human on earth
that I have yet encountered who embraces even a slight part of this.

It's a battle I gave up on.

-- E

> On Jan 23, 2016, at 4:25 PM, David Waite via swift-evolution <swift-evolution at swift.org> wrote:
> API guidelines should probably be consistent about enum cases and static let properties
> I’ve been naming my 'static let’s in UpperCamelCase to match the convention of enums, because I often use them the same way in code. But standard types do differently, e.g.
> var initialPoint:CGPoint = .zero
> -DW
>> On Jan 23, 2016, at 11:11 AM, Joe Groff via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> On Jan 23, 2016, at 2:12 AM, Marc Knaup via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> What is the rationale behind naming enumeration cases in upper camel case?
>>> Follow case conventions: names of types, protocols and enum cases areUpperCamelCase. Everything else islowerCamelCase.
>>> let a = NSComparisonResult.OrderedSame  // refers to a value, but is upper-case
>>> let b = NSDate.distantFuture            // refers to a property/value, but is lower-case
>>> everything related to types (type names, protocol names, generic type parameter names) should be upper camel case
>>> everything else (function names, property names, variable names, etc.) should be lower camel case
>>> This is already the current and the proposed recommendation with enumeration cases being the only exception.
>>> Enumeration cases are not types.
>> I agree. It would make enum cases feel more consistent with the rest of the language to make them lowerCamelCase.
>> -Joe
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <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/20160123/906f4830/attachment.html>

More information about the swift-evolution mailing list