[foreign-memaccess+abi] RFR: Add support for high-level functions to copy to and from Java arrays [v5]

[Maurizio Cimadamore]

On 25/06/2021 01:50, leerho wrote:
> There is no perfect solution here.

I agree  that there's no silver bullet, however:

* When thinking a bit how the API might work, I think at some point it 
becomes obvious that the length of the copy _must_ be specified in 
elements - that's the only sensible choice, otherwise you end up with 
either partial element copies or exceptions (in case we want to defend 
against partial copy). So, I found myself that, after working with the 
API for few days, I internalized what the API was trying to do, and 
after that point I was constantly fighting with the positioning of the 
length parameter (for which, by then, couldn't see any other alternative 
than expressing it in elements).

* Diverging from similarly looking APIs has a cost too. Yes, it's not 
exactly similar to System.arrayCopy - there are more issues here for 
sure - but I think it depends on how you look at things, and on how much 
you want the differences to "pop out" in the new signature. The 
signatures we have now are screaming for "I'm new and different!" while 
I think at least some users will not find them _too_ different.

I think the key observation is the one you made few weeks ago: the 
natural offset for segments is expressed in bytes, while for arrays we 
work with element indices. That's a good summary which should probably 
be captured somewhere in the javadoc. Once the user internalizes that, I 
believe it is safe to go back to the src/dst model w/o worrying too much 
about unit mismatches: given that length has to apply to _both_ 
parameters, and given that some parameters are offset-able and others 
are index-able, the only possible choice for the length parameter is to 
work off indices/elements (to avoid the problem mentioned above).

I think for now I'll just integrate what we have - but I believe that 
this needs to be rediscussed.

Another thing worth considering is whether MemoryCopy should have a 
static method for copying segments into segments:

copy(MemorySegment src, long srcOffset, ValueLayout srcLayout, 
MemorySegment dst, long dstOffset, ValueLayout dstLayout, long bytes)

and, maybe, an overload for simple cases where no swapping is desired:

copy(MemorySegment src, long srcOffset, MemorySegment dst, long 
dstOffset, long bytes)

I think these would be useful. MemorySegment::copyFrom is a fluent 
version of the copy methods, which I'm sure is handy if you already 
happen to have the right segments in your hands. But I believe that 
slicing and offseting just in preparation of a copy is, as we have 
learned in this thread, a conceptual overhead that we'd like to leave to 
the API implementation, so that, when reading the code, the intent is 
made clearer.

Maurizio