Having trouble with LuaFunction::wrap_raw() in v0.10

[alerque]

I'm playing around with RC.1 trying to figure out how to handle my traits and types ergonomically, currently using decasify as a place to experiment without the project being too big to easily fiddle with.

Note that if this issue doesn't make sense I can try packaging it into an MWE.

I'm trying to simply the full set of extra functions and type conversions I used in v0.9.x (see also #424) and have a local type (Chunk) that I have implemented Into for a number of common string types (&str, String, &Cow<'_, str>, etc.). I also have functions that accept imp Into<Chunk>. What I'm trying to do is wrap those functions in a Lua module without writing a bunch of shim functions.

Here is a sample function signature I'm using for testing. For ease of testing I'm just discarding the data for now and just trying to get the types right.

pub type Result<T> = anyhow::Result<T>;

#[mlua::lua_module]
fn decasify(lua: &Lua) -> LuaResult<LuaTable> {
    let exports = lua.create_table().unwrap();
    exports.set("test", LuaFunction::wrap_raw(test_func))?;
    Ok(exports)
}

pub fn test_func(_s: String) -> Result<String> {
    Ok("some pseudo return data".into())
}

This works by itself so the basic bones of my test seem to be in place.

Now lets look at my trait. By itself the Into<Chunk> compiles fine, but I can't seem to use it in a function:

impl FromLua for Chunk {
    fn from_lua(_value: LuaValue, _: &Lua) -> LuaResult<Self> {
        Ok(Self {})
    }
}

pub fn test_func(_chunk: impl Into<Chunk>, _s: String) -> Result<String> {
    Ok("some pseudo return data".into())
}

