SE-0183 - Substring performance affordances


(Chris Lattner) #1

Hello Swift community,

Context: One more small refinement proposal for Swift 4 strings. We are specifically not opening the floodgates for new proposals yet, this is this simply one potential small-scope refinement to an existing Swift 4 feature.

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

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at
https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  • What is your evaluation of the proposal?
  • Is the problem being addressed significant enough to warrant a change to Swift?
  • Does this proposal fit well with the feel and direction of Swift?
  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at:
https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

Chris Lattner
Review Manager


(Howard Lovatt) #2

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

        • 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’.

        • Is the problem being addressed significant enough to warrant a
change to Swift?

Yes

        • Does this proposal fit well with the feel and direction of Swift?

It depends upon the long term view, if protocols are to be improved then
no. If protocols are to remain as is then yes.

        • If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?

Other languages that have more powerful equivalent to protocols program to
the protocol and use them for argument and return types. This works better
than the proposal because it is much more generally applicable and doesn’t
hard code implementation details.

        • How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?

Read the proposal only, but have had problems with protocols in general and
have tried various ad-hoc solutions including solutions similar to those
proposed for `String`.

···

More information about the Swift evolution process is available at:
https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

Chris Lattner
Review Manager

_______________________________________________
swift-evolution-announce mailing list
swift-evolution-announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

--
-- Howard.


(Huon Wilson) #3

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

···

On Jul 19, 2017, at 16:16, Howard Lovatt via swift-evolution <swift-evolution@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

        • 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’.