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

[David Sweeris]

+1 on the CamelCase. Just so y’all know, though, there’s a bug in the complier involving naming collisions between cases and types. Currently (Xcode 7.2), case labels silently override type names, leading to the following error:
enum Foo {
    case Int            // Ok
    case Something(Int) // “Error: Use of undeclared type 'Int'"
    case Float(Double)  // Ok
}

That should probably get fixed *before* the API design guidelines start recommending that case labels begin with uppercase letters. (I mean, it should get fixed anyway, but it should especially get fixed before we start encouraging behavior which makes it easier to encounter.)

- Dave Sweeris

On Jan 23, 2016, at 11:18 AM, Joe Groff via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:

> 
>> On Jan 23, 2016, at 11:01 AM, David Owens II <david at owensd.io <mailto:david at owensd.io>> wrote:
>> 
>> What about enums with associated data? Those really are like types. So do we capitalize those?
>> 
>> Unless those get redesigned, there is really this contrary feel to those and other enum cases. 
> 
> Before open sourcing, I had written up some thoughts on this:
> 
> https://github.com/apple/swift/blob/master/docs/proposals/EnumStyle.rst <https://github.com/apple/swift/blob/master/docs/proposals/EnumStyle.rst>
> 
> From an API perspective, an enum 'case' behaves similarly to a factory method or initializer on a struct or class, and in native Swift we generally prefer `init`s to static factory methods when possible. We also see a lot of API design in the wild where framework authors paper over the enum-ness of their API enums with initializers:
> 
> enum Result<T> {
>   case Success(T)
>   case Error(ErrorType)
> 
>   init(success: T) { self = .Success(success) }
>   init(error: ErrorType) { self = .Error(error) }
> }
> 
> We hadn't settled on our argument label model when we originally designed and implemented enums; I feel like if we had, it's likely we would have favored cases that natively look and feel more like initializers, using labels to distinguish cases:
> 
> enum Result<T> {
>   case (success: T)
>   case (error: ErrorType)
> }
> 
> -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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160123/02d0195d/attachment.html>