<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 </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=""> 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<S:Sequence>(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 <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On Tue, Jul 5, 2016 at 9:24 PM, Chris Lattner <<a href="mailto:clattner@apple.com" class="">clattner@apple.com</a>> wrote:<br class=""><blockquote type="cite" class="">On Jul 5, 2016, at 6:57 PM, Dmitri Gribenko via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> 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. 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! For the issues in the “low hanging fruit” list, are the changes all sufficiently "obvious”? 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(&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<i;j++){if(!(i%j)){j=0;break;}}if<br class="">(j){printf("%d\n",i);}}} /*Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com" class="">gribozavr@gmail.com</a>>*/<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>