> 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 <[email protected]> > wrote: > > >> 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 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 >> > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
