Yeah, I wasn't trying to take a side, just identifying where David might have heard "Protocol" in an official Apple presentation. I'm staying out of this one. :-)
Jordan > On Apr 20, 2017, at 00:21, Gwendal Roué <gwendal.r...@gmail.com> 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_r...@apple.com > <mailto: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 <mailto: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 >>> <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 <mailto:swift-evolution@swift.org>> wrote: >>>> >>>> >>>>> Le 19 avr. 2017 à 17:23, Gwendal Roué <gwendal.r...@gmail.com >>>>> <mailto: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/ >>>> <https://swift.org/documentation/api-design-guidelines/> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
