> 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
<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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
