[swift-evolution] [Pitch] Improve the API Design Guidelines about protocol naming

[Riley Testut]

+1 to the proposal, *especially* the addition of the RangeExpression protocol.

That being said, I agree with the critiques over the chosen name. I also can't remember where exactly, but I do remember at some point hearing that the -Protocol suffix should be added to protocol names if needed to disambiguate them from concrete types (and have followed this convention in my own projects).

While I actually believe taken at face value "RangeExpression" is a better name than "RangeProtocol", I believe RangeProtocol is better overall as it is more consistent with the naming conventions. (As an aside, I much preferred Swift 2's "-Type" suffix naming convention for protocols. However, since we're no longer using that, might as well be consistent with other protocol names.)

> On Apr 20, 2017, at 12:21 AM, Gwendal Roué via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Well, IteratorProtocol, LazySequenceProtocol weren't imported from ObjC.
> 
> They set a precedent for the -Protocol suffix.
> 
> Now, even if you don't like RangeProtocol, this doesn't make RangeExpression better.
> 
> "Expression" and `1...` don't belong to the same level of the language: one is a concept of that belongs to the compiler, when the other is a plain value used in a program:
> 
> When a program does `1 + 2`, it both sums two integers, and builds a expression from two other expressions and an operator. Both are true. Yet 1 is of type `Integer`, not `IntegerExpression`.
> 
> Currently all types of the standard library belong the program realm, not to the compiler realm. I wish we wouldn't break this practice, and avoid `RangeExpression`.
> 
> That's why I suggest `RangeProtocol`. Other options could be `Ranging`, `Bounds`...
> 
> Gwendal Roué
> 
> 
>> Le 19 avr. 2017 à 23:35, Jordan Rose <jordan_rose at apple.com> a écrit :
>> 
>> That was probably about the ObjC importer, which does this (appends "Protocol") when there's a class and protocol with the same name in the same module. That doesn't necessarily mean it's the right thing to put in the API guidelines, though.
>> 
>> Jordan
>> 
>> 
>>> On Apr 19, 2017, at 10:59, Gmail via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> 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 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 at swift.org> wrote:
>>>>> 
>>>>> 
>>>>> Le 19 avr. 2017 à 17:23, Gwendal Roué <gwendal.roue at 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 at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170420/02153b6c/attachment.html>