Best interface for memcpy() (and the string.h family of functions)

[Mike Franklin]

On Thursday, 30 May 2019 at 08:28:50 UTC, Stefanos Baziotis wrote:

> If we don't really target users, then that makes this:
>
>> Apart from that, I'm still sceptical about whether we should 
>> provide
>> a version with size..
>
> Not important. Because my thought was that a lot of users would
> have some pointers a, b and somehow want to do: memcpy(a, b, 
> for_some_size);
>
> What I'm thinking is that yes, we decouple D from libc _on D 
> Runtime_.
> But in general, users may will still want that.

If users need to copy blocks of memory they should first prefer 
those D features that were added to improve upon C, so users 
don't have to resort to raw pointers, pointer arithmetic, 
managing sizes outside of arrays, etc.  See Walter's article "C's 
biggest mistake" for some perspective on that 
http://www.drdobbs.com/architecture-and-design/cs-biggest-mistake/228701625 It's important when designing a D replacement for a C feature to not repeat C's mistakes.

I wouldn't rule out a public interface in the future, but, at the 
moment, I don't see a compelling use case given that D has 
first-class arrays.  Regardless, a public interface should be 
required to achieve the goals of the GSoC project and could 
introduce controversy and other design complications.

Mike