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

[Stefanos Baziotis]

On Thursday, 30 May 2019 at 09:10:11 UTC, Mike Franklin wrote:
>
> 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 agree with Walter on that. I don't think though that ref, 
dynamic arrays as
now and GC are the solution to that or low-level memory 
management in general.

I think that people are in 2 categories:

1) People that use these D features will probably never want to 
use mempcy() (directly) anyway.
2) People that use D more as a betterC will probably want to use
a memcpy() with pointers and possibly one more optional 
parameter, in which they will give size.

But, some important notes:

a) D moves in a certain direction, away from C, pointers etc. And 
it moves
towards ref, dynamic arrays. Agreeing with that is not important, 
but help
is.

b) If memcpy() targets (possibly only) the D Runtime, then it 
doesn't really
care for the users in category 1) or 2) as they are on the user 
side.

So, I think the best option in this regard, especially note a) is 
to use refs,
unless there are serious implementation obstacles (which I doubt).

- Stefanos