Type coercion from function item types to function pointers

[mattheww]

The "Type coercions" section says coercion is allowed from:

• Function item types to fn pointers
• Non capturing closures to fn pointers

This ought to describe the compatibility requirements, including:

• the signatures must be compatible (which needs defining)
• the ABI must be the same
• the safety must be the same

See rust-lang/fls#460 and rust-lang/fls#472

[workingjubilee]

This ought to describe the compatibility requirements, including:
the signatures must be compatible (which needs defining)
the ABI must be the same
the safety must be the same

We seem to, on stable, allow some coercions that suggest this is incorrect, allowing safe-to-unsafe coercions:

https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=24fee23b7435081e9394387265ddea4d

[workingjubilee]

This has been an intentional behavior since 1.14ish

• fn should coerce to unsafe fn rfcs#1762
• rustc_typeck: Allow reification from fn item to unsafe ptr rust#37389
• Direct coercion from closures to unsafe fn pointers rust#57883
• Allow closure to unsafe fn coercion rust#59580

[mattheww]

The discussion in rust-lang/rfcs#1762 treats safe-item-to-unsafe-pointer as an instance of the transitive case, with the second leg being a coercion from fn pointer to unsafe fn pointer.

That second coercion does exist, but it isn't documented in the Reference.

Once that's documented, the Reference could document the compatibility requirement here as "the safety must be the same" as suggested above, but I agree it would be clearer to say that only unsafe-item-to-safe-pointer is forbidden.

[mattheww]

Note that safe-item-to-unsafe-pointer doesn't work in least-upper-bound coercion.

This compiles:

fn safe_fn1() {}
fn safe_fn2() {}

fn main() {
    let f: fn() = if true {safe_fn1} else {safe_fn2};
}

But this doesn't (in Rust 1.87):

unsafe fn unsafe_fn() {}
fn safe_fn() {}

fn main() {
    let f = if true {safe_fn} else {unsafe_fn};
}

The Reference's least-upper-bound coercion docs offer only the following way to get a type which isn't one of the inputs:

try to compute a mutual supertype of T_t and Ti, which will become the new target type.

That's too weak: it doesn't allow the first example.

Compare the FLS (§4.12.3:53, fls_92pwnd1xbp5r), which makes a stronger claim:

if TC and U are […] function item types […], and a function pointer type exists that both TC and U can coerce to, make that function pointer type be target type U.

That's too strong: it allows the second example, given that a safe function item can coerce to an unsafe function pointer.

(rust-lang/fls#472 documented the rules for function-item-to-function-pointer coercion in terms of a subtype relation for function signatures, but as far as I can tell it doesn't define that relation anywhere.)

[mattheww]

A variant of the second example with the target type explicitly specified is accepted:

unsafe fn unsafe_fn() {}
fn safe_fn() {}

fn main() {
    let f: unsafe fn() = if true {safe_fn} else {unsafe_fn};
}

But neither the Reference nor the FLS say that such an explicit type affects least-upper-bound coercion.