> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
