[swift-evolution] SE-184 Improved Pointers
kelvin13ma at gmail.com
Sat Aug 19 20:42:47 CDT 2017
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
> 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.
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:
and the other methods should take both an *offset* parameter instead of a
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...
More information about the swift-evolution