Thread overview
core.thread.memcpy conflicts with core.stdc.string.memcpy
Oct 17, 2014
Marco Leise
Oct 17, 2014
Sean Kelly
Oct 18, 2014
Marco Leise
October 17, 2014
When I read that error I wondered why anyone would define a function for threads with the same name as a well established C function. On a closer look it revealed to be just another name for the same extern(C) memcpy to avoid the import of core.stdc.string in core.thread:

private
{
    import core.sync.mutex;
    import core.atomic;

    //
    // from core.memory
    //
    extern (C) void  gc_enable();
    extern (C) void  gc_disable();
    extern (C) void* gc_malloc(size_t sz, uint ba = 0);

    //
    // from core.stdc.string
    //
    extern (C) void* memcpy(void*, const void*, size_t);

    //
    // exposed by compiler runtime
    //
    extern (C) void  rt_moduleTlsCtor();
    extern (C) void  rt_moduleTlsDtor();

    alias void delegate() gc_atom;
    extern (C) void function(scope gc_atom) gc_atomic;
}

Well, it is mildly annoying. `private` doesn't really help in the way the author expected it to work here.

-- 
Marco

October 17, 2014
Its a holdover from when we were trying to eliminate imports in druntime because of the associated overhead. I'd submit a bugzilla about it.
October 18, 2014
Am Fri, 17 Oct 2014 15:54:27 +0000
schrieb "Sean Kelly" <sean@invisibleduck.org>:

> Its a holdover from when we were trying to eliminate imports in druntime because of the associated overhead. I'd submit a bugzilla about it.

Alright, I guessed so. https://issues.dlang.org/show_bug.cgi?id=13627

-- 
Marco