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

[Erik Eckstein]

> 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.

OK. How do you like to proceed with that? I'm fine to handle this as part of #437 as long as it goes through quickly. If it's accepted, do you want to do the implementation? Otherwise I can do it (the removal of ManagedProtoBuffer). Roman could help with the `unsafeAddressOf` part.


> On Jul 19, 2016, at 12:17 AM, Charlie Monroe <charlie at charliemonroe.net> wrote:
> 
> 
>> On Jul 19, 2016, at 8:49 AM, Brent Royal-Gordon <brent at architechies.com> wrote:
>> 
>>> On Jul 18, 2016, at 10:05 PM, Charlie Monroe <charlie at charliemonroe.net> wrote:
>>> 
>>>> 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.
>>> 
>>> Wouldn't this disallow access to the capacity field? That's as well defined on ManagedProtoBuffer and AFAIK can be accessed during the initialization.
>> 
>> Yes, which is why I suggested it should be passed in to the `initialHeader` closure too. (It's read-only anyway, so there's no loss of capability.) What it *does* prevent access to is `withUnsafeMutablePointerToHeader`, but I'm not sure how that method is supposed to work before the header's been initialized anyway.
> 
> I'd personally just remove the ManagedProtoBuffer and note in the documentation of ManagedBuffer.create that you should not read the header from within the block. I think it's a similar programming error as indexing out of bounds which is also documented to be a programming error.

I agree.


> 
> I'm not sure whether we could simply eliminate ManagedBuffer altogether since looking at https://github.com/search?l=swift&q=ManagedBuffer&type=Code the only places this is used are generally just forks of apple/swift and I haven't found a single use ManagedBuffer.create in the entire stdlib, all of the Array code uses ManagedBufferPointer directly and initializes it with the unsafeBufferObject, which is some subclass of _ContiguousArrayStorageBase...
> 
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies
>> 
>