memcpy, memset, memcmp and friends in the D Runtime

[monarch_dodra]

On Wednesday, 9 April 2014 at 12:12:35 UTC, Mike wrote:
> On Wednesday, 9 April 2014 at 11:50:13 UTC, Daniel Murphy wrote:
>> "Mike"  wrote in message 
>> news:iflykgpsrmdbfhuwzqtp at forum.dlang.org...
>>
>>> So, my question remains:  If I'm porting D to a platform that 
>>> has no C library, shouldn't a public, supported function that 
>>> copies memory be added in the D Runtime?
>>
>> What platform doesn't have a C library?  And you can always 
>> cast arrays to ubyte[] before assigning to avoid postblit.
>
> My custom, bare-metal, D-only platform has no C library, nor 
> will it ever.  And, Yes, I know I can cast, but should I?
>
> memcpy is used quite often in Phobos.  Here's a small sample 
> from std.array:
>
> void trustedMemcopy(T[] dest, T[] src) @trusted
> {
>     assert(src.length == dest.length);
>     if (!__ctfe)
>         memcpy(dest.ptr, src.ptr, src.length * T.sizeof);
>     else
>     {
>         dest[] = src[];
>     }
> }
>
> You could ask the same question there, "Why isn't a cast used 
> instead?" and remove the dependency on the C library.
>
> So far, it seems D has only been used on one subset of computer 
> systems that happen to have a C library, but some of us our 
> trying to break some new ground with D.  I'm challenging the "D 
> is only useful on PCs with a C library" bias and looking to see 
> if D has the will to stand on its own two feet instead of 
> leaning on C.

I think arguably, there should be D equivalents of the C runtime 
functions, if only for the added safety of slices (for example, 
memchr could be 100% certifiably safe), and to avoid the rampant 
deduplication of things as in the above, because of CTFE.

These may or may not use the C-runtime library. But at that 
point, it would become a "druntime implementation detail", rather 
than rampant usage throughout phobos.