Additional mismatch overloads for memory segments

[Maurizio Cimadamore]

On 14/06/2022 11:53, Alexander Biryukov wrote:
> From my perspective the Java ecosystem has a "duality" in static and 
> instance methods. But probably this observation comes from Arrays and 
> many Apache *Utils libraries.
> I think it's not really necessary to pick one, why shouldn't there be 
> 2 ways, at least for the functions which make sense to do so (binary 
> operators).

This is true, we should not feel compelled to _have to pick one_. That 
said, especially in the case of `copy`, where directionality is 
important, a static method is, I think, a superior choice (in fact the 
instance version is called "copyFrom", to make the directionality pop 
out a bit more). But yes, we could still provide both (for binary 
methods), for convenience.

The main point I wanted to make is that an offset parameter makes sense 
in _all_ the instance methods of memory segment (the unary operators). 
Because, if there's no offset argument in these methods (e.g. toArray) 
and you use your own offset system (like you do), the API becomes full 
of "sharp edges" where you can't just pass an offset and you have to 
slice instead.

That's why I'm trying to uplevel the discussion a bit: if storing a 
MemorySegment and an associated long offset is a common enough operation 
in certain contexts, and we want to support that use case, then we need 
to pick a solution that's consistent about it, rather than speculating 
on how useful adding an overload on one particular operation might be. 
The latter is at severe risk of extrapolating from too few use cases, 
since this is a new API (the fact that we're having this discussion 
again after the one on copy is in itself a revealing fact).

Maurizio