[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 Thu, Sep 7, 2017 at 12:31 PM, Andrew Trick <atrick at apple.com> wrote:

>
> On Sep 7, 2017, at 8:06 AM, Taylor Swift <kelvin13ma at 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 <jgroff at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170907/2ba16590/attachment.html>