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_r...@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@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@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
> 
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to