[swift-evolution] [Pitch] Eliminate `ManagedProtoBuffer`

Charlie Monroe charlie at charliemonroe.net
Mon Jul 18 23:46:57 CDT 2016

This is now part of a pull - https://github.com/apple/swift-evolution/pull/437

The discussion for the four items in the pull ran here (http://thread.gmane.org/gmane.comp.lang.swift.evolution/23093), though there was not enough feedback. But given the deadline for breaking changes, I decided to put the proposal together anyway.

> On Jul 19, 2016, at 4:03 AM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
>> On Jul 18, 2016, at 4:13 PM, Erik Eckstein via swift-evolution <swift-evolution at swift.org> wrote:
>> The reason why `ManagedProtoBuffer` (the base class of `ManagedBuffer`) exists is to give the users an extra bit of type safety inside of the closure `initialHeader` passed to `ManagedBuffer.create()`.
> ...
>> This closure receives the `ManagedBuffer` instance and returns the initial value that is stored in the buffer (the header part of the buffer).  We are passing the `ManagedBuffer` as `ManagedProtoBuffer` to prevent the closure from reading the uninitialized `value` property. This property is defined in `ManagedBuffer` but not in `ManagedProtoBuffer`.
> ...
>> This proposal suggests removing `ManagedProtoBuffer` in order to simplify the API.
>> It means that  `ManagedBuffer` would not be derived from `ManagedProtoBuffer` and all methods from `ManagedProtoBuffer` would be moved to `ManagedBuffer`.
>> The closure `initialHeader` would receive a  `ManagedBuffer` instead of a `ManagedProtoBuffer`.
> I haven't used `ManagedBuffer`, but would it make sense to change the signature of `initialHeader` to `@noescape (elements: UnsafeMutablePointer<Element>, capacity: Int) -> Header` and then effectively run it inside a `withUnsafeMutablePointerToElements()` call? That would prevent access to the uninitialized `header` field while also allowing us to eliminate the `ManagedProtoBuffer` type.
> -- 
> Brent Royal-Gordon
> Architechies
> _______________________________________________
> 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