[swift-evolution] SE-184 Improved Pointers

[Andrew Trick]

> On Aug 20, 2017, at 6:03 PM, Taylor Swift <kelvin13ma at gmail.com> wrote:
> 
> New draft of the proposal is up here: <https://github.com/kelvin13/swift-evolution/blob/patch-3/proposals/0184-improved-pointers.md <https://github.com/kelvin13/swift-evolution/blob/patch-3/proposals/0184-improved-pointers.md>>
> 
> Important changes start here <https://github.com/kelvin13/swift-evolution/blob/patch-3/proposals/0184-improved-pointers.md#proposed-solution>.

I have more feedback for you after discussing with Ben and Michael.

Under the section "Background". The retaining/releasing counts are confusing because we normally talk about "+0/+1" with respect to a single value. Here you're summing the reference count effect across different source and destination values. I think you can drop the -1/+0/+1 from the cell labels and just label the headers as "Source-Copy(+1) vs. Source-Move(+0)" and "Dest-Initializing(+0)" vs. "Dest-Destroying(-1)".

Ben noticed that we still don't have `UnsafeMutableBufferPointer.deallocate()`. Please add that as well.

I think you should also add the default `alignedTo:Int = MemoryLayout<UInt>.alignment` to `UnsafeRawMutablePointer`. It is effectively part of Swift's memory model... [Background: We're providing a language level default guarantee of word-aligned storage. We don't want to expose the platform's default alignment. There is no such thing as a "maximal" alignment for all imported primitive types. We expect allocators to typically provide 16-byte alignment, but when developers are relying on that for correctness, we want it to be explicit. Developers usually rely on word alignment so there's no value in making that explicit.]

The source breaking changes can be marked deprecated for now, but can only be marked unavailable in Swift 5 mode or later.

We anticipate adding a ContiguouslyStored protocol "soon", which could be used to reduce the amount of overloading on the buffer `initialize`/`assign` APIs. But we need a lot more time to iterate on that design and it doesn't appear that migrating to it would be source breaking w.r.t. your proposal.

I think we would be receptive to a "non-Optional baseAddress" proposal now if you or anyone else wants to pitch that. I know Dave Abrahams had a working implementation at some point. That would weaken some of the incentive to continue adding more convenience to buffer slices.

Sorry to bring this up again, but I was not able to defend the addition of `UnsafeMutableBufferPointer.deinitialize()`. It is incorrect for the typical use case and doesn't appear to solve any important use case. The *only* fully initializing method is `initialize(repeating:)`, but that will usually be used for trivial values, which should not be deinitialized. It's preferable for the user to explicitly deinitialize just the segments that they know were initialized, which can be done on the base pointer. The only benefit in having a `deinitialize` on the buffer is to communicate to users who see the `initialize` API for the first time that it is their responsibility to deinitialize if the type requires it. To that end, we could add a `deinitialize(at:count:)` method, communicating the symmetry with `initialize(at:from:). Naturally `index + count <= self.count`.

-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170821/e98138b3/attachment.html>