> On Sep 7, 2017, at 2:29 PM, Jordan Rose <jordan_r...@apple.com> wrote:
>
>>
>> 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.)
There are two distinct but related issues (1) malloc compatibility (2)
malloc/free like functionality. I know developers sometimes expect or want #2.
Realistically, we will always want the runtime to provide malloc_size, even if
it’s not super fast, so we’re not giving up anything long term by providing #2.
The fact the #1 is also a likely goal on major platforms just reinforces that
position.
>> 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".)
I also don’t see any usability advantage in providing the extra argument for
anyone directly using UnsafePointer, which is why I initially objected to Joe
Groff’s request. Then I realized I care less about usability and potential
confusion than I care that UnsafePointer API can be viewed is a specification
of the Swift's basic memory management functionality. We want to communicate
that data structures doing manual allocation/deallocation should provide the
allocated capacity during deallocation if it is available. The runtime could
make good use of that. In particular, I want UnsafeBufferPointer’s deallocate()
to be able to call UnsafePointer.deallocate(allocatedCapacity: buffer.count),
rather than implementing it in terms of Builtins.
Incidentally, FWIW, I think compiled code should continue to be required to
pass the capacity to the runtime during deallocation. That way, any changes in
the runtime implementation of deallocation, particularly extra address checks,
are isolated to the standard library.
-Andy
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
