Cannot coerce closures to `fn(...) -> ...` in a slice if the slice contains only one function

[symphorien]

fn useful(i: usize) -> usize {
    i
}

fn useful2(i: usize) -> usize {
    i
}

fn main() {
    for f in &[useful, useful2, |x| x] {
        println!("{}", f(6));
    }
}

compiles and runs fine. (see https://play.rust-lang.org/?gist=de9e7ce8fd0683e1dbdcf362a2e16dd4&version=stable)
but if I remove useful2 from the slice, type inference fails:

error[E0308]: mismatched types
  --> src/main.rs:10:24
   |
10 |     for f in &[useful, |x| x] {
   |                        ^^^^^ expected fn item, found closure
   |
   = note: expected type `fn(usize) -> usize {useful}`
              found type `[closure@src/main.rs:10:24: 10:29]`

(see https://play.rust-lang.org/?gist=428522c1c8e14eefaa690d5d09e67b82&version=stable )

If I insert useful twice (ie &[useful, useful, |x| x]) I still get this error.

[Manishearth]

This also depends on the order of items within the array. You must start with two different functions for it to work.

IIRC the fn item to fn pointer coercion is a bit more "loose" than other coercions (it triggers a bit more often), causing this. I wasn't aware closures also coerce.

[vitalyd]

You don’t have to start with two different functions, but you must have (at least) 2 different ones before the closure is seen. That is, you can have &[useful, useful, useful2, <closure>] - that works.

[eddyb]

This is because two functions will coerce to a function pointer, but a function and a closure won't.
Not just arrays, but if-else and match are also affected.

The only reason it works for functions, without a coercion target being inferred from anywhere, is for backwards-compatibility, since some items were incorrectly typed as fn pointers in 1.0.

cc @rust-lang/lang We could allow [|x| x, |y| y + 1] to have the type [fn(i32) -> i32] (just like [fn_1, fn_2] coerces both function types to fn pointers), do we want to?
If we do it then it would also work when mixing functions and closures - or do we only want that?

[nikomatsakis]

@eddyb a good question. It feels like it would be useful, but might be quite confusing though, and perhaps problematic in the future if we ever get some form of union type thing going on, no?

[eddyb]

@nikomatsakis Well, right now, the lack of it breaks the associativity of the "LUB coercion": LubCoerce(A, B) = C must mean either: CoerceTo(A, B) (C = B), CoerceTo(B, A) (C = A), or some special-cased C, for which CoerceTo(A, C) && CoerceTo(B, C).

We originally special-cased fn pointers to be LUB-coerced from two function types, and that means that if the final type is going to be a fn pointer type, any order of functions and fn pointer values will coerce into a single fn pointer type (assuming they all have the same signature).

Introducing more coercions (i.e. from closures) to a given special-cased C (i.e. fn pointers), without considering those types (closures) in the special-case makes LubCoerce non-associative, e.g. LubCoerce(LubCoerce(fun1, fun2), closure) works because it's effectively CoerceTo(closure, LubCoerce(fun1, fun2) = fn(...)), but LubCoerce(function, closure) doesn't.

And non-associative LUB-coerce is observable as order dependence of arrays, if-else/match arms, etc.

In other words, for an order-independent LUB-coerce, the special-cases aside from CoerceTo, should not be about coercion source types or "kinds of coercions", but about "guessing" coercion output types, and if we can guess a type O such that CoerceTo(A, O) works, we must be able to guess O for any B where CoerceTo(B, O) works.

[steveklabnik]

Triage: no changes