+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 > <[email protected]> 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 <[email protected]> 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 >>> <[email protected]> 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 >>>>> <[email protected]> wrote: >>>>> >>>>> >>>>> Le 19 avr. 2017 à 17:23, Gwendal Roué <[email protected]> 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 >>>> [email protected] >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
