<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>+1 to the proposal, *especially* the addition of the RangeExpression protocol.</div><div><br></div><div>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).</div><div><br></div><div>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.)</div><div><br>On Apr 20, 2017, at 12:21 AM, Gwendal Roué via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div></div><div>Well, IteratorProtocol, LazySequenceProtocol weren't imported from ObjC.</div><div><br></div><div>They set a precedent for the -Protocol suffix.</div><div><br></div><div>Now, even if you don't like RangeProtocol, this doesn't make RangeExpression better.</div><div><br></div><div>"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:</div><div><br></div><div>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`.</div><div><br></div><div>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`.</div><div><br></div><div>That's why I suggest `RangeProtocol`. Other options could be `Ranging`, `Bounds`...</div><div><br></div><div>Gwendal Roué</div><div><br></div><div><br>Le 19 avr. 2017 à 23:35, Jordan Rose <<a href="mailto:jordan_rose@apple.com">jordan_rose@apple.com</a>> a écrit :<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><div class="">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.</div><div class=""><br class=""></div><div class="">Jordan</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 19, 2017, at 10:59, Gmail via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">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. </div><div class=""><br class=""></div><div class="">Unfortunately I couldn’t find it (yet?). The closest I’ve found so far is <a href="http://asciiwwdc.com/2014/sessions/407" class="">http://asciiwwdc.com/2014/sessions/407</a> but I’m not sure that was it.</div><div class="">> essentially when there's a conflict between a class name and a protocol name, we'll append protocol to the name of the protocol.</div><div class=""><br class=""></div><div class="">David</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 19 Apr 2017, at 17:55, Gwendal Roué via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><blockquote type="cite" class="">Le 19 avr. 2017 à 17:23, Gwendal Roué <<a href="mailto:gwendal.roue@gmail.com" class="">gwendal.roue@gmail.com</a>> a écrit :<br class=""><br class="">Re: [swift-evolution] [Review] SE-0172: One-sided Ranges<br class=""><br class="">"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.<br class=""></blockquote><br class="">A detailed look at API Design Guidelines [1] shows that this subject is not addressed:<br class=""><br class=""><blockquote type="cite" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• Protocols that describe what something is should read as nouns (e.g. `Collection`).<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• Protocols that describe a capability should be named using the suffixes `able`, `ible`, or `ing` (e.g. `Equatable`, `ProgressReporting`).<br class=""></blockquote><br class="">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".<br class=""><br class="">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.<br class=""><br class="">Such a situation comes rather easily:<br class=""><br class="">- 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.)<br class="">- at the birth of a code base, when a protocol coexists with a concrete type which rightfully deserves the noun claimed by the protocol.<br class=""><br class="">IteratorProtocol and LazySequenceProtocol have set a precedent: maybe we should have the API Design Guidelines evolve with a third rule:<br class=""><br class="">+ 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`).<br class=""><br class="">What do you think?<br class=""><br class="">Gwendal Roué<br class="">[1] <a href="https://swift.org/documentation/api-design-guidelines/" class="">https://swift.org/documentation/api-design-guidelines/</a><br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></blockquote></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>