<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I’m quite interested in this point:</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><span style="color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class="">Figure out whether&nbsp;</span><code style="box-sizing: border-box; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 13.600000381469727px; padding: 0.2em 0px; margin: 0px; background-color: rgba(0, 0, 0, 0.0392157); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; color: rgb(51, 51, 51);" class="">RangeReplaceableCollection.replaceRange</code><span style="color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class="">&nbsp;should accept a Sequence as its argument, and if so implement it.</span></blockquote><br class=""></div><div class="">At the moment `replaceSubrange` takes a sequence, and lots of methods on RangeReplaceableCollection use that to perform their mutation operations. That means that Collections gets iterated item-by-item; for example, a String will get parsed out in to Characters and added individually to the existing string. In general, depending on which methods you use to mutate a RRC, you can expect wildly different performance characteristics. So it’s more important to fix than the name might suggest.</div><div class=""><br class=""></div><div class="">I had a PR open for this which added a Collection specialisation, but you said this could be handled in a more general way which allows for more optimised mutations. I’m curious how this would work; how does `RangeReplaceableCollection.replaceSubrange&lt;S:Sequence&gt;(range:, with: S)` call a more optimised implementation if S also conforms to Collection, if not by adding a specialisation?</div><div class=""><br class=""></div><div class=""><br class=""></div>Karl<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 6 Jul 2016, at 07:50, Dmitri Gribenko via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On Tue, Jul 5, 2016 at 9:24 PM, Chris Lattner &lt;<a href="mailto:clattner@apple.com" class="">clattner@apple.com</a>&gt; wrote:<br class=""><blockquote type="cite" class="">On Jul 5, 2016, at 6:57 PM, Dmitri Gribenko via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:<br class=""><blockquote type="cite" class=""><br class="">Hi swift-evolution,<br class=""><br class="">Dave, Max and I have compiled a list of open issues in the standard<br class="">library for which the resolutions could result non-additive API<br class="">changes. &nbsp;Having a resolution (and an implementation of the<br class="">resolution!) for these issues is blocking API stability.<br class=""><br class=""><a href="https://gist.github.com/gribozavr/37e811f12b27c6365fc88e6f9645634d" class="">https://gist.github.com/gribozavr/37e811f12b27c6365fc88e6f9645634d</a><br class=""></blockquote><br class="">Thank you for collecting this Dmitri! &nbsp;For the issues in the “low hanging fruit” list, are the changes all sufficiently "obvious”? &nbsp;If so, having one proposal tackle all of them in one sweep would be preferable to reduce process overhead.<br class=""></blockquote><br class="">My subjective assessment:<br class=""><br class=""><blockquote type="cite" class="">The global function withUnsafe[Mutable]Pointer(&amp;x) should have an argument label “to”.<br class=""></blockquote>Obvious.<br class=""><br class=""><blockquote type="cite" class="">UnicodeScalar.init(Int) should be failable.<br class=""></blockquote>Obvious.<br class=""><br class=""><blockquote type="cite" class="">withUnsafePointer shouldn't take its argument as inout.<br class=""></blockquote>Jordan has objections, see <a href="https://bugs.swift.org/browse/SR-1956" class="">https://bugs.swift.org/browse/SR-1956</a><br class=""><br class=""><blockquote type="cite" class="">Remove unsafeAddressOf. We are not aware of any real usecases for it. If there are any, it should be renamed to unsafeAddress(of:) to follow the guidelines.<br class=""></blockquote>Obvious, unless someone comes up with use cases during the review period.<br class=""><br class=""><blockquote type="cite" class="">Consider renaming or eliminating ManagedProtoBuffer.<br class="">The reason why ManagedProtoBuffer exists is to give the users an extra bit of type safety inside of the closure passed to ManagedBuffer.create().<br class=""></blockquote>Debatable.<br class=""><br class=""><blockquote type="cite" class="">String.CharacterView.Iterator should be a custom type rather than the default, to allow performance optimizations. Audit all other collections for such opportunities.<br class=""></blockquote>Obvious.<br class=""><br class=""><blockquote type="cite" class="">String(count:, repeatedValue:) and String.append() are ambiguous without an explicit cast to Character.<br class=""></blockquote>Obvious.<br class=""><br class=""><blockquote type="cite" class="">Rename the ~LiteralConvertible protocols according to the resolution of the proposal currently under review.<br class=""></blockquote>A separate review.<br class=""><br class="">Dmitri<br class=""><br class="">-- <br class="">main(i,j){for(i=2;;i++){for(j=2;j&lt;i;j++){if(!(i%j)){j=0;break;}}if<br class="">(j){printf("%d\n",i);}}} /*Dmitri Gribenko &lt;<a href="mailto:gribozavr@gmail.com" class="">gribozavr@gmail.com</a>&gt;*/<br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></div></body></html>