A closure literal is not coerced to Closure1 in a struct field initializer

A closure literal is coerced to Closure1<A, B> when it is a call argument, but not when it initializes a struct field.

struct Filter<I, Item> {
  inner : I,
  keep : Closure1<Item, bool>,
}

let f = Filter<Range, i64> { inner : r, keep : | x : i64 | x > 2i64 };

Error: Type mismatch in struct initialization for field 'keep'. Expected Closure1<i64, bool>, got Closure_2

The same literal is accepted as an argument:

fn filter<I, Item>(inner : I, keep : Closure1<Item, bool>) -> Filter<I, Item> {
  return Filter<I, Item> { inner : inner, keep : keep };
}

let f = filter(r, | x : i64 | x > 2i64);   // fine

So the coercion exists; the struct initializer does not reach it. Closure_2 is the anonymous type the literal is given before coercion, which is why the message names it.

core::iter works around this by building each adaptor through a function rather than a struct literal. That is a reasonable API anyway, but the workaround should not be load-bearing -- a user writing the literal directly gets an error naming a type they never wrote.

Start by tracing how closure literals are coerced for call arguments and how struct field initializers type-check; compare that path with the direct Filter literal shown in the issue. Check the core::iter function-based workaround for a relevant example. Done means the direct struct initializer accepts the closure as Closure1<i64, bool> and no longer reports the anonymous Closure_2 type.