On Thu, Sep 7, 2017 at 12:31 PM, Andrew Trick <atr...@apple.com> wrote:
> > On Sep 7, 2017, at 8:06 AM, Taylor Swift <kelvin1...@gmail.com> wrote: > > I don’t see any source for this claim in the documentation > <https://developer.apple.com/documentation/swift/unsafemutablepointer/2295090-deallocate>, > or the source code > <https://github.com/apple/swift/blob/master/stdlib/public/core/UnsafePointer.swift.gyb#L432>. > As far as I can tell the expected behavior is that partial deallocation > “should” work. > > On Thu, Sep 7, 2017 at 8:59 AM, Joe Groff <jgr...@apple.com> wrote: >> >> >> The segfaulting example is an incorrect usage. The only valid parameters >> to deallocate(capacity:) are the base address of an allocation, and the >> original capacity passed into allocate(); it has never been intended to >> support partial deallocation of allocated blocks. It seems to me like this >> proposal is based on a misunderstanding of how the API works. The >> documentation and/or name should be clarified. >> >> -Joe >> >> > “fixing” this bug will cause programs that once operated on previously >> valid assumptions of “free()” semantics to behave differently, without any >> warnings ever being generated. Conversely incorrect code will suddenly >> become “correct” though this is less of a problem. >> > >> >> 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 >> > > This discussion needs to be grounded by reiterating role of the API. > UnsafePointer specifies the memory model without extraneous functionality > or convenience. > > The UnsafePointer.deallocate() API *is not*: > > - a common, expected, or encouraged way to deallocate > > - the simplest, safest, or most convenient way to deallocate > > - necessarilly the most optimal path for deallocation > > There is only one decision that needs to be made here. Does the Swift > runtime track allocation size for manually allocated blocks? I think the > answer should be "yes", or at least haven't heard a strong argument against > it. UnsafePointer.deallocate() needs to direcly reflect that model by > making `allocatedCapacity` an *optional* argument. > > Discussion about whether this API is unsafe, misleading, suboptimal or > incorrectly implemented are secondary. Those are all deficiencies in the > current documentation, current implementation, and availability of > higher-level APIs. > > Note that yesterday I argued that an optional argument wasn't worth the > potential for confusion. That's true from a practical perspective, but I > had lost sight of need to clearly specify the memory model. We want the > Swift runtime to both have the functionality for tracking block size and > also allow user code to track it more efficiently. Both those intentions > need to be reflected in this API. > > -Andy > idk how the swift heap is planned to be implemented, but why is passing the capacity to deallocate considered the fast path anyway? i thought the block size was stored in a header right before the block pointer
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution