Functions provided in a vector to a vec::each can't be called

[AngryLawyer]

This may turn out to me being a plonker, but while maintaining rust-sdl to match the latest version of Master, I had to swap out vec::iter for vec::each, as the former has vanished.

I have code similar to this:

fn first() {
    io::println("LOL FIRST");
}

fn second() {
    io::println("LOL SECOND");
}

fn main() {
    let functions = [
        first,
        second
    ];

    for functions.each |func| { func(); };
}

And I'm getting this in response.

first_class_test.rs:15:32: 15:39 error: mismatched types: expected function or foreign function but found &fn()
first_class_test.rs:15     for functions.each |func| { func(); };
                                                       ^~~~~~~

Any ideas?

[bstrie]

We were so close to figuring it out! That vec::each change has, in fact, made it in, and it also turns out that () binds more tightly than *. So this works:

fn main() {
    let functions = [
        || io::println("LOL FIRST"),
        || io::println("LOL SECOND")
    ];

    for functions.each |func| {
        (*func)();
    }
}

Though if you're calling func multiple times inside the loop you should probably reassign it for convenience:

    for functions.each |func| {
        let func = *func;
        func();
    }

This still feels a little grody, though. Niko has noted a potential solution for this in rust-lang/prev.rust-lang.org#1, via supporting infallible matching in parameter lists. That would enable you to write it a bit more naturally:

    for functions.each |&func| {
        func();
    }

@nikomatsakis, would you mind opening an issue for infallible matching in parameter lists, so it doesn't get forgotten? I get the feeling that people are going to keep stumbling/grumbling over this.

[AngryLawyer]

That looks like it has fixed it - you're a star.

The latter syntax would indeed make life a lot more pleasant, but I'm happy to call this closed.

[brson]

@AngryLawyer using named functions as values is wonky right now and needs to be rethought. Wrapping them in explicit closures per @bstrie is the best workaround.

[bstrie]

@brson Actually, using named functions in this case wasn't an issue. Changing func() to (*func)() fixes the problem in either case, and when using func() you even get the same error message whether you're using named functions or closures. Is there something else you're referring to that we should be aware of?

[nikomatsakis]

as @bstrie pointed out, this is related to demoding... each gives you a ptr to the thing in the list, hence a ptr to a fn, so you have to manually dereference the pointer to call it.

[brson]

@bstrie no