The code is passing the function pointers into Win32 APIs, so the caller side isn’t controlled; the callbacks have to work as native C function pointers.

This was probably posted in response to this other link from two days ago, which is about about JIT-compiling wndproc callbacks in particular; the comments discuss the “proper” way to do it, which is to use GWLP_USERDATA:

https://news.ycombinator.com/item?id=46259334

At least, that’s the proper way to do it if you control the entire application. But for what’s apparently a thin wrapper that exposes Win32 APIs directly to Lua, I can understand picking an approach that makes life easier for the Lua code author, even if it’s hackier under the hood. It also avoids the need to write custom behavior for each API.

It was inspired by that post, but not in response to it. Over the 3 or 4 months that I took writing lowkPRO, one of the features I'm most proud of is this, the ability for it to create C callbacks on the fly that just call Lua callbacks and return the value to C. And I would argue that it's not hacky but just well-engineered. After all, everything compiles to assembly at the end of the day, right?