> On Sep 30, 2017, at 10:45 AM, Taylor Swift <kelvin1...@gmail.com> wrote: > > this function initializeMemory<C:Collection>(as:from:) says it will be > removed in Swift 4.0. It is now Swift 4.0. can I remove it?
It looks safe to remove. However, the doc comments in the same file should be updated to refer to `initializeMemory<T>(as:from:count:)`. +cc Nate Cook -Andy > On Sat, Sep 30, 2017 at 2:15 AM, Taylor Swift <kelvin1...@gmail.com > <mailto:kelvin1...@gmail.com>> wrote: > > > On Thu, Sep 28, 2017 at 7:59 PM, Andrew Trick <atr...@apple.com > <mailto:atr...@apple.com>> wrote: > >> On Sep 6, 2017, at 10:15 PM, Taylor Swift <kelvin1...@gmail.com >> <mailto:kelvin1...@gmail.com>> wrote: >> >> okay so I think so far what’s been agreed on is >> >> 1. rename “Bytes” to “Memory” in the raw pointer API. Note: this brings the >> `copyBytes<C>(from:)` collection method into the scope of this proposal >> >> 2. change raw offsets to be in terms of bytes, not typed strides. This >> argument will be called `atByteOffset:` and will only appear in >> UnsafeMutableRawBufferPointer. “at:” arguments are no longer needed in >> UnsafeMutableRawPointer, since we can just use pointer arithmetic now. >> >> >> 3. move UnsafeMutableBufferPointer’s `at:` arguments to the front of the >> parameter list. mostly cause any pointer arithmetic happens in the front so >> structurally we want to mirror that. >> >> 4. add dual (to:) single element initializers and assigners to >> UnsafeMutablePointer, but not UnsafeMutableRawPointer because it’s >> apparently not useful there. >> `UnsafeMutableRawPointer.initializeMemory<T>(as:repeating:count:)` still >> loses its default count to prevent confusion with its buffer variant. >> >> 5. memory deallocation on buffer pointers is clearly documented to only be >> defined behavior when the buffer matches a whole heap block. > > > Kelvin, > > Attempting to limit the scope of this proposal backfired. I was hoping to > avoid discussing changes to the slice API, instead providing basic > functionality within the buffer API itself. However, Dave Abrahams has argued > that once the slice API is extended, the positional arguments are extraneous > and less clear. > > Instead of > > buf.intialize(at: i, from: source) > > We want to force a more obvious idiom: > > buf[i..<n].intialize(from: source) > > I think this is a reasonable argument and convinced myself that it's possible > to extend the slice API. I'm also convinced now that we don't need overloads > to handle an UnsafeBufferPointer source, instead we can provide a single > generic entry point on both UnsafeMutableBufferPointer and its slice, > optimized within the implementation: > > `initialize<S : Sequence>(from: S) -> (S.Iterator, Index) > > We can always drop down to the UnsafePointer API to get back to a direct > unsafe implementation as a temporary workaround for performance issues. > > Let's set aside for now whether we support full or partial > initialization/assignment, how to handle moveInitialize, and whether we need > to return the Iterator/Index. This is going to require another iteration on > swift-evolution, which we should discuss in a separate thread. > > At this point, I suggest removing the controversial aspects of SE-0184 so > that we can put the other changes behind us and focus future discussion > around a smaller follow-up proposal. > > Here I've summarized the changes that I think could be accepted as-is: > https://gist.github.com/atrick/c1ed7afb598e5cc943bdac7683914e3e > <https://gist.github.com/atrick/c1ed7afb598e5cc943bdac7683914e3e> > > If you amend SE-0184 accordingly and file a new PR, I think it can be quickly > approved. > > -Andy > > > Part one of SE-0184 is here as SE-0184 A > <https://github.com/kelvin13/swift-evolution/blob/improved-pointers/proposals/0184a-unsafe-pointers-part-1.md> > > I’ll implement it tomorrow and then make the PR >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
