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

[Kevin Lundberg]

> *Protocols* that describe what something *is* should read as nouns
(e.g. |Collection|). Protocols that describe a *capability* should be
named using the suffixes |able|, |ible|, or |ing| (e.g. |Equatable|,
|ProgressReporting|).

I personally like the idea behind the current convention for protocols
that describe a thing (IntegerType, CollectionType, etc) where there is
a suffix of Type appended to the end, so I give this specific part of
the proposal a -1. The specific wording of the protocol's name is not so
important as the recognition at a glance that this is a protocol vs a
concrete type. I like being able to infer at a glance how I'm expected
to use a specific type reference based on its name alone; otherwise I
may have to refer back to the type definition to refresh my memory of
whether or not it is in fact a protocol or is something else.

This change could also lead to confusion among some developers. For
someone who is new to Swift, would they know they should use Bool over
Boolean if they've seen both types before? Both names look reasonable to
store a boolean value, but the semantics of each type differ
significantly. Someone may try to have a type conform to Bool instead of
Boolean, which would obviously not work, but could cause some
consternation for developers who don't know the difference by heart.
Naming the protocol BooleanType at least calls out that this may not be
conceptually the same as a plain boolean value, which could make a
developer think twice before trying to use that over Bool.

Removing some common prefix from these kinds of protocols could also run
the risk of unintentionally shadowing type names, if someone wanted to
write their own Collection or Error struct or class for instance, or if
a pre-existing concrete type in their code turned out to unexpectedly
shadow a protocol in a new dependency that they want to add. These
situations would not cause any technical hiccups due to module
namespacing, but it could lead to confusion when a developer forgets to
qualify the name and tries to use one type where the other is expected.

In short, appending Type (or something like it) i think is a reasonable
convention to keep around for non-behavioral protocols.

As far as alternatives to 'Type', I personally don't like the suffix
'Protocol' as much (which is suggested as a disambiguation option in the
related standard library review), since 'Type' is shorter, feels nicer
to read, and describes the purpose of the protocol well to me. C#'s
approach of prefixing all interfaces with a capital I would be even more
succinct, but I personally don't think that approach would look nice to
read either. (PCollection, PBoolean? Ick.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160123/a1ddcae3/attachment.html>