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

Reply via email to