This falls apart because it can't figure out what to do with the function signature:

 1  error[E0283]: type annotations needed
   --> src/lua.rs:27:26
    |
 27 |     exports.set("test", LuaFunction::wrap_raw(test_func))?;
    |                          ^^^^^^^^^^^^^^^^^^^^^ ----- type must be known at this point
    |                          |
    |                          cannot infer type of the type parameter `F` declared on the associated function `wrap_raw`
    |
    = note: cannot satisfy `_: Into<content::Chunk>`
 note: required by a bound in `test_func`
   --> src/lib.rs:52:27
    |
 52 | pub fn test_func(_chunk: impl Into<Chunk>, _s: String) -> Result<String> {
    |                           ^^^^^^^^^^^ required by this bound in `test_func`
 help: consider specifying the generic arguments
    |
 27 |     exports.set("test", LuaFunction::wrap_raw::<_, (A, std::string::String)>(test_func))?;
    |                                               +++++++++++++++++++++++++++++++

I can tinker with that wrapper a bit and get it to compile:

exports.set("test", LuaFunction::wrap_raw::<_, (String, String)>(test_func))?;

But that seems like an unnecessary hoop to jump through, and overly restricting. I don't actually want the Lua function to only accept strings, I want to be able to implement this for other possible Lua types as well.

Is it apparent what I'm missing or is this a bug or a missing feature? Or does none of this make sense and I should work up an actual stand alone MWE?

[khvzak]

Any function argument should implement FromLua trait (not Into<Chunk>). What is the purpose of Into<Chunk> argument?

[alerque]

The purpose of the internal types (Chunk struct, Locale enum, etc.) is that we're internally using specific types, but also providing an API interface where people can pass us what they have and get what they want back. Rather than having one set of functions to operate on &str and another on String and another for Cow<...>, etc. we just have a single function fn (c: impl Into<Chunk>) and implement From<T> for all the things we can work with. This allows a simpler more robust API on the Rust side.

For Lua I'm just trying to pass the Rust functions off in a module (and ditching the wrapper functions I had to write for v0.9). I've setup impl FromLua for Chunk, so it should be possible for mlua to deduce what needs to happen. But in the ned it still needs a hint.

Here is a more concise rundown of my findings:

impl FromLua for MyStruct

fn myfun (c: impl Into<MyStruct>)

// I expected this to work:
LuaFunction::wrap_raw(myfun)

// Instead I have to give it an extra hint with confusing semantics (note comma and empty place holder are required):
LuaFunction::wrap_raw::<_, (MyStruct,)>(myfun)

Here it is working in context, but these wrap_raw() hints seem unnecessary:

https://github.com/alerque/decasify/blob/mlua-v010/src/lua.rs#L52-L71

They basically just mirror what the function signatures have, swapping the impl Into<> for a concrete type:

https://github.com/alerque/decasify/blob/mlua-v010/src/lib.rs#L30-L91

[khvzak]

This is how Rust type system works.

Rust functions in Lua require types that implement FromLua trait. Having Into<MyStruct> does not mean that FromLua is satisfied for all types.
When you give type hint you reduce possibilities to only MyStruct type and nothing else.
In another words, the missing piece is

impl<T: Into<MyStruct>> FromLua for T {}

which is impossible because FromLua is a foreign trait.

If you change your definition to:

fn myfun (c: impl Into<MyStruct> + FromLua) {}

it should work without the missing piece.

Or more realistically define a public wrapper that will automatically convert + call normal func:

fn myfun (c: impl Into<MyStruct>) {
    myfun_impl(c.into)
}

fn myfun_impl(c: MyStruct) {
 // logic
}

[alerque]

This is how Rust type system works.

Thanks for the explanations. I think I've made sense of this all and the ergonomics aren't too bad. The error messages understanding what is what on the other hand are a bit cryptic. I don't think mlua is responsible for those though.

Having Into<MyStruct> does not mean that FromLua is satisfied for all types.

Actually it does since there is provable 100% overlap. That being said I've done some scrounging and found many other instances of this problem unrelated to mlua. The issue seems to be that there are multiple pathways between X and Y. Provably all X can be used for Y, but the compiler doesn't have enough info to know whether it should get there by X→A→Y or X→B→Y or in my case actually X→Y directly has an implementation..

The hint I was providing above (String) was not convincing the compiler that the trait could be satisfied, but picking which route to satisfy it. And it was a bad pick of routes to, the obvious one was to just pick the direct route: I can just give it it the hint Chunk instead of String the final function can optimize away the extra .into() later.

When you give type hint you reduce possibilities to only MyStruct type and nothing else. In another words, the missing piece is

Sort of, but what I was misunderstanding is that the hint is not for what Lua is allowed to accept (which is always LuaValue) but what it will be coerced to before running the Rust function.

If you change your definition to:

fn myfun (c: impl Into<MyStruct> + FromLua) {}

it should work without the missing piece.

Thanks for the suggestion, but that would mean forcing the crate to be built with Lua support, which I don't want to do. The Lua interface is an optional feature, so changing the original signatures is not an option.

Or more realistically define a public wrapper that will automatically convert + call normal func:

fn myfun (c: impl Into<MyStruct>) {
    myfun_impl(c.into)
}

fn myfun_impl(c: MyStruct) {
 // logic
}

A public wrapper with all the casts is exactly what I was trying to avoid, but at it turns out that isn't needed. wrap_lua() creates the wrapper and the necessary hints make some sense. They should just be MyStruct to wrap anything that takes impl Into<MyStruct> instead of some random other Rust native type that has an implementation trait.

The only remaining puzzle for me is why the empty field is needed here:

fn myfun (_: impl Into<MyStruct>);

// Doesn't compile
LuaFunction::wrap_raw::<_, (MyStruct)>(myfunc);

// Works fine
LuaFunction::wrap_raw::<_, (MyStruct,)>(myfunc);

This seems to only be the case for functions that take one argument, as soon as I tried it with functions that took two or more arguments, the lineup of types makes perfect sense.

fn myfun (_: impl Into<MyStruct>, _: impl Into<MyEnum>);
LuaFunction::wrap_raw::<_, (MyStruct, MyENum)>(myfunc);

No complaints there. Why does that make so much more sense?

[sxyazi]

The only remaining puzzle for me is why the empty field is needed here:

They are two different types in Rust, with or without a comma (,):

fn print_type<T>(_: &T) { println!("{}", std::any::type_name::<T>()) }

let a = (1);
let b = (1,);
print_type(&a); // i32
print_type(&b); // (i32,)

[alerque]

Thanks @sxyazi I was today years old when...