[swift-evolution] [swift-evolution-announce] SE-0183 - Substring performance affordances

[Huon Wilson]

> On Jul 19, 2017, at 16:16, Howard Lovatt via swift-evolution <swift-evolution at swift.org> wrote:
> 
> The review of "Substring performance affordances" begins now and runs through July 21, 2017. The proposal is available here:
> https://github.com/apple/swift-evolution/blob/master/proposals/0183-substring-affordances.md <https://github.com/apple/swift-evolution/blob/master/proposals/0183-substring-affordances.md>
> 
>         • What is your evaluation of the proposal?
> 
> Generally good. The reservation I have is there are an increasing number of ‘small’ proposals that paper over the limitations of protocols. If protocols could be used as a type then the methods in `StringProtocol` would return `StringProtocol` and methods would accept `StringProtocol`. Whether `String` or `StringSlice` is actually returned by a method would be irrelevant. Is it better to spend the engineering effort on improving protocols and `Self` rather than continuously ‘papering over the cracks’. 


Using protocols as types has various performance penalties (more virtual method calls, and, depending on the size of the data, allocations) and semantic downsides that would likely defeat the purpose of splitting String from Substring. It would be essentially the same as having a String can implicitly be a Substring (a slower version of something like `enum StringProtocol { case String_(String), Sub(Substring) }`) which was touched on in the string manifesto: https://github.com/apple/swift/blob/master/docs/StringManifesto.md#same-type-shared-storage

Huon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170720/cf8fd38f/attachment.html>