Can you elaborate on this? Why aren't you sure this is a wise idea?<br><br><div class="gmail_quote"><div dir="ltr">On Thu, Dec 8, 2016 at 16:19 Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="gmail_msg">
on Thu Dec 08 2016, Alexis Beingessner <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg">
<br class="gmail_msg">
>> On Dec 8, 2016, at 3:50 PM, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>> on Thu Dec 08 2016, Ben Cohen <ben_cohen-AT-apple.com> wrote:<br class="gmail_msg">
>><br class="gmail_msg">
><br class="gmail_msg">
>>>> On Dec 2, 2016, at 8:27 PM, Nate Cook <<a href="mailto:natecook@gmail.com" class="gmail_msg" target="_blank">natecook@gmail.com</a>> wrote:<br class="gmail_msg">
>>>><br class="gmail_msg">
>>>>> On Dec 2, 2016, at 2:12 PM, Ben Cohen via swift-evolution<br class="gmail_msg">
>>>>> <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>>><br class="gmail_msg">
>>>>> wrote:<br class="gmail_msg">
>>><br class="gmail_msg">
>>>>><br class="gmail_msg">
>>>>>> On Dec 1, 2016, at 11:33 PM, Nate Cook via swift-evolution<br class="gmail_msg">
>>>>>> <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>>><br class="gmail_msg">
>>>>>> wrote:<br class="gmail_msg">
>>>>>><br class="gmail_msg">
>>>>>> 3) Make all buffer pointers their own slices but use a different<br class="gmail_msg">
>>>>>> index type. If the indices were just wrapped pointers, that would<br class="gmail_msg">
>>>>>> handle the index sharing without needing an additional property on<br class="gmail_msg">
>>>>>> the buffer. We could also maintain integer-based stridable<br class="gmail_msg">
>>>>>> conformance (which greatly simplifies index arithmetic), since the<br class="gmail_msg">
>>>>>> indices would just offset by a byte for raw buffers or a stride<br class="gmail_msg">
>>>>>> for typed buffers.<br class="gmail_msg">
>>>>>><br class="gmail_msg">
>>>>><br class="gmail_msg">
>>>>> Unfortunately, switching to non-integer indices would change this<br class="gmail_msg">
>>>>> from being mildly source-breaking to being extremely<br class="gmail_msg">
>>>>> source-breaking, as there’s lots of code out there using buffers<br class="gmail_msg">
>>>>> today indexing them with integers (including integer literals).<br class="gmail_msg">
>>>>><br class="gmail_msg">
>>>>> The big win with UnsafeBufferPointer having an integer index is<br class="gmail_msg">
>>>>> it’s a drop-in replacement for arrays, so when you hit a<br class="gmail_msg">
>>>>> performance problem using an array you can quickly switch to using<br class="gmail_msg">
>>>>> a buffer under most circumstances instead without having to change<br class="gmail_msg">
>>>>> much of your code – including code that uses for i in<br class="gmail_msg">
>>>>> 0..<myArray.count, of which there is a lot out there in the<br class="gmail_msg">
>>>>> wild. Switching to an opaque index would break anyone doing that.<br class="gmail_msg">
>>>><br class="gmail_msg">
>>>> It is definitely very source-breaking, though with relatively simple fixits:<br class="gmail_msg">
>>>><br class="gmail_msg">
>>>> buf[0] ---> buf[buf.startIndex]<br class="gmail_msg">
>>>> buf[3] ---> buf[buf.startIndex + 3]<br class="gmail_msg">
>>>> buf[i] ---> buf[buf.startIndex + i]<br class="gmail_msg">
>>>><br class="gmail_msg">
>>>> Any integer arithmetic happening outside the subscript could be left<br class="gmail_msg">
>>>> unchanged. If that cost isn't worth the benefit, then making<br class="gmail_msg">
>>>> UnsafeRawBufferPointer use Slice as its slice type is probably the<br class="gmail_msg">
>>>> best way to resolve that issue.<br class="gmail_msg">
>>>><br class="gmail_msg">
>>>> Nate<br class="gmail_msg">
>>><br class="gmail_msg">
>>> The fixits aren’t quite that simple for slices, though:<br class="gmail_msg">
>>><br class="gmail_msg">
>>> let slice = buf[3..<6]<br class="gmail_msg">
>>> slice[3] —> slice[slice.startIndex + 0] // fixit would somehow need to know this is 0 not 3<br class="gmail_msg">
>>> slice[i] —> slice[slice.startIndex + ??] // or even need to<br class="gmail_msg">
>>> know this is, erm, I haven’t had enough coffee this morning<br class="gmail_msg">
>>><br class="gmail_msg">
>>> The other downside is it would thwart speculatively switching an Array<br class="gmail_msg">
>>> to an UnsafeBuffer to see if that was a bottleneck, then switching<br class="gmail_msg">
>>> back.<br class="gmail_msg">
>>><br class="gmail_msg">
>>>> On Dec 1, 2016, at 11:33 PM, Nate Cook via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg">
>>>><br class="gmail_msg">
>>>> 1) Switch to using Slice as a wrapper for UnsafeRawBufferPointer.<br class="gmail_msg">
>>>><br class="gmail_msg">
>>><br class="gmail_msg">
>>> Based on the above, it seems like this is the least bad option, and we<br class="gmail_msg">
>>> need to do this ASAP as currently UnsafeRawBufferPointer is<br class="gmail_msg">
>>> non-compliant with the requirements of slicing and needs changing<br class="gmail_msg">
>>> before it’s more widely adopted.<br class="gmail_msg">
>><br class="gmail_msg">
>> Or we could say that UnsafeRawBufferPointer isn't a Collection. Making<br class="gmail_msg">
>> it a Collection in the first place has always seemed suspect to me.<br class="gmail_msg">
>><br class="gmail_msg">
><br class="gmail_msg">
> If this is considered a viable option, it's the one I want. Passing<br class="gmail_msg">
> types without bounds checks into generic "safe" code shouldn't be this<br class="gmail_msg">
> easy.<br class="gmail_msg">
<br class="gmail_msg">
I don't think I agree, but that's a separate argument, about<br class="gmail_msg">
UnsafeBufferPointer. This is about passing *untyped* memory without<br class="gmail_msg">
bounds checks.<br class="gmail_msg">
<br class="gmail_msg">
> You should need to explicitly wrap it up in something safe. And I<br class="gmail_msg">
> really don't want the known-to-be-error-prone indexing model in<br class="gmail_msg">
> concrete unsafe code.<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
--<br class="gmail_msg">
-Dave<br class="gmail_msg">
<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div>