Unsafe vs MemorySegments / Bounds checking...

[Ron Pressler]

> On 30 Oct 2024, at 20:19, Brian S O'Neill <bronee at gmail.com> wrote:
> 
> The problem is that the FFM API currently isn't a good enough replacement for the few remaining operations. It's close, though.

Another problem is that you have a very particular definition of “good enough” which is not the one we’re striving for. As Maurizio said, performance will improve, but identical performance to Unsafe in *every* case is not a goal (at least not currently).

> 
> Again, I think there's a misunderstanding. There's the full Unsafe class as it exists today, and there's the FFM API which provides a useful subset of the those operations. I have no personal attachment to the Unsafe class. The FFM API provides all the features I need already, but just in a more complicated and inefficient fashion. There's nothing preventing it from improving while still retaining all the other checks that it has.

Are you proposing to add a new restricted unsafe API for the probably small and hopefully shrinking class of applications that would be significantly affected when moving from Unsafe to FFM? This sounds like a big ask for an unclear benefit. First we’ll need to see how big the problem is and if improvements to FFM can’t take care of nearly all of it (again, absolute parity with Unsafe in *every* conceivable case is not an important-enough goal).

As for the simplicity aspect, that’s subjective, the FFM API was iteratively designed and refined over years, and even if you find the result not to your taste, the overall amount of code directly interacting with either FFM or Unsafe (let alone the “new Unsafe”) is expected to be relatively small and well-encapsulated. You’re now talking about offering different APIs to suit the different tastes among what is a small group of developers to begin with.

> The FFM API is mostly useless in that case, because foreign functions cannot be linked in anyhow.

That depends what is meant by “mostly”. There’s no doubt that FFI is a major aspect of FFM, but there’s useful stuff you can do with I/O without restricted methods.

— Ron