> On Jul 5, 2016, at 11:50 PM, Dmitri Gribenko via swift-evolution > <[email protected]> wrote: > > On Tue, Jul 5, 2016 at 9:24 PM, Chris Lattner <[email protected] > <mailto:[email protected]>> wrote: >> On Jul 5, 2016, at 6:57 PM, Dmitri Gribenko via swift-evolution >> <[email protected]> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
