> On Sep 7, 2017, at 11:39 AM, Jordan Rose <[email protected]> wrote:
>
>> 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.
No, all of Swift’s APIs for manual allocation/deallocation need to be
compatible. UnsafeBufferPointer is highly preferable to UnsafePointer today. In
the future we will have a safe API for manual allocation, still based on the
underlying model specified by UnsafePointer.
UnsafePointer.allocate() is *not*
- a common, expected, or encouraged way to allocate
- the simplest, safest, or most convenient way to allocate
- necessarily the most optimal path for allocation
Even though high-level APIs are specified in terms of this model, they can be
implemented via their own fast-paths.
> Myquestion 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.
We don’t need to claim that manually allocated Swift memory is malloc
compatible on every platform that happens to have malloc. We do want the Swift
memory model to be consistent with the reality that on most platforms, we need
the runtime to track block size.
> (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.)
I never misinterpreted the meaning of the API, but apparently multiple people
on the evolution list did. Regardless, that is not valid reason for changing
the API. It’s only a valid reason for improving documentation and encouraging
the use of safer APIs.
If our memory model states that the runtime tracks capacity of manually
allocated blocks, then the deallocation capacity should be optional to reflect
that.
Still waiting to hear any arguments that something about that memory model is
bad.
-Andy
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
