On Sun, Aug 20, 2017 at 10:18 PM, Andrew Trick <[email protected]> wrote:
> > On Aug 19, 2017, at 9:12 PM, Taylor Swift <[email protected]> wrote: > >> >> and the other methods should take both an *offset* parameter instead of >> a count parameter: >> >> initialize(from:at:) >> assign(from:at:) >> moveInitialize(from:at:) >> moveAssign(from:at:) >> >> 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!) >> >> >> I’m open to that, with source.count <= self.count + index. They are >> potentially ambiguous (the `at` could refer to a source index) but >> consistent with the idea that this API is for copying an entire source >> buffer into a slice of the destination buffer. Again, we need to find real >> code that benefits from this, but I expect the stdlib could use these. >> > > In case that typo wasn’t obvious, we actually want the precondition: > `offset + source.count <= self.count` (your latest proposal draft is > correct). > > The more I think the more I believe using from:at: is the right approach. > The only problem is that it would have to be written as a generic on > Collectionor Sequence to avoid having to provide up to 4 overloads for > each operation, since we would want these to work well with buffer slices > as well as buffers themselves. That puts them uncomfortably close to the > turf of the existing buffer pointer Sequence API though. > > > It would have to be a generic method taking a RandomAccessCollection. > Calling that would rely on tricky type inference. For now, I prefer the > explicitly typed API in your current proposal. > > Or we could make UnsafeMutableBufferPointer its own slice type. Right now > MutableRandomAccessSlice<UnsafeMutableBufferPointer<Element>> takes up 4 > words of storage when it really only needs two. > > > A slice needs to be a separate type because of the indexing semantics: > https://github.com/apple/swift-evolution/commit/ > c8165b41b188c3d095425a0b4636fcf299ee9036 > > Note that it's actually a feature that Subsequence refers back to its > original buffer. If we cared enough, we could define a buffer slice type > that exposes most of the buffer API. I just don't think we need to worry > about that level of convenience yet, especially with you adding the `at:` > labels. I'm fine if developers resort to `init(rebasing:)` in rare cases. > Again, once we have a safe move-only or reference counted buffer type, that > will be the better choice for Swift APIs. For now, this is still largely > driven by C interop. > a method like `buffer.segment(0 ..< 5)` or something which would avoid constructing the slice type (and save typing that long `UnsafeMutableBufferPointer(rebasing:)` name) like that would be nice . but that’s just sugar and not very important if you ask me > > I like this proposal as it stands! > https://github.com/kelvin13/swift-evolution/blob/ > 9d305ced7b82b9cf5854b55b3f0d08952853d046/proposals/0184- > improved-pointers.md > > -Andy > I’ll try to get an updated implementation out in the next few days
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
