Whether and how to wrap size/pointer pairs?

[dertseha]

The API has a "data clump" of size and raw-pointer parameters in several of the API functions. (this topic originated from #18)
Consider two examples:

func CreateBuffer(context Context, flags MemFlags, size int, hostPtr unsafe.Pointer) (MemObject, error)
func SetKernelArg(kernel Kernel, index uint32, size uintptr, value unsafe.Pointer) error

Apart from the (somewhat deliberate) mismatch of size types, is this a potential candidate for a combined type that the API understands?

If this were an interface for example, it could look like this:

type HostData interface { // name not finalized
    Size() uintptr // or int
    Ptr() unsafe.Pointer
}
func CreateBuffer(context Context, flags MemFlags, data HostData) (MemObject, error)
func SetKernelArg(kernel Kernel, index uint32, data HostData) error

and then have factory methods like

func Uint32(value uint32) *HostDataUint32 // HostDataUint32 could be type HostDataUint32 uint32
func Slice(data []byte) *HostDataSlice // potentially via generics

so that it reads as

cl.SetKernelArg(kernel, 0, cl.Uint32(10))
cl.CreateBuffer(context, flags, cl.Slice(initData))

Is this acceptable? Too "clever"? Not too far away from the OpenCL API?`

Speaking of "too clever" - with the interface approach, user can provide their own, there could be a Raw(size int, ptr unsafe.Pointer) HostData- AND the built-in types like MemObject could implement this on their own.

Points to consider:

• Asynchronous APIs. For example, the copy operations demand that the pointers remain intact in case they are started asynchronously. Is this wrapper approach too dangerous in this case?

[dertseha]

Thinking about this, I am starting to grow on the idea of having data being passed via an interface, and the interface being implemented by some common types.

Another point that brought me to this were the native vector types, which have an additional alignment demand. I do not know whether these alignment properties are taken into account when a Go type is created from such a native type (as in type Float4 C.float4).
Furthermore they may be demand for memory blocks that have a fixed address - The Go runtime may move around memory of objects if it feels like it. And if the address of the first element of a byte array becomes invalid, this is bad for asynchronous buffer read/write actions. So a way to create a data block backed by unmovable C-memory may be necessary, and this is easier if done with a common type (interface).

On that note, it may also be necessary to look into runtime.SetFinalizer() and also runtime.KeepAlive().