fn's can no longer be implicitly converted to closures

[Dretch]

The code used to work, but now it doesn't compile:

fn double(x: int) -> int {
    x * 2
}

fn main() {
    let v = (~[1, 2, 3]).map(double);
}

Rustc says:

test-extern-fn.rs:9:29: 9:35 error: mismatched types: expected `&fn(+:&<VI2>) -> <V8>` but found `extern fn(int) -> int` (expected &-ptr but found int)
test-extern-fn.rs:9     let v = (~[1, 2, 3]).map(double);
                                                 ^~~~~~
test-extern-fn.rs:9:8: 9:36 error: cannot determine a type for this local variable: unconstrained type
test-extern-fn.rs:9     let v = (~[1, 2, 3]).map(double);
                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
error: aborting due to 2 previous errors

This may be intentional but also might be a bug.

[brson]

This is bugging me too.
On Jan 19, 2013 12:44 PM, "Dretch" notifications@github.com wrote:

The code used to work, but now it doesn't compile:

fn double(x: int) -> int {
x * 2
}

fn main() {
let v = (~[1, 2, 3]).map(double);
}

Rustc says:

test-extern-fn.rs:9:29: 9:35 error: mismatched types: expected &fn(+:&<VI2>) -> <V8> but found extern fn(int) -> int (expected &-ptr but found int)test-extern-fn.rs:9 let v = ([1, 2, 3]).map(double);
^~~~~~
test-extern-fn.rs:9:8: 9:36 error: cannot determine a type for this local variable: unconstrained typetest-extern-fn.rs:9 let v = ([1, 2, 3]).map(double);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
error: aborting due to 2 previous errors

This may be intentional but also might be a bug.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4544.

[nikomatsakis]

I think your problem here is that the type of double is wrong. Map passes in pointers to the data in the vector.

For example, the following program compiles fine:

fn double(x: &int) -> int {
    *x * 2
}

fn main() {
    let v = (~[1, 2, 3]).map(double);
}

That said, as part of fn reform, I modified fn items so that their type is extern fn() and this is no longer a subtype of the closure type &fn(). This is because the extern fn() value will eventually be JUST a function pointer, and not a pair of a function and an environment. The compiler will automatically convert from one to the other when it does assignability checks, which means on function parameters, struct fields (but not records), and let x: T = ... locations. This could be made to work differently if it's proving to be a big pain in practice, though I found it worked very well in our current codebase and was a relatively straightforward approach.

[nikomatsakis]

I should add: I am closing because this test case works. If there are others you think should work but do not, please open a separate bug and we can discuss.

[Dretch]

Ah, indeed the test case I posted did not demonstrate the issue - which is, as you stated, that extern fn is no longer a subtype of &fn().

I think this is less convenient than the way it worked before, but I guess no more so than the implicit string pointer conversions.

In one of my actual use-cases I was bitten because I was passing a vector of extern fn() to a function expecting a vector of fn().

[nikomatsakis]

I see. Yes, this would no longer work. An easy workaround would be to introduce a struct type. Alternatively, the original design called for more comprehensive inference.