[swift-evolution] [Proposal] Move public AutoreleasingUnsafeMutablePointer API from StdlibCore -> Objective C Overlay

Dave Abrahams dabrahams at apple.com
Fri Jul 22 17:06:48 CDT 2016

on Fri Jul 22 2016, Michael Gottesman <swift-evolution at swift.org> wrote:

>> On Jul 22, 2016, at 11:42 AM, Dave Abrahams via swift-evolution
>> <swift-evolution at swift.org> wrote:
>> on Fri Jul 22 2016, Ben Rimmington
>> <swift-evolution at swift.org
>> <mailto:swift-evolution at swift.org>>
>> wrote:
>>>> On 21 Jul 2016, at 18:02, Michael Gottesman wrote:
>>>> This is a proposal to move AutoreleasingUnsafeMutablePointer from
>>>> StdlibCore to the Objective C overlay. The reason to do this is that
>>>> ideally StdlibCore would not have any code specific to ObjC in
>>>> it. This is a small step that we can take in this direction by
>>>> moving the public API of AutoreleasingUnsafeMutablePointer to the
>>>> ObjC overlay. The way that this would be done is that the
>>>> implementation for AutoreleasingUnsafeMutablePointer would remain in
>>>> StdlibCore, but we would add an underscore to make that API private
>>>> to the standard library. Then inside the ObjC overlay, we would
>>>> create a typealias to the internal API with the non-underscored name
>>>> (i.e. make the typealias the public API). Then at a later point in
>>>> time we can move the implementation. The reason why I am not
>>>> proposing to move the implementation today is that there are
>>>> dependencies in Array/Hashed Collections on
>>>> AutoreleasingUnsafeMutablePointer. Moving that code is a larger
>>>> project that is preconditioned on this proposal going in first as an
>>>> incremental step.
>>> If you want to move APIs which aren't cross-platform out of stdlib,
>>> should there be a similar proposal for the PlaygroundQuickLook enum
>>> and CustomPlaygroundQuickLookable protocol?
>>> <https://github.com/apple/swift/blob/master/stdlib/public/core/Mirror.swift>
>>> <https://github.com/apple/swift-xcode-playground-support>
>> That is a good question!  We don't have an obvious existing module into
>> which to move them, though, do we?
> This is just an incremental proposal. The playground work should be in
> a different proposal so we keep this proposal focused.


> Michael
>> -- 
>> Dave
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution


More information about the swift-evolution mailing list