On FreeBASIC, I could do something like this:

Type GENERIC_PTR As Any Ptr

Dim i as GENERIC_PTR

Could I do something similar with QB64? Because when everything is _OFFSET the code is almost impossible to understand. Intensive use of comments help a bit but this naming trick could really improve the situation.

For example:

int somefunc(struct somestruct *data);

On QB64 it will be:

function somefunc&(byval data as _offset)

Who know what type is data? The only way to read comments.

But something like this really helps:

Type SomeStructPtr As _OFFSET

This is way easier to understand:

function somefunc&(byval data as SomeStructPtr)

On QB64, we only have _OFFSET and _MEM.
Look at this example:

https://www.qb64.org/wiki/Windows_Libraries

As you see, they have to substitute any pointer types with the generic _OFFSET. This is real trouble when interfacing with C or even doing something useful with it own.

Look at this example:

int somefunc(struct somestruct *data);

Which translate to this in QB64:

function somefunc%(byval data as _OFFSET)

How we actually use this in code?

Instead of parse it directly like on FB, we have to create it first:

dim data as somestruct

data.somefield = somedata;
...

somefunc%(_OFFSET(data))

This is how we call it. Think about it. How inconvenient it is? It's also not type-safe as the generic pointer _OFFSET has no type and we have to workaround this by comment, intensive comments! Instead of a self explantory declaration on FB:

declare function somefunc(byval data as somestruct ptr) as integer

p/s: FB stands for FreeBASIC.