On Sat, Aug 19, 2017 at 8:52 PM, Andrew Trick <atr...@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.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
