> On Sep 6, 2017, at 6:56 PM, Andrew Trick <[email protected]> wrote:
>
>
>>> On Sep 6, 2017, at 4:46 PM, Taylor Swift <[email protected]> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
