on Wed Jul 06 2016, Karl <razielim-AT-gmail.com> wrote: > 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,
No, actually at the moment it takes a Collection. > 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. And a String is neither a Sequence nor a Collection. > 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. It depends on the RRC. Some RRCs can be restructured at the front or back more cheaply than in the middle. > 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? I'm sorry, I don't know what you're referring to here. If you have specific questions about a response to a PR, could you ask them in the PR? (It doesn't have to be open) >> 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 > -- Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
