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

[Dave Abrahams]

on Tue Jul 05 2016, Dmitri Gribenko <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.

The only debate, IMO, is whether to rename or eliminate.  Anything with
“ProtoBuf” in the name is likely to be misleading.

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

-- 
Dave