Inner functions declarations should allow type elision

[bryanlarsen]

OK, this is the third time this has happened to me, and I'm starting to get annoyed.

I'm writing a function, find some duplicated code and then move the duplicated code into a closure to avoid copy-paste errors etc.

Then the compiler whines about the closure capturing a variable as mutable so I can't use the variable anywhere else.

So I convert the closure into an inner function to avoid the capture, and suddenly my nice clean code is littered with line noise due to ugly type annotations full of angle brackets.

I understand the reason why we don't type elide public functions. IMO private functions should allow type elision, but I can take it or leave that. But inner functions definitely should allow type elision.

In the particular case I could probably also get rid of the duplicated code once RFC 2497 lands, but that's just this particular instance and not my other ones.

Of course, if the closure captured at time of use rather than time of definition I would also be fine, but I remember using Lisp's with dynamic scopes and that's a horror we don't want to revisit.

[kpreid]

You could use the closure syntax while avoiding capturing anything in it.

fn outer(foo: ...) {
    let helper = |foo_by_arg_not_capture| { ... };
    helper(foo);
}

This way, helper doesn't have any captures but also doesn't require a full signature. Closures without captures can be used in all the ways function items can (except for being generic).

[bryanlarsen]

When I tried that, I ended up with E0282: type annotations needed. Which seems odd, can it not just infer the types from what I pass into the closure? I call the closure the same way every time.

But it did infer the return type, which was the main source of the line noise four levels of angle brackets deep.