Generalize .ptr to RawPtr ranges?

[Dmitry Olshansky via Digitalmars-d]

On 06-Oct-2015 01:36, Brad Anderson wrote:
> On Monday, 5 October 2015 at 10:06:04 UTC, Dmitry Olshansky wrote:
>> Just a random idea - slices have .ptr and therefor have a bunch of
>> advantages such as SSE optimized copy routine.
>>
>> Once I wrap a slice in something (anything) it looses ALL of that.
>> Now for instance std.container.Array!int.Range can easily provide .ptr
>> property, together with .length it would allow us to use memcpy etc.
>>
>> Maybe generalize to isRandomAccessRange!Range + hasRawPtr!Range, where
>> hasRawPtr!(Range) would test for compatible .ptr and .length.
>>
>> The benefit compared to manually slicing the .ptr and using that, then
>> propagating the change back to the original range is that:
>>     - it's error prone
>>     - awkwardly replicated at each call site
>>
>> So it would be much better to retain safe range interface and
>> encapsulate speed-hacks inside of the algorithms.
>>
>> Thoughts?
>
> Somewhat related, C++17 is going to add the concept of Contiguous
> Iterators.
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3884.pdf

I'm thinking it might be better to add support RawChunkedAccess for 
ranges that can offer raw pointer(s) but only in bits and peices like 
e.g. a typical dequeue would or more generally segmented data 
structure/range.

If these two cases could be unified in some satisfactory that would be a 
huge win.

-- 
Dmitry Olshansky