Slices are supposed to be safe pointers. Sadly, exposing an Array's internal pointer as a slice is unsafe, because the internal pointer may be reallocated, and accessing any exported slice would segfault.

Array#to_slice doesn't exist to not introduce a safety a feeling to the developer, when it's actually not. Use #to_unsafe and #size instead, so it's clear that you are dealing with something unsafe.

Maybe we could add Array#to_unsafe_slice?

#to_slice would be feasible, however it would have to copy the underlying memory.

What about this? Renamed #to_slice to #to_unsafe_slice, and made the documentation more clear on dangerous usage.

IMHO a Slice ain't just a Pointer with a size, but also caries the idea of a safe struct. It's obvious a Pointer is unsafe, it's less obvious a Slice is, because we sell Slices as a safe alternative to Pointers. Adding Array#to_unsafe_slice in stdlib would push the idea that a Slice can be unsafe, which I'm not comfortable with.

You must be very careful with the exported, unsafe Slice, too; if you are writing the slice to an IO, the IO will likely switch fibers, and... if something mutates the Array in another Fiber: 💥 segfault. You may be confident when you write the code that this won't happen... but what about a few weeks or months later? when you optimize Game.player_positions to reuse an Array instead of allocating one on each call?

I support @RX14 solution: allocate and copy memory (that won't trigger the event loop).

class Array(T)
  def to_slice
    pointer = Pointer(T).malloc(size)
    pointer.copy_from(to_unsafe, size)
    Slice(T).new(pointer, size)
  end
end

@ysbaddaden totally agree

If we're going with the allocate & copy solution, the documentation should mention that it's slow (copy the array buffer), and even slower on an Array of struct.

In that same vein, wouldn't it be better to be a little more explicit and call it copy_to_slice? Nobody reads the documentation of to_slice given it's so pervasive in the std

Are you sure? to_ already means an export, we do x.to_u32 not x.copy_to_u32. I agree that to_slice usually exposes internals directly, but isn't it a side-effect of objects having a stable internal pointer, which allows optimizations?

@ysbaddaden It is not-obvious that a call to #to_slice on an array would copy anything. I wouldn't expect it to. E.g. String#to_slice doesn't copy. Why it doesn't isn't that important, the user knows it's fast, the internal detail became a feature. That assumption would break with Array, causing headache if a production application suddenly slows down to a crawl.

Last argument, then I shut up: naming should be done consistently on what is expected to be returned, not internal details optimizations.

If a method could accept an Array, StaticArray, Slice of String or whatever, I would have to make a special case for Array, because it decided to use the unexpected #copy_to_slice instead of the expected #to_slice.

Silly example: what about a What#copy_to_s method?

Array is a high-level type, and taking slices from it is super unsafe because later the array can change and discard a whole slice (when realloc happens). I think it's better to use the to_unsafe way explicitly to show that something unsafe is happening.