[swift-evolution] [Pitch] deprecating ManagedBufferPointer

Erik Eckstein eeckstein at apple.com
Wed Oct 19 18:56:56 CDT 2016


> On Oct 19, 2016, at 3:28 PM, Alexis <abeingessner at apple.com> wrote:
> 
> A bit late to this game, because I didn’t fully understand the “point” of ManagedBuffer(Pointer). After a good week of messing around with these in Dictionary/Array/String, I now have Opinions.
> 
> I agree ManagedBufferPointer is largely unnecessary. However it’s seeming a lot like ManagedBuffer (and its equivalents) are suboptimal for the standard library’s purposes too!
> 
> In particular, pretty much every one of these buffers that I see wants to be a subclass of some NS* collection so that it can be toll-free bridged into objective C. This means that all those types are forced to directly drop down to allocWithTailElems, rather than using a nice abstraction that does it for them. Array does this right now, and I’ve got a PR up for review that’s doing the same thing to the HashedCollections. It’s an outstanding bug that String isn’t doing this (forcing its buffer to be wrapped in another class to be bridged).
> 
> I don’t really feel any pain from directly using allocWithTailElems, it’s a great API. It just leaves me at a loss for when I’d reach for ManagedBuffer at all, as it’s very limited.

I think we can implement a replacement for ManagedBufferPointer. But it would have a different API. Something like that:

public struct ManagedBufferPointer2<StorageClass: AnyObject, Element> {

  public init(minimumCapacity: Int,
              initWith factory: (StorageClass) throws -> ()
  ) rethrows {
    buffer = Builtin.allocWithTailElems_1(
         StorageClass.self, minimumCapacity._builtinWordValue, Element.self)
    try factory(buffer)
  }
  // ...
  let buffer: StorageClass
}


> 
> 
>> On Oct 13, 2016, at 3:11 PM, Erik Eckstein via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> I created a proposal: https://github.com/apple/swift-evolution/pull/545 <https://github.com/apple/swift-evolution/pull/545>
>> 
>>> On Oct 11, 2016, at 11:32 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> 
>>> on Tue Oct 11 2016, Károly Lőrentey <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>>> +1
>>>> 
>>>> ManagedBuffer has been really useful a couple of times, but I never
>>>> found a use for ManagedBufferPointer. I can’t even say I’m entirely
>>>> sure what need it was originally designed to fulfill.
>>> 
>>> The real need is/was to be able to do the same kind of storage
>>> management in classes not derived from ManagedBuffer.  This can be
>>> important for bridging, where the buffers of various native swift
>>> containers need to be derived from, e.g., NSString or NSArray.  That is,
>>> however, an extremely stdlib-specifc need.
>>> 
>>> 
>>>>> On 2016-10-11, at 00:12, Erik Eckstein via swift-evolution
>>>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>> 
>>>>> The purpose of ManagedBufferPointer is to create a buffer with a custom class-metadata to be able
>>>> to implement a custom deinit (e.g. to destroy the tail allocated elements).
>>>>> It was used in Array (before I replaced it with the new tail-allocated-array-built-ins). But now
>>>> it’s not used anymore in the standard library.
>>>>> 
>>>>> As a replacement for ManagedBufferPointer one can just derive a class from ManagedBuffer and implement the deinit in the derived class.
>>>>> 
>>>>> final class MyBuffer : ManagedBuffer<MyHeader, MyElements> {
>>>>>  deinit {
>>>>>    // do whatever needs to be done
>>>>>  }
>>>>> }
>>>>> 
>>>>> // creating MyBuffer:
>>>>> let b = MyBuffer.create(minimumCapacity: 27, makingHeaderWith: { myb in return MyHeader(...) })
>>>>> 
>>>>> IMO ManagedBuffer is much cleaner than ManagedBufferPointer (it doesn’t need this custom
>>>> bufferClass to be passed to the constructor). Also ManagedBufferPointer doesn’t use SIL
>>>> tail-allocated arrays internally. Although this is not something visible to the programmer, it makes
>>>> life easier for the compiler.
>>>>> 
>>>>> So I suggest that we deprecate ManagedBufferPointer.
>>>>> 
>>>>> Erik
>>>>> _______________________________________________
>>>>> 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 <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>> 
>>> 
>>> -- 
>>> -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 <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

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


More information about the swift-evolution mailing list