[swift-evolution] SE-184 Improved Pointers

[Taylor Swift]

On Sat, Aug 19, 2017 at 9:31 PM, Andrew Trick <atrick at apple.com> wrote:

>
> On Aug 19, 2017, at 6:16 PM, Taylor Swift <kelvin13ma at gmail.com> wrote:
>
> What you’re describing is basically an earlier version of the proposal
> which had a slightly weaker precondition (source >= destination) than yours
> (source == destination). That one basically ignored the Sequence methods at
> the expense of greater API surface area.
>
>
> The Sequence methods don’t provide the simpler, more convenient form of
> initialization/deinitialization that I thought you wanted. I see two
> reasonable options.
>
> 1. Don’t provide any new buffer initialization/deinitialization
> convenience. i.e. drop UsafeMutableBufferPointer moveInitialize,
> moveAssign, and deinitialize from your proposal.
>
> 2. Provide the full set of convenience methods: initialize, assign,
> moveInitialize, and moveAssign assuming self.count==source.count. And
> provide deinitialize() to be used only in conjunction with those new
> initializers.
>
> The question is really whether those new methods are going to
> significantly simplify your code. If not, #1 is the conservative choice.
> Don't provide convenience which could be misused. Put off solving that
> problem until we can design a new move-only buffer type that tracks
> partially initialized state.
>
> -Andy
>
>
I’m not sure the answer is to just omit methods from
UnsafeMutableBufferPointer since most of the original complaints circulated
around having to un-nil baseAddress to do anything with them.

What if only unary methods should be added to UnsafeMutableBufferPointer
without count:, meaning:

initialize(repeating:)
assign(repeating:)
deinitialize()

and the other methods should take both an *offset* parameter instead of a
count parameter:

initialize(from:at:)
assign(from:at:)
moveInitialize(from:at:)
moveAssign(from:at:)

which provides maximum explicitness. This requires improvements to buffer
pointer slicing though. But I’m not a fan of the mission creep that’s
working into this proposal (i only originally wrote the thing to get
allocate(capacity:) and deallocate() into UnsafeMutableBufferPointer!)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170819/c5d7d9c4/attachment.html>