<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 27, 2016, at 11:42 PM, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class="">on Wed Jan 27 2016, Dave <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">Huh… Yeah, you’re right. I guess I saw “CollectionType” and<br class="">“CustomStringConvertible” or something and made a connection that<br class="">wasn’t there.<br class="">Well, FWIW, that convention (plus the occasional “HasNoun”, and<br class="">-ableType for constraining the element of custom collections) tends to<br class="">work well for me.<br class=""><br class="">What’s been the deciding factor between -Type and -able so far?<br class=""></blockquote><br class="">When there's no reasonable -able or -ible name, use -Type.<br class=""></div></div></blockquote></div><br class=""><div class="">This is where I never know whether to keep my nose out of things or just jump in. I find there are generally two kinds of protocols: verby-ones ("this is how this thing works") and nouny-ones ("this is what this thing is"). Here's the guidance I've been giving:</div><div class=""><br class=""></div><div class=""><i class="">Swift protocols describe the surface that connect a feature provider API with its consumer. Protocols establish a communication contract. They ensure a fit between each required member and the provider’s implementation. It’s like whether a virus can attach to a host cell’s receptors, or whatever the actual biological equivalent is. </i><i class="">The standard library describes protocols using nouns (typically ending in Type, e.g. MirrorPathType, MutableCollectionType, ErrorType) and adjectives (typically ending in ble, like Streamable, Strideable, ArrayLiteralConvertible). The former more commonly discuss what a conforming type is and the latter what it does. </i></div><div class=""><div class=""><i class=""><br class=""></i></div><div class=""><i class="">When naming a protocol, you’re not limited to Type and ble endings. Your protocol can be, for example, a DataProvider or a FloatConsumer. A protocol can describe a relationship DownloadProcessingDelegate or ListViewDataSource. You may implement an OutputDestination or an IntegerSink. The current API Design guidelines say "omit needless words", so you might prefer to go with DataProvider over DataProviderType or MirrorPath over MirrorPathType, but I wouldn't give much more constraint to naming beyond that.</i></div></div><div class=""><br class=""></div><div class="">For example, for "HasNoun", I'd go with something more like NounContainingType or NounSupplier.</div><div class=""><br class=""></div><div class="">Non-Abrahams Dave writes: "I like -Type for protocols that can only be used a generic constraint, and -able/-ible for protocols that can be “concrete” types.</div><div class=""><br class=""></div><div class="">And Canonical Dave replies: "But that's not how they're used. I'd have to rename Equatable and Comparable to follow that convention."</div><div class=""><br class=""></div><div class="">I agree in that I'm not convinced it's the role of a protocol to describe implementation details. (I'd say the same for method names, but that's different thread about mutability and side effects, etc). Going that way leads you to over-designated hungarian-esque guidelines that I'd rather keep loose, friendly, and sensible.</div><div class=""><br class=""></div><div class="">-- Erica</div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>