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

[Erica Sadun]

> On Jul 5, 2016, at 11:50 PM, 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 <mailto: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.
>> 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.
>> withUnsafePointer shouldn't take its argument as inout.
> Jordan has objections, see https://bugs.swift.org/browse/SR-1956 <https://bugs.swift.org/browse/SR-1956>

These batch together but I'm thinking the latter three will have much more debate. (The first one can be a quick hit.) I'll get these topics started in a separate thread.

>> UnicodeScalar.init(Int) should be failable.
> Obvious.
> 
>> 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.

These string items  naturally batch together


>> Rename the ~LiteralConvertible protocols according to the resolution of the proposal currently under review.
> A separate review.


I think Matthew Johnson has this under control

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