> On Sep 7, 2017, at 11:57 AM, Taylor Swift <[email protected]> wrote:
>
>
>
> On Thu, Sep 7, 2017 at 1:39 PM, Jordan Rose <[email protected]
> <mailto:[email protected]>> wrote:
>
>
>> On Sep 7, 2017, at 10:31, Andrew Trick via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>>
>>> On Sep 7, 2017, at 8:06 AM, Taylor Swift <[email protected]
>>> <mailto:[email protected]>> 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 <[email protected]
>>> <mailto:[email protected]>> 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
>
> I don't think this is correct. UnsafePointer.deallocate is the API you must
> use to deallocate memory allocated with UnsafePointer.allocate. My question
> is whether it's acceptable to break all the people who didn't know this and
> are using it to deallocate memory allocated with malloc or new on Apple
> platforms. It sounds like the answer to that is "no, we want to be
> malloc-compatible", and therefore the 'capacity' parameter isn't currently
> serving a purpose today. We will always need to check if the memory is
> actually in the Swift pool before even believing the 'capacity' parameter.
>
> (It is definitely true that the intent was for this to be the allocation
> capacity, and I'm surprised you interpreted it as supporting partial
> deallocation. But we probably can't fix that at this point.)
>
> Jordan
>
>>
>> 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
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>
>
> I mean I would have thought it’s reasonable to expect that if the method asks
> for a capacity parameter, it will actually use it
It will.
-Joe
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
