> On Sep 7, 2017, at 3:10 PM, Joe Groff <[email protected]> wrote:
>
>
>> 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]> wrote:
>>>
>>>
>>>>> On Sep 7, 2017, at 10:31, Andrew Trick via swift-evolution
>>>>> <[email protected]> wrote:
>>>>>
>>>>>
>>>>> On Sep 7, 2017, at 8:06 AM, Taylor Swift <[email protected]> wrote:
>>>>>
>>>>> I don’t see any source for this claim in the documentation, or the source
>>>>> code. 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]> 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]
>>>> 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
but it doesn’t
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
