> On Jul 19, 2016, at 8:49 AM, Brent Royal-Gordon <[email protected]> > wrote: > >> On Jul 18, 2016, at 10:05 PM, Charlie Monroe <[email protected]> >> 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'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 > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
