The implementation is complete and building successfully: https://github.com/apple/swift/pull/12200
On Sat, Sep 30, 2017 at 2:56 PM, Taylor Swift via swift-evolution < [email protected]> wrote: > https://github.com/apple/swift-evolution/pull/750 > https://github.com/apple/swift/pull/12200 > > On Sat, Sep 30, 2017 at 2:15 AM, Taylor Swift <[email protected]> > wrote: > >> >> >> On Thu, Sep 28, 2017 at 7:59 PM, Andrew Trick <[email protected]> wrote: >> >>> >>> On Sep 6, 2017, at 10:15 PM, Taylor Swift <[email protected]> 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.initi >>> alizeMemory<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 >>> >>> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
