Don't require all parameters of callback function for .map, .filter, etc.

[vgrichina]

Most of the time someone uses .map they don't want to handle all arguments, but only first one, i.e. write code like this:

items.map(it => it.name);

Is it possible to implement in AssemblyScript using e.g. trampoline function of proper type passed to .map which will just passthrough throwing out extra args? Ideally compiler should also be able to inline whole construction into single loop in case when passed function is constant.

[willemneal]

I know this is not exactly what you're looking for and a bit ugly, but you could use underscores to ignore the other arguments.

let y = x.map<i32>((x:i32,_:i32,_:i32[]):i32 => x + 1);

[MaxGraey]

@vgrichina This of course possible. Actually inferring is not always optimal for now. We discussed about this with @dcodeIO some time ago and I know how this probably resolve. But maybe @dcodeIO has its own solution and point of view on current problem?

[dcodeIO]

For a bit of background, we currently have a signature like this:

map<U>(callbackfn: (value: T, index: i32, array: Array<T>) => U): Array<U>

The limit here is the call_indirect instruction emitted within the map function's body that is fixed to a specific signature, let's call it "T,i32,T[],U[] for its parameter and return type, of the callback function at compile time, as it can't call "T,i32,U[]" or "T.U[]" directly.

One solution is some sort of trampoline, as proposed above, that wraps a "T,U[]" for example into a "T,i32,T[],U[]" at compile time that just ignores additional parameters "i32,T[]", looking something like this:

array.map(function trampoline(value, index, array) => actual(value));

Another solution could be a signature like

map<U,F=(value: T, index: i32, array: Array<T>) => U>(callbackfn: F): Array<U> {

that'd then compile to unique versions of the map function for each actual signature type provided, but not sure how feasible this would be.

[dcodeIO]

There's also this Binaryen pass that might help: https://github.com/WebAssembly/binaryen/blob/master/src/passes/FuncCastEmulation.cpp, but it looks like it would be somewhat intrusive ABI-wise (all call_indirects going through some overhead with complicated call signatures).

[MaxGraey]

I prefer solution without dynamic cast emulation. We could use syntactic sugar for this.

1. Inferring parametric type of array instance
2. resolve generic closure signature by type inferred in step 1 (we know how signature should look like)
3. replace existing signature to polyfilled.

Example steps:

1. arr.map(val => val) --> arr.map<i32[]>(val => val)
2. arr.map<i32[]>(val => val) --> arr.map<i32[]>((val: i32): i32 => val)
3. arr.map<i32[]>((val: i32): i32 => val) -->
   arr.map<i32[]>((val: i32, _unused_$1: i32, _unused_$2: i32[]): i32 => val)
   This could provide by creating new func signature and copy function body from actual function

[vgrichina]

BTW, is there any reason why types have to be specified on inline function definition?
It looks should be possible to derive them from .map signature.

[dcodeIO]

If I'm not mistaken then one of the issues here is that contextual types are somehow lost when trying to resolve the inner types of an inferred signature, or something along those lines. Not an intended limitation.

[dcodeIO]

As an alternative solution, the PR linked above now explicitly compiles function expressions to match the context they are used in, in turn allowing us to infer parameter and return types and to omit any number of parameters in such cases.

It looks like this solves all cases mentioned in this issue, but the trampoline idea still remains valid in a scenario like

function foo(): void {}
arr.map(foo);

where a trampoline would be necessary to simply ignore excess arguments in order to make the call_indirect valid.