> On Sep 7, 2017, at 13:02, Andrew Trick <[email protected]> wrote:
>
>
>> On Sep 7, 2017, at 11:39 AM, Jordan Rose <[email protected]
>> <mailto:[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.
That's all fine; I'll rephrase to say that if I allocated with
UnsafeMutablePointer.allocate, I'll probably deallocate with
Unsafe[Mutable]Pointer.deallocate. They're not independent.
>
>> 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.
I suspect that we cannot revoke that from existing platforms.
> 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.
I don't know where this comes from. If you don't need to be malloc-compatible,
you don't strictly "need" this information. (It would break tools like 'leaks',
though.)
>
>> (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.
That "you" was addressed to Kelvin (Taylor), but if we really think people are
mixing malloc/free and UnsafePointer APIs today, we should not break that on
our existing platforms. It's unfortunate, but we're on Swift 4 already. It is
not worth the cost.
> 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.
I don't see an advantage to having the parameter if we're going to promise that
it's always present. It is additional complexity for very little win in a
generic interface. If someone wants to write a special allocation entry point
that actually makes use of this, they can do so, but it shouldn't live on
UnsafePointer.
(We also have nothing that prevents you from doing `(ptr+1).deallocate()`, but,
well, "unsafe".)
Jordan
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
