what was the reasoning for making raw at: offset in strides and not bytes?

> On Sep 3, 2017, at 10:22 PM, Andrew Trick <[email protected]> wrote:
> 
> 
>>> On Sep 3, 2017, at 8:05 PM, Xiaodi Wu <[email protected]> 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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to