> On Jul 18, 2016, at 4:13 PM, Erik Eckstein via swift-evolution > <[email protected]> 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 [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
