> On Jul 19, 2016, at 4:03 AM, Brent Royal-Gordon via swift-evolution 
> <[email protected]> wrote:
> 
>> 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.

Wouldn't this disallow access to the capacity field? That's as well defined on 
ManagedProtoBuffer and AFAIK can be accessed during the initialization.


> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to