I seem to recall that something (maybe a WWDC session) mentioned something about protocols that in essence represent a single type would have the Protocol-suffix.
Unfortunately I couldn’t find it (yet?). The closest I’ve found so far is http://asciiwwdc.com/2014/sessions/407 <http://asciiwwdc.com/2014/sessions/407> but I’m not sure that was it. > essentially when there's a conflict between a class name and a protocol name, > we'll append protocol to the name of the protocol. David > On 19 Apr 2017, at 17:55, Gwendal Roué via swift-evolution > <swift-evolution@swift.org> wrote: > > >> Le 19 avr. 2017 à 17:23, Gwendal Roué <gwendal.r...@gmail.com> a écrit : >> >> Re: [swift-evolution] [Review] SE-0172: One-sided Ranges >> >> "RangeExpression" is an unexpected name. I was expecting "RangeProtocol", as >> in IteratorProtocol and LazySequenceProtocol. We need a consistent suffix >> for protocols that can't be named in -able, -ible, or named with a simple >> noun because the noun is already used by a concrete type. "-Protocol" should >> be that prefix: RangeProtocol. > > A detailed look at API Design Guidelines [1] shows that this subject is not > addressed: > >> • 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`). > > Nothing is said for "protocols that describe what something but can't be > named as nouns", or "protocols that describe a capability but can't be named > using the suffixes able, ible, or ing". > > For example: the name of the protocol for all ranges discussed with SE-0172 > should be addressed by the first rule (because the protocol describes what > something is rather than a capability). But that protocol can't be named > Range because Range is already taken. > > Such a situation comes rather easily: > > - in an evolving code base, when a protocol is added on top of an existing > type hierarchy which should be preserved (RangeProtocol added on top of > Range, ClosedRange, etc.) > - at the birth of a code base, when a protocol coexists with a concrete type > which rightfully deserves the noun claimed by the protocol. > > IteratorProtocol and LazySequenceProtocol have set a precedent: maybe we > should have the API Design Guidelines evolve with a third rule: > > + When a protocol can't be named with a noun, or with an `able`, `ible`, or > `ing` suffix, the protocol should be named using the suffix `Protocol` (e.g. > `IteratorProtocol`). > > What do you think? > > Gwendal Roué > [1] https://swift.org/documentation/api-design-guidelines/ > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
