I’m quite interested in this point: > Figure out whether RangeReplaceableCollection.replaceRange should accept a > Sequence as its argument, and if so implement it.
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. 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? Karl > On 6 Jul 2016, at 07:50, Dmitri Gribenko via swift-evolution > <[email protected]> wrote: > > On Tue, Jul 5, 2016 at 9:24 PM, Chris Lattner <[email protected]> wrote: >> On Jul 5, 2016, at 6:57 PM, Dmitri Gribenko via swift-evolution >> <[email protected]> wrote: >>> >>> Hi swift-evolution, >>> >>> Dave, Max and I have compiled a list of open issues in the standard >>> library for which the resolutions could result non-additive API >>> changes. Having a resolution (and an implementation of the >>> resolution!) for these issues is blocking API stability. >>> >>> https://gist.github.com/gribozavr/37e811f12b27c6365fc88e6f9645634d >> >> 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. > > My subjective assessment: > >> The global function withUnsafe[Mutable]Pointer(&x) should have an argument >> label “to”. > Obvious. > >> UnicodeScalar.init(Int) should be failable. > Obvious. > >> withUnsafePointer shouldn't take its argument as inout. > Jordan has objections, see https://bugs.swift.org/browse/SR-1956 > >> 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. > Obvious, unless someone comes up with use cases during the review period. > >> Consider renaming or eliminating ManagedProtoBuffer. >> The reason why ManagedProtoBuffer exists is to give the users an extra bit >> of type safety inside of the closure passed to ManagedBuffer.create(). > Debatable. > >> String.CharacterView.Iterator should be a custom type rather than the >> default, to allow performance optimizations. Audit all other collections for >> such opportunities. > Obvious. > >> String(count:, repeatedValue:) and String.append() are ambiguous without an >> explicit cast to Character. > Obvious. > >> Rename the ~LiteralConvertible protocols according to the resolution of the >> proposal currently under review. > A separate review. > > Dmitri > > -- > main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if > (j){printf("%d\n",i);}}} /*Dmitri Gribenko <[email protected]>*/ > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
