I'm a mad person and want to use existing C/C++ modules in the same VM as rlua

[Alloyed]

So context: I have a game server written in the love framework, which is your usual C++ framework composed of little modules that are exposed to lua. I'd like to replace the underlying framework layer with something I'm writing in rust, but I like the fact that any love game client can also be a self hosting server, so where it makes sense I'd like to provide a level of API compatibility between the two frameworks.

for my proof of concept, I am literally just taking a custom built love.so and requiring it from my rlua-hosted script:

love.filesystem = require 'love.filesystem'
love.filesystem.init()
-- my app code 

and this totally works! there is nothing stopping me from pulling in whatever insane C++ code I want.

I don't want to rely on this forever, especially considering #116 implies that it should be going away, and that from a wider perspective I would like to limit what I can run to a nice contained subset of useful stuff that runs on any platform. This means that supporting arbitrary native modules is an explicit non-goal.

So my options are, as near as I can tell:

1. Rewrite it all in Rust. This is only half a joke.
2. Take the C++ api provided by love, and write my own rlua-based wrappers around each piece of functionality. (rewrite the bindings in Rust).
3. something analogous to this really rough snippet (rewrite the entry point in Rust):

lua_ctx.create_unsafe_function(|lua_ctx, L: ActuallyJustALuaStatePtr|
  unsafe { let num_args = luaopen_my_lib(L); Ok(lua_values_from_stack(L, num_args)) }
)?

4. Don't do this.

Is 3 even remotely within the realm of possibility without fundamentally compromising rlua's safety model? Could I take steps to enable this for my one usecase without necessarily making it a core rlua feature?

[kyren]

The ability of require to load C libraries would never go away, it would just be behind an unsafe boundary.

Eventually, I'd like it if you could get at the lua state pointer from Lua and construct Lua from external state pointers (unsafely). You could do what you wanted by just creating a C closure using the Lua C API as you normally would, anything that is of type LUA_TFUNCTION will end up as an rlua::Function if you get a handle to the value via rlua.

This comes up when you want to use rlua in "module position" as well as when you also want to interoperate with things that use other Lua bindings strategies.

The main things I need to do are 1) document what is and isn't safe when you do this, and 2) make rlua stop using the "extra data" section of the main Lua state pointer.

I haven't had a lot of time recently to devote to rlua unfortunately, but I'll try to get around to this in the near future.

[jugglerchris]

Closing as the original question has been answered. I have opened #209 to cover the access to the underlying Lua state.