[swift-evolution] Open Issues Affecting Standard Library API Stability

[Karl]

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 <swift-evolution at swift.org> wrote:
> 
> On Tue, Jul 5, 2016 at 9:24 PM, Chris Lattner <clattner at apple.com> wrote:
>> On Jul 5, 2016, at 6:57 PM, Dmitri Gribenko via swift-evolution <swift-evolution at swift.org> 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 <gribozavr at gmail.com>*/
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160706/031cc53d/attachment.html>