[swift-dev] [Question] Why StringProtocol not inherit RangeReplaceableCollection?

Brent Royal-Gordon brent at architechies.com
Mon Dec 11 02:06:37 CST 2017


> On Dec 6, 2017, at 3:15 AM, Cao, Jiannan via swift-dev <swift-dev at swift.org> wrote:
> 
> Hi everyone,
> 
> I have a question about StringProtocol.
> Since String and Substring are adopted RangeReplaceableCollection, why StringProtocol not inherit RangeReplaceableCollection?

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: <https://github.com/apple/swift-evolution/blob/master/proposals/0163-string-revision-1.md>

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.

> Also consider StringProtocol could inherit:
> CustomDebugStringConvertible
> CustomPlaygroundQuickLookable
> CustomReflectable
> CustomStringConvertible
> CVarArg

These are *not* discussed in that proposal, but the reasons are basically:

* 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.

* `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.

-- 
Brent Royal-Gordon
Architechies

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20171211/4a8383ba/attachment.html>


More information about the swift-dev mailing list