rawCopy, rawTransfer, rawFind ?

[Dmitry Olshansky]

Finally got to this: http://d.puremagic.com/issues/show_bug.cgi?id=8349

Half way through it become obvious to me that we'll have similar 
problems with memcpy and it's ilk every time somebody optimizes bit-wise 
copy/move/find.

More then that I think that we lack a specific set of low-level 
functions that cover all of C's mem* functionality.
(The focus is on fast primitives.)

Currently there are obvious gaps:
memset ---> cast(ubyte[]) + array ops
memcpy ---> cast(ubyte[]) + array ops (also breaks with overlap)
...so far so good...
memmove ---> ???
memchr ---> cast(ubyte[]) + std.algorithm.find is *not* good enough

(in fact std.algorithm.find arguably could use memchr to greatly 
optimize some specializations (!) )

Why don't we just use C's ones?
a) CTFE-ability, alternatively we can just hard wire all of common libc 
functions into CTFE
b) more generality and/or flexibility, e.g. despite it's speed memchr 
can't search for ushort or uint
c) safer, as it would operate on slices of _typed_ arrays, not pointer + 
number of _bytes_

So I propose the following set of low-level tools for inclusion into 
Phobos or druntime:

@system:
//bitblit, doesn't call destructors/postblits
//also can be used to forcibly move structs
void rawCopy(T)(const(T) src, T dest);

//same, but also works with overlapped memory chunks
void rawTransfer(T)(const(T) src, T dest);

//fast search, bitwise comparison only
void rawFind(T)(const(T)[] src, const(T) needle);

Well the above is a sketch. Maybe I'm digging in the wrong direction and 
this stuff just needs to be somewhere among compiler's intrinsics.
(so that it can do some magic if the size is known in advance etc.)

-- 
Dmitry Olshansky