[swift-evolution] [swift-evolution-announce] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

[Taylor Swift]

> On Sep 6, 2017, at 7:01 PM, Andrew Trick <atrick at apple.com> wrote:
> 
> 
>>> On Sep 6, 2017, at 4:54 PM, Taylor Swift <kelvin13ma at gmail.com> wrote:
>>> 
>>> The semantics of buffer.deallocate() needs to be: free `buffer.count` bytes of memory at `buffer.baseAddress`. So, that will always be the fast path!
>>> Kelvin, do you agree with that?
>> 
>> this could be problematic if you have multiple contiguous buffers carved out of the same heap block. i agree that this is the best semantics for buffer pointers but we need the sized backend in Swift before this is possible else we will end up in the same boat we’re in right now with `deallocate(capacity:)` where we would have to make buffer deallocate heap block-based for now and then pull the rug out from underneath users later in order to switch to the improved semantics
> 
> If I understand your proposal, it’s only valid to deallocate a buffer that was allocated with the same capacity. Anything else should assert.
> -Andy

the proposal isn’t specific enough there and that’s my fault but this seems like a good solution. in the future if we get a sized backend we can loosen the assertions and make the partial heap block buffer case defined behavior.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170906/49a11a3e/attachment.html>