<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Dec 6, 2017, at 3:15 AM, Cao, Jiannan via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><meta http-equiv="Content-Type" content="text/html; charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">Hi everyone,</div><div class=""><br class=""></div><div class="">I have a question about StringProtocol.</div>Since String and Substring are adopted RangeReplaceableCollection, why StringProtocol not inherit RangeReplaceableCollection?<div class=""></div></div></div></div></blockquote><div><br class=""></div><div>With the goal of teaching a man to fish: `StringProtocol` was introduced after Swift 2.0, which means it was reviewed as part of the open evolution process and there is a proposal describing it. For `StringProtocol`, that proposal is SE-0163: <<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0163-string-revision-1.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0163-string-revision-1.md</a>></div><div><br class=""></div><div>Proposals describe not only what we are changing, but why we're doing it and why it has the chosen design. They should be your first stop when you're trying to understand why a part of Swift has a particular design. In this case, your question is answered a few paragraphs into the "proposed solution" section.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">Also consider StringProtocol could inherit:</div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><ul class=""><li class="">CustomDebugStringConvertible</li><li class="">CustomPlaygroundQuickLookable</li><li class="">CustomReflectable</li><li class="">CustomStringConvertible</li><li class="">CVarArg</li></ul></div></blockquote></div></div></div></blockquote></div><div class="">These are *not* discussed in that proposal, but the reasons are basically:</div><div class=""><br class=""></div><div class="">* The `Custom*` protocols should only ever be adopted by types which specifically need to customize those things. They correspond to features which work with any type, so you shouldn't need to know whether a given type conforms to the `Custom*` protocol.</div><div class=""><br class=""></div><div class="">* `CVarArg` indicates that a type can be passed with a C-compatible calling convention. While `String` and `Substring` can, there is no guarantee any other type which might conform to `StringProtocol` in the future would too.</div><br class=""><div class="">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div class=""><div style="font-size: 12px; " class="">-- </div><div style="font-size: 12px; " class="">Brent Royal-Gordon</div><div style="font-size: 12px; " class="">Architechies</div></div></span>
</div>
<br class=""></body></html>