[swift-evolution] SE-184 Improved Pointers

[Taylor Swift]

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

>
>> The problem is I would expect to be able to safely call deinitialize()
>> and friends after calling initialize(from:). If Element is a class type and
>> initialize doesn’t fill the entire buffer range, calling deinitialize()
>> will crash. That being said, since copy(from:bytes:) and copyBytes(from:)
>> don’t do any initialization and have no direct counterparts in
>> UnsafeMutableBufferPointer, it’s okay if they have different behavior than
>> the other methods.
>>
>>
>> You astutely pointed out that the UnsafeMutableBufferPointer.deinitialize()
>> method is dangerous, and I asked you to add a warning to its comments.
>> However, given the danger, I think we need to justify adding the method to
>> begin with. Are there real use cases that greatly benefit from it?
>>
>
> I agree that’s a problem, which is why i was iffy on supporting partial
> initialization to begin with. The use case is for things like growing
> collections where you have to periodically move to larger storage. However,
> deinitialize is no more dangerous than moveInitialize,
> assign(repeating:count:), or moveAssign; they all deinitialize at least one
> entire buffer. If deinitialize is to be omitted, so must a majority of the
> unsafe pointer API.
>
>
> Here's an alternative. Impose the precondition(source.count == self.count)
> to the following UnsafeMutableBufferPointer convenience methods that you
> propose adding:
>
> +++ func assign(from:UnsafeBufferPointer<Element>)
> +++ func assign(from:UnsafeMutableBufferPointer<Element>)
> +++ func moveAssign(from:UnsafeMutableBufferPointer<Element>)
> +++ func moveInitialize(from:UnsafeMutableBufferPointer<Element>)
> +++ func initialize(from:UnsafeBufferPointer<Element>)
> +++ func initialize(from:UnsafeMutableBufferPointer<Element>)
>
> I don't that introduces any behavior that is inconsistent with other
> methods. `copyBytes` is a totally different thing that only works on
> trivial types. The currently dominant use case for UnsafeBufferPointer,
> partially initialized backing store, does not need to use your new
> convenience methods. It can continue dropping down to pointer+count style
> initialization/deinitialization.
>
> -Andy
>

the latest draft does not have assign(from:UnsafeMutableBufferPointer<
Element>) or  initialize(from:UnsafeMutableBufferPointer<Element>), it uses
the generic Sequence methods that are already there that do not require
that precondition.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170819/adbe7509/attachment.html>