Re: [swift-evolution] [pitch] Substring performance affordances

on Wed Jun 28 2017, Ben Cohen wrote: > Hi swift-evolution, > > Below is a short pitch for some performance improvements to be made to String > to accommodate > Substrings. > > As outlined in SE-0163, the more general question of implicit conversion from > Substring

Re: [swift-evolution] [pitch] Substring performance affordances

> On Jun 28, 2017, at 10:26 AM, rintaro ishizaki wrote: > > Does this mean it's guaranteed that Substring.hashValue is always equal to > String.hashValue? Yes. ___ swift-evolution mailing list swift-evolution@swift.org

Re: [swift-evolution] [pitch] Substring performance affordances

> On Jun 28, 2017, at 2:41 PM, David Hart wrote: > > Should authors use StringProtocol or String as often as possible? Our general advice is to stick with String. Most APIs would be simpler and clearer just using String rather than being made generic (which itself can come

Re: [swift-evolution] [pitch] Substring performance affordances

Purely additive, so +1 from me. Side note, I’m wondering how problematic these same discussions will be in third-party library code. Should authors use StringProtocol or String as often as possible? > On 28 Jun 2017, at 18:37, Ben Cohen via swift-evolution > wrote:

Re: [swift-evolution] [pitch] Substring performance affordances

Hi, Just a quick question. Does this mean it's guaranteed that Substring.hashValue is always equal to String.hashValue? ``` let foobar: String = "foo bar" let sliced: Substring = foobar.suffix(3) let bar = "bar" bar.hashValue == sliced.hashValue // guaranteed? ``` 2017-06-29 1:37 GMT+09:00

[swift-evolution] [pitch] Substring performance affordances

Hi swift-evolution, Below is a short pitch for some performance improvements to be made to String to accommodate Substrings. As outlined in SE-0163, the more general question of implicit conversion from Substring to String was deferred pending feedback on the initial implementation. To date,