IME partial copy primitives are lacking, so I use this:

/// Copy only as much as possible, return the copied data
T[] CopyHead(T)(T[] dst, in T[] src) pure
{
	if(dst.length>=src.length)return CopyAll(dst, src);
	CopyOverlap(dst, src[0..dst.length]);
	return dst;
}

/// Copy all input data, return the copied data
T[] CopyAll(T)(T[] dst, in T[] src) pure
{
	assert(dst.length>=src.length);
	dst=dst[0..src.length];
	CopyOverlap(dst, src);
	return dst;
}

/// Copy overlapping slices
void CopyOverlap(T)(T[] dst, in T[] src) pure
{
	import core.stdc.string:memmove;
	assert(dst.length==src.length,"same lengths required");
	byte[] dstBytes=cast(byte[])dst;
	memmove(dstBytes.ptr, src.ptr, dstBytes.length);
}

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

On Thursday, 30 May 2019 at 09:10:11 UTC, Mike Franklin wrote:
>Regardless, a public interface should be
> required to achieve the goals of the GSoC project and could introduce controversy and other design complications.

should --> shouldn't

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