[swift-evolution] Open Issues Affecting Standard Library API Stability
dabrahams at apple.com
Wed Jul 6 20:29:17 CDT 2016
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.
>> 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”.
>> UnicodeScalar.init(Int) should be failable.
>> 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
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.
>> String(count:, repeatedValue:) and String.append() are ambiguous without an explicit cast to Character.
>> Rename the ~LiteralConvertible protocols according to the resolution of the proposal currently under review.
> A separate review.
More information about the swift-evolution