Add atRawUnsafe and atUnsafe to array classes

[armanbilge]

Currently if you do:

// some native call
def foo(ptr: Ptr[Byte], len: Int): Unit = extern

val buf = new Array[Byte](0) // 0-length array
foo(buf.at(0), 0)

The buf.at(0) will throw an index-out-of-bounds exception, because the array is of zero length and there is no element at that position.

Does anyone else find this annoying? Whenever using .at I have to remember to to add a special case to handle 0-length arrays, even though the actual logic would not be broken. I keep forgetting and making bugs whenever I try to use this optimization 😅

The fundamental conflict is that I'm not interested in the element at the 0th position, I'm interested in the pointer at which the array data starts (no matter what length it is).

If nobody thinks it is harmful, I'd like to change the semantic here.

[armanbilge]

Shoot, I forgot these APIs are also used for array implementations, not just for users 😅 maybe we have to introduce a new API then ... 🤔

[WojciechMazur]

maybe we have to introduce a new API then

Yes, I agree. We can do it in one of two ways:

• add methods in runtime value similar to atRaw but without bound check, e.g. atRawUnsafe
• If you want to get the area of Array underlying memory we could also use runtime.MemoryLayout.Array.ValuesOffset to calculate the address to the start of the data area. (so we would something like fromRawPtr[T](castObjectToRawPtr(arr) + ValuesOffset))

[ekrich]

I think something like the atRawUnsafe to avoid the bounds checks would be good.

[armanbilge]

Thanks for the feedback. I updated the PR to add atRawUnsafe and atUnsafe methods.

[armanbilge]

We are already in the unsafe package. Actually I would prefer to make at directly delegate to the unsafe one because I am never interested in the safe one. But maybe that's too confusing...

[tanishiking]

I can understand we want to make atUnsafe as at since we are already in Unsafe package, but I believe that's too confusing as you mentioned and better to keep as it is 👍
When we enrich our library using import scalanative.unsafe._, people won't see at method comes from unsafe package at a glance, so naming atUnsafe makes sense to me even though atUnsafe sounds a bit redundant, my two cents.

[tanishiking]

Except https://github.com/scala-native/scala-native/pull/3327/files#r1283253067 it looks good from my side 👀

[tanishiking]

I can understand we want to make atUnsafe as at since we are already in Unsafe package, but I believe that's too confusing as you mentioned and better to keep as it is 👍
When we enrich our library using import scalanative.unsafe._, people won't see at method comes from unsafe package at a glance, so naming atUnsafe makes sense to me even though atUnsafe sounds a bit redundant, my two cents.