rawCopy, rawTransfer, rawFind ?

[Damian]

On Friday, 26 October 2012 at 21:25:22 UTC, Dmitry Olshansky 
wrote:
> 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.)

These should definitely be put into the language!! but they'd 
have to be
100% reliable for me to adopt them over C equivalents.

unit std.memory anyone?