Closure inference is based on expected type

[brson]

UPDATE: I updated the title to reflect the root problem. "Closure inference" refers to detailing the specifics of a closure type, such as its bounds and so forth. Ideally, only the argument types would derive from the expected type (with a fallback to fresh type variables).

original issue report follows:

type t = {
    f: fn~()
};

fn main() {
    let _t: t = { f: {||()} };
}

../src/test/run-pass/test.rs:6:16: 6:29 error: mismatched types: expected `t` but found `{f: fn@()}` (in field `f`, closure protocol mismatch (fn~ vs fn@))
../src/test/run-pass/test.rs:6     let _t: t = { f: {||()} };

[nikomatsakis]

There are two separate problems here. The first is that we do not push the expected type through records into their fields. The second is that our inference of the closure type is based purely on the expected type rather than generating some sort of variable that can later be unified. I think we should fix both (but probably the first one first).

[brson]

FWIW this actually demonstrates a second problem with closure inference - the nil in {||()} should be inferred.

[bblum]

Don't think this has to do with records. The closure here infers as a fn@ if the ret is removed, but works with the ret present.

const generations: uint = 1024+256+128+49;

fn child_no(x: uint) -> fn~() {
    ret || {
        if x < generations {
            task::spawn(child_no(x+1));
        }
    }
}

fn main() {
    task::spawn(child_no(0));
}

[nikomatsakis]

Actually the original bug may have been fixed since marijn did some work towards pushing expected types through records. I think the problem bblum points out is a separate but related issue.

[nikomatsakis]

Indeed, what bblum points out (as brson pointed out earlier but I didn't understand it) is a problem that the "expected type" does not appear to be propagated to the expr in tail position in a record.

[nikomatsakis]

sorry, tail position in a block

[bblum]

This seems more extensive than just records - I'm running into trouble inferring closures inside of options.

This works:

fn foo(f: fn&()) { f() }
fn bar() {}
fn main() { foo(||bar()); }

Now I try to put the closure in an option. It works if I just use the name bar:

fn foo(f: option<fn&()>) { f.iter(|x|x()) }
fn bar() {}
fn main() { foo(some(bar)); }

But if I use the bars syntax, it infers that as a fn@, and dies:

fn foo(f: option<fn&()>) { f.iter(|x|x()) }
fn bar() {}
fn main() { foo(some(||bar())); }

[nikomatsakis]

Give people an inch and they want a mile. :) Closure inference is broken in many ways, because it's a quick hack based on the expected type. I hope to replace with something more principled along the lines of what we do for integer literal inference though.

[bblum]

(that commit has a case of the code in my above commit; tagged with a fixme. should be easy to get rid of the fixme after this bug.)

[catamorphism]

Reproduced as of 3edccc3

[pcwalton]

I don't believe this is backwards incompatible, renominating.

[graydon]

blocked on resolution of #6308

[graydon]

sub-bug of #6834

[graydon]

just a bug, removing milestone/nomination.

[nikomatsakis]

Related to #6834

[catamorphism]

Visiting for triage. Sub-bug of #6834, therefore doesn't need to be on a milestone itself.

[thestinger]

Closure inference is gone, because there are only borrowed stack closures now.

[nikomatsakis]

Not so. There are still things we might need to infer, such as closure bounds and so on.

[nikomatsakis]

I updated the title to reflect the root problem.

[steveklabnik]

@nikomatsakis is this issue still relevant with all of the changes to closures?

[nikomatsakis]

Not really. The current state roughly corresponds with what I described as the "ideal" scenario above, though I'd not call it ideal ideal. ;)

[steveklabnik]

😄