POV: rlua should only be concerned with rust-side safety and soundness

[SoniEx2]

Currently, rlua does some stuff like:

• remove debug
• remove native modules
• remove bytecode loading
• replace pcall/xpcall/etc
• replace coroutines? (see also: pcall/xpcall/etc)
• among other things

In other words, it attempts to be a Rust-based implementation of OpenComputers, a Lua sandbox. At this point, why not just use wasm instead? - which incidentally is something we're attempting to do with OpenComputers because it provides better sandboxing than trying to patch Lua, and allows exposing all the APIs without worrying about holes.

Instead, "High level Lua bindings to Rust" should be just that - bindings, not an entire sandbox!

References: #116 , README, [...]

---

If you take our former hexchat-plugin crate as an example, for making hexchat plugins, it does its best to prevent the Rust plugin from having bugs, but doesn't try to actively prevent other plugins from having bugs that interact badly with the Rust plugins. (where possible, we tried to submit upstream patches to hexchat instead, altho we didn't have much success with that because we were kind of a prick back then. >.<)

So we do think things like handling userdata soundness (#19) is important, even when the Lua code is explicitly calling __gc on the userdata twice. But it should not be implemented through "replacing Lua".

[jugglerchris]

Hi,
I think this is covered by #190 and #192 .