Support closures as host functions tracking issue

[MarkMcCaskey]

Wasmer does not currently support closures (functions with captured environments) as host functions, this is a tracking issue for progress on this feature.

The current plan is to reject closures in 1.0 and possibly support them in the future. Please let us know if this feature is important to your use case.

[aidanhs]

This seems like it'd help the ergonomics of environments a bunch.

Simple example:

Function::new_native_with_env(&store, script_len,
    move |&script_len_env: &u32| -> u32 { script_len_env })

vs

Function::new_native(&store,
    move || -> u32 { script_len })

---

Slightly more complex example:

struct MemEnv {
    #[wasmer(export)]
    memory: LazyInit<Memory>,
}
Function::new_native_with_env(&store, Default::default(),
    move |env: &MemEnv, data: WasmPtr<u8, Array>| -> () {    
          let memory = env.memory_ref().expect("memory not set up");    
          let data_cell = mytry!(data.deref(memory, 0, script_len).ok_or(()));    
          for (cell, &b) in data_cell.into_iter().zip(script.iter()) {    
              cell.set(b)    
          }    
      })

vs

struct ScriptEnv {
    script: Vec<u8>,
    script_len: u32,
    #[wasmer(export)]
    memory: LazyInit<Memory>,
}
let script_env = ScriptEnv { script, script_len, memory: Default::default() };
Function::new_native_with_env(&store, script_env,
    move |env: &ScriptEnv, data: WasmPtr<u8, Array>| -> () {    
          let memory = env.memory_ref().expect("memory not set up");    
          let data_cell = mytry!(data.deref(memory, 0, env.script_len).ok_or(()));    
          for (cell, &b) in data_cell.into_iter().zip(env.script.iter()) {    
              cell.set(b)    
          }    
      })

---

This latter example has a couple of points worth observing:

1. many functions may want a Memory, and so if I could capture environments I can use the single MemoryEnv struct between them and capture the rest. With no capturing, I have to define a fresh struct for every set of things I want to carry in the environment
2. a WasiEnv has a Clone bound, whereas a capturing Fn does not. This is relevant in the case above because script may be very large - I don't want to clone a script every time the function is called and it's not clear based on the trait bounds of WasiEnv if that might be the case. With a non-Cloneable Fn, I can be confident there's no data copying on calling my Function. Note that this point could be resolved by just documenting why the Clone bound exists on WasiEnv so that people can create data structures appropriately.

[syrusakbary]

This should be solved by Wasmer 3.0

[silwol]

The current master still contains an unimplemented!() call pointing to this issue at lib/api/src/js/externals/function.rs:482. Is it possible that this was changed in an inconsistent manner between lib/api/src/sys and lib/api/src/js? If the issue is not present in wasmer 3, the pointer to this issue shouldn't be necessary, I assume.
cc @syrusakbary

[epilys]

@silwol Yeah, lib/api/src/sys and lib/api/src/js need to be synced (-> in this direction). This should be a new ticket

[Hpmason]

Docs for 3.1.1 and 3.2.0-alpha still say that Function will panic with captured env. Does that still need to be updated?