It's very hard to avoid accidental copies when using system.string type. This makes it unsuitable for I/O, especially when moving around large blobs of data.

There is system.shallow(string), which helps a bit, but it's semantics are underspecified and I've struggled to use it. Anyway, I think it's bad idea to mark strings as copying/non-copying at runtime instead of at type level.

Therefore I propose inclusion of new View[T] type to the standard library. View[T] essentially points to an array in memory and in most basic form View[T] = tuple[pointer: ptr T, length: int]. It is modelled after Go slice and after my implementation of View[T] in collections.nim. Similar ideas were discussed before e.g. 1, 2.

The requirements for the type are as follows:

• non-copying slice(self: View, start: int, length: int) operating, which returns subview of self.
• ability to construct views pointing to arbitrary memory (useful for C interop)
• at least partial memory safety - e.g. slice checks for index of bounds errors

It's easy to implement type that fullfils these requirements. However, there are two question:

• should there be separate ConstView and VarView types (to mark immutability in type system)?
• should memory pointed by views by tracked by GC?

GcView?

The basic version, implemented as View[T] = tuple[pointer: ptr T, length: int], is not memory-safe when not used carefully.

It's possible to add third field gcptr: RootRef, that can be used force GC to keep memory pointed to by View alive. I've tested this approach before in go2nim branch of collections.nim: gcptrs, goslice (go2nim was my attempt at creating Go to Nim translator).

The main disadvantage is that this increases size of the type to 3 words (e.g. 24 bytes on amd64) and makes making copies a bit more expensive. Maybe we should create separate types ViewPtr and ViewRef?