[swift-evolution] SE-184 Improved Pointers

[Andrew Trick]

> On Aug 19, 2017, at 9:12 PM, Taylor Swift <kelvin13ma at gmail.com> 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 <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.

I like this proposal as it stands!
https://github.com/kelvin13/swift-evolution/blob/9d305ced7b82b9cf5854b55b3f0d08952853d046/proposals/0184-improved-pointers.md

-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170820/8bb1293e/attachment.html>