> On Jul 19, 2017, at 16:16, Howard Lovatt via swift-evolution
> <[email protected]> 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_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
