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

[Dave Abrahams]

on Sat Jan 23 2016, Trent Nadeau <swift-evolution at swift.org> wrote:

> While enum cases may not be types from a compiler perspective, I think they
> are from a user's level.
>
> Consider:
>
> enum MyError: ErrorType {
>     case FileError(fileName: String)
>     case SocketError(ipAddr: String, port: Int16)
> }
>
> From a compiler perspective, it's a tagged union (one type), but for a user
> this is a set of disjoint types that happen to share the same space and
> have exhaustiveness checking, etc. It's a much more efficient and
> convenient version of multiple structs or tuples.

I don't understand how you can say MyError.FileError is a type from the
user's perspective; they don't work in most of the places you'd expect a
type to work. For example, you can't declare this function:

      func f(x: MyError.FileError) {}

The fact that some people are viewing these things as a kind of type
only makes me more motivated to change the naming convention, because
it's clear that whatever passing similarity they may have to types,
combined with the current naming convention, is strongly misleading.

> On Sat, Jan 23, 2016 at 1:49 PM, Joe Groff <jgroff at apple.com> wrote:
>
>>
>> > On Jan 23, 2016, at 10:24 AM, Trent Nadeau <tanadeau at gmail.com> 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).
>>
>> They aren't, though. I don't see much value in setting false expectations.
>>
>> -Joe
>>
>>

-- 
-Dave