<div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The review of "Substring performance affordances" begins now and runs through July 21, 2017. The proposal is available here:<br>
<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0183-substring-affordances.md" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0183-substring-affordances.md</a><br>
<br>
• What is your evaluation of the proposal?</blockquote><div dir="auto"><br></div><div dir="auto">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’. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
• Is the problem being addressed significant enough to warrant a change to Swift?</blockquote><div dir="auto"><br></div><div dir="auto">Yes</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
• Does this proposal fit well with the feel and direction of Swift?</blockquote><div dir="auto"><br></div><div dir="auto">It depends upon the long term view, if protocols are to be improved then no. If protocols are to remain as is then yes.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</blockquote><div dir="auto"><br></div><div dir="auto">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. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</blockquote><div dir="auto"><br></div><div dir="auto">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`. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
More information about the Swift evolution process is available at:<br>
<a href="https://github.com/apple/swift-evolution/blob/master/process.md" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/blob/master/process.md</a><br>
<br>
<br>
Thank you,<br>
<br>
Chris Lattner<br>
Review Manager<br>
<br>
<br>
_______________________________________________<br>
swift-evolution-announce mailing list<br>
<a href="mailto:swift-evolution-announce@swift.org" target="_blank">swift-evolution-announce@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution-announce" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution-announce</a><br>
</blockquote></div></div><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature">-- Howard.</div>