> On Sep 2, 2017, at 2:06 PM, Taylor Swift via swift-evolution
> <swift-evolution@swift.org> 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.
-Andy
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
