Swift has matured significantly in the years since this answer was written. The design guidelines now state:
Protocols that describe what something is should read as nouns (e.g.
Protocols that describe a capability should be named using the suffixes
Thank you to David James for spotting this!
Using some form of Hungarian Notation can be a good idea – to represent important concepts that cannot be encoded inside the type system. However, the fact that some identifier refers to a protocol is part of the type system in Swift (and C#), and as such any prefix or suffix only adds noise. Clear prefixes or suffixes are a better idea for concepts such as exceptions or events.
In the absence of an official style guide for Swift, we have to come up with our own, or borrow from existing guides or code. For example, the Objective-C style guide for Cocoa contains this section:
Protocols should be named according to how they group behaviors:
Most protocols group related methods that aren’t associated with any class in particular. This type of protocol should be named so that the protocol won’t be confused with a class. A common convention is to use a gerund (“...ing”) form:
NSLocking – Good.
NSLock – Poor (seems like a name for a class).
Some protocols group a number of unrelated methods (rather than create several separate small protocols). These protocols tend to be associated with a class that is the principal expression of the protocol. In these cases, the convention is to give the protocol the same name as the class.
An example of this sort of protocol is the
NSObject protocol. This protocol groups methods that you can use to query any object about its position in the class hierarchy, to make it invoke specific methods, and to increment or decrement its reference count. Because the
NSObject class provides the primary expression of these methods, the protocol is named after the class.
However, the advice of the second point is no longer applicable:
Because the namespace of classes and protocols is unified in Swift, the
NSObject protocol in Objective-C is remapped to
NSObjectProtocol in Swift. (source)
…Protocol suffix was used in order to disambiguate the protocol from the class.
The Swift Standard Library contains the protocols
Printable. These do not use the Cocoa “…ing” form, but rather the “…able” suffix to declare that any instance of this type must support a certain operation.
In a few cases where a protocol only has one relevant implementation, a “…Protocol” suffix can make sense so that the class and protocol can have the same name. However, this should be limited to such cases only.
Otherwise, the name should be some noun reflecting what operations this protocol contains. Using an “…ing” or “…able” form of a verb can be a good starting point, and such names are unlikely to conflict with class names.
EquatableProtocol is not recommendable. The name
Equating would be far better, and I do not expect any class to have the name
Equatable. In this case, the
Protocol suffix is noise.