> On Aug 20, 2017, at 6:03 PM, Taylor Swift <[email protected]> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
