consider removing the environment pointer parameter

[thestinger]

This isn't a huge problem, because the deadargelim pass can remove it if the function is internal and the address isn't taken and passed around non-trivially.

Without the environment parameter, creating a (boxed) closure would require making a local wrapper function making a cheap static tail call to the real function.

I don't think replacing a single virtual call with a virtual call and an extra static call will matter much. If we ended up adding unboxed closures to the type system, there would be fewer cases where this would be necessary.

It's hard to say what the best compromise would be.

[thestinger]

cc @nikomatsakis

[nikomatsakis]

I agree a wrapper function is reasonable, however I think it would have to be used whenever we coerce to a fn type, not just to a closure type, unless that target fn type has an ABI other than Rust. The reason is because of code like the following:

let mut f: fn(uint) = foo;
if cond { f = bar; }
use(f);
fn use(f: |uint|) { ... }

So basically we could optimize direct calls but not indirect ones. I think this is fine.

Another simpler option I have considered is moving the environment pointer to the end of the list. In most (all?) ABIs that I have seen, the first few parameters are privileged with respect to registers and so on. This would be an improvement, I suspect, but for functions with few parameters wouldn't make any difference.

[brson]

It is a shame to be wasting the best registers on null pointers. It seems like just putting the environment arg at the end would solve most of the problem, since the actually used arguments get registers and the environment is first to get punted to the stack.

[nikomatsakis]

Is it the case that in all C ABIs it is OK to pass extra arguments? In that case, we could (1) move env pointer to the end for closures and (2) remove it altogether for bare functions. When a bare function is promoted to a closure, and called, an extra NULL would be passed, but it'd be ignored.

[pnkfelix]

�What is "all C ABIs" supposed to denote?
�
If I understand the dialogue so far, the problem would arise for any calling convention where the callee is responsible for cleanup (i.e. popping its received arguments off of the argument stack). Wikipedia has an index of such calling conventions for x86 here.

[nikomatsakis]

My comment was imprecise. This is not an issue for any ABI other than "Rust", since closures only use the "Rust" ABI. And we can of course freely define Rust how we like. But in practice what we do is compile Rust closures "basically" like C functions, except not entirely since we don't follow precisely the same rules regarding when to pass by ref and when not (perhaps we should).