[swift-evolution] SE-184 Improved Pointers

[Taylor Swift]

On Sun, Aug 20, 2017 at 10:18 PM, Andrew Trick <atrick at apple.com> wrote:

>
> 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
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170820/b44f1c46/attachment.html>