<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
> <strong>Protocols</strong> that describe what something <strong>is</strong>
should read as
nouns (e.g. <code class="highlighter-rouge">Collection</code>).
Protocols that describe a <strong>capability</strong>
should be named using the suffixes <code class="highlighter-rouge">able</code>,
<code class="highlighter-rouge">ible</code>, or <code
class="highlighter-rouge">ing</code>
(e.g. <code class="highlighter-rouge">Equatable</code>, <code
class="highlighter-rouge">ProgressReporting</code>).<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
In short, appending Type (or something like it) i think is a
reasonable convention to keep around for non-behavioral protocols.<br>
<br>
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.) <br>
</body>
</html>