[swift-evolution] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

[Taylor Swift]

I’m fine with most of this

On Tue, Sep 5, 2017 at 4:49 PM, Andrew Trick <atrick at apple.com> wrote:

>
> On Sep 5, 2017, at 9:53 AM, Taylor Swift <kelvin13ma at gmail.com> wrote:
>
> we agreed to deprecate the strided at:? Note that
> UnsafeMutableRawBufferPointer would still need a byteOffset: argument.
> I’m also still not comfortable with duplicating functionality for the sake
> of having two names
>
>
> I’ll summarize what I think happened in this thread...
>
> I don't think the suggested copyBytes rename was controversial:
>
> UMRP (raw pointer):
> --- copyBytes(from:count)
> +++ copyMemory(from:bytes:)
>
>
> UMRBP (raw buffer):
> --- copyBytes(from:)
> +++ copyMemory(atByteOffset:from:)
>
> --- copyBytes<C>(from:)
> +++ copyMemory(from:)
>
>
no problem with this


>
> In the new raw initializeMemory methods, Xiaodi and I agreed to make
> it more clear that the offset is in terms of `self` rather than
> `from`, and to further reduce ambiguity by forcing manual stride
> computation and using an explicit "offset" label. The call site will
> be just as explicit as dropping down to `baseAddress` but without any
> pointer conversion boilerplate.
>
> UMRBP (raw buffer):
> +++ func initializeMemory<T>(atByteOffset:as:from:)
> +++ func moveInitializeMemory<T>(atByteOffset:as:from:)
>
>
Agree, but the label should just be `atByte:`, not `atByteOffset:`. after
all, we don’t use `atOffset:` in the strided case; its obvious that it’s an
offset


>
> Than, in the one existing initializeMemory method, just drop the strided
> index.
> It's never used, we want to be consistent in using a byte offset
> for the raw index, and that can be expressed just as easily as pointer
> arithmetic:
>
> UMRP (raw pointer):
> --- func initializeMemory<T>(as:T.Type, at:Int = 0, count:Int = 1, to:T)
> +++ func initializeMemory<T>(as:T.Type, repeating:T, count:Int = 1)
>
> Then you can simply leave these methods as-is:
> > func initializeMemory<T>(as:T.Type, from:UnsafePointer<T>, count:Int)
> > func moveInitializeMemory<T>(as:T.Type, from:UnsafeMutablePointer<T>,
> count:Int)
>
>
yes


> We don't have a consensus, but I think the suggestion to distinguish
> between single value vs. multiple semantics was good. Otherwise,
> adding the default count could be very misleading. Normally, we try to
> minimize surface area, but adding two methods for the single-value case
> avoids ambiguity between the buffer and pointer semantics:
>
> UMP (pointer)
> --- func initialize(to:count:(=1))
> +++ func initialize(to:)
> +++ func initialize(repeating:count:) // no default count
> +++ func assign(to:)
> +++ func assign(repeating:count:) // no default count
>
> UMRP (raw pointer):
> --- func initializeMemory<T>(as:at:(=0)count:(1)to:)
> +++ func initializeMemory<T>(as:repeating:count:) // remove default count
>

still extremely suspicious of this but i’m willing to compromise. also
there should be an `initializeMemory<T>(at:to:)` to match the typed methods


>
> -Andy
>
> On Tue, Sep 5, 2017 at 11:31 AM, Andrew Trick <atrick at apple.com> wrote:
>
>> I think we’ve agreed to a few minor updates to this proposal. Since there
>> hasn’t been any other feedback on the thread it may be worth posting an
>> amended proposal so we all know what we’ve agreed on.
>>
>> -Andy
>>
>> On Sep 3, 2017, at 8:23 PM, Andrew Trick via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>
>> On Sep 3, 2017, at 8:05 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>
>> If we use byte offset, then the at parameter in UnsafeMutableRawPointer
>>> should be removed, since pointer arithmetic can be used instead (just
>>> like with UnsafeMutablePointer).
>>>
>>
>> I agree that it seems quite sensible to remove the ‘at’ parameter
>> altogether from the UMRP method.
>>
>>
>> No code in tree or on github is using the `at` argument. I think it can
>> be removed. A fixit should still be possible.
>>
>> Not convinced moving the at: argument to come before the as: argument is
>>> worth it in terms of source breakage.
>>>
>>
>> Since much of this proposal involves shuffling and relabeling arguments,
>> I’d argue it’s better to break slight more source in one go for the optimal
>> API than to break slightly less for a slightly less optimal API, no? (This
>> is assuming there is agreement that ‘at:as:’ is less prone to
>> misinterpretation than ‘as:at:’.)
>>
>>
>> To be clear, we’re just talking about UnsafeMutableRawBufferPointer.initializeMemory
>> now, so this is purely additive.
>> I think the label needs to be `atByteOffset`, and placing it before `as`
>> makes a lot of sense because it no longer depends on the type’s stride.
>>
>> -Andy
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170905/546a467a/attachment.html>