[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 6:56 PM, Andrew Trick <atrick at apple.com> wrote:
> 
> 
>>> On Sep 6, 2017, at 4:46 PM, Taylor Swift <kelvin13ma at gmail.com> wrote:
>>> 
>>> A sized implementation may fail more obviously when you violate the contract in the future. Not having sized deallocation is a known deficiency of the C model we've been fairly diligent about avoiding in Swift's allocation interfaces, and it would be extremely unfortunate for us to backpedal from it.
>>> 
>>> -Joe
>> 
>> Which is worse, an active gaping hole in Swift’s memory system, or potentially discouraging users from using a hypothetical future allocation API? 
>> 
>> Making sure the existing allocation API is working properly is a prerequisite to introducing a future more advanced allocation API.
> 
> I think we agree that the runtime should assert when it is passed an invalid deallocation size. The problem you’re describing could still occur with the UnsafeBufferPointer.deallocate() method if the user happened to slice and rebase the buffer.
> 
> -Andy 

the proposal specifically defines UnsafeMutableBufferPointer.deallocate() behavior in terms of calling deallocate() on its baseAddress if non-nil. this operation doesn’t have any relation to the length of the buffer itself. that being said, it *should*, and i’d be down for redefining it in terms of deallocating self.count elements, if this was technically possible but it’s not
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170906/1cdd1853/attachment.html>