> On Sep 2, 2017, at 5:34 PM, Xiaodi Wu <[email protected]> wrote:
>
> On Sat, Sep 2, 2017 at 4:41 PM, Andrew Trick <[email protected]
> <mailto:[email protected]>> wrote:
>
>> On Sep 2, 2017, at 2:06 PM, Taylor Swift via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>> the subscript doesn’t know about the stride that you want to use. If you
>> want to get rid of the `at:` ambiguity, you have to get rid of it
>> everywhere, or users will just wind up having to remember two ways (one
>> ambiguous and one less ambiguous) of doing the same thing, instead of one
>> (ambiguous) way of doing it.
>>
>> Certainly, that's a good point. On rethink and another re-reading of the
>> proposal, it's unclear to me that the addition of `at` arguments to
>> UnsafeMutablePointer is sufficiently justified by the proposal text. Is it
>> merely that it's shorter than writing `foo + MemoryLayout<T>.stride *
>> offset`? With the ambiguity of `at`, it seems that the current way of
>> writing it, though longer, is certainly less ambiguous.
>>
>> Please reread it; UnsafeMutablePointer’s methods do not use `at:`.
>
> Regarding the typed buffer pointers, I think it is clear by convention, and
> will be well documented, that the `at` label refers to a position in `self`.
>
> The raw buffer pointer API isn’t so obvious. Since the `at` refers to `self`
> it might more logically be a byte offset. Note that `at` as a label name
> always refers to a strided index.
>
> This would be a bit more explicit:
> UnsafeRawBufferPointer.initializeMemory(as:T.self, atByteOffset: position *
> MemoryLayout<T>.stride, from: bufferOfT)
>
> But possibly less convenient… Since that `at` label currently on
> UnsafeRawPointer.initializeMemory is almost never used, I don’t think we need
> to worry too much about convenience.
>
> That existing `at` label on UnsafeRawPointer.initializeMemory, would also
> need to be renamed, which is fine.
>
> If I may suggest one more incremental improvement in clarity, it would be to
> move `at[ByteOffset]` to be the first argument; this eliminates the possible
> reading that we are offsetting the source buffer:
>
> ```
> UnsafeRawBufferPointer.initializeMemory(atByteOffset: position *
> MemoryLayout<T>.stride, as:T.self, from: bufferOfT)
> ```
Sure, that probably makes sense if we decide to go with a byte offset vs.
stride index.
-Andy
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
