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

[Dave Abrahams]

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 <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
>

-- 
Dave