extern fn type declarations and extern fn bindings should both default to the same ABI.

[brson]

This has confused me several times:

fn main() {
    extern {
        // extern "C"
        fn foo();
    }

    // extern "Rust"
    let f: extern fn() = foo; // error
}

[brson]

Nominating back compat.

[catamorphism]

accepted backwards-compatible

[nikomatsakis]

Relates to #2202.

[huonw]

extern fn foo() {
    // do Rust things
}

seems to have the C ABI by default too.

[brson]

Is there still even an extern "Rust" type? What is the default for locals now?

[nikomatsakis]

Yes, I believe fn(T) -> U is shorthand for extern "Rust" fn(T) -> U. It occurs to me that extern fn(T) -> U could (reasonably) be shorthand for extern "C" fn(T) -> U.

[nrc]

looking at this

[nrc]

The question is, if they should both default to the same ABI - which ABI? C or Rust?

[nrc]

Niko explained via irc that his comment implies that all uses of (unadorned) extern should mean extern "C"

[brendanzab]

As I commented on #12328, why is this? Wouldn't it make more sense to have extern fn mean extern "Rust" fn? This is looking to the future here. We are our own language.

[huonw]

@bjz fn is the short name for a Rust function; shouldn't extern fn be the most common type used for FFI/extern-stuff (i.e. C ABI)?

[brendanzab]

Doesn't extern "Rust" fn in function parameters mean that the function has to be free-standing?

[brendanzab]

I just don't see that promoting "C" as all-powerful makes sense. Maybe I'm being idealistic here.

[huonw]

fn() now works for that, and with that change, extern can be regarded as just an FFI thing.

[brendanzab]

Can't we just say that all externs must be followed by an ABI? Declaring extern fns is very rare outside of extern blocks, so I doubt the added verbosity would be an issue.

[brendanzab]

I think this is definitely a thing that links into our 'design philosophy'. Do we privilege C as the default for all ffi stuff? If so, we need to be consistent everywhere.

[brendanzab]

Another option would be to remove extern "ABI" fn, and instead have fn "ABI".

[nrc]

@bjz Rust tries to have identifiers always follow keywords. That makes things much easier to parse both by tools and humans, so I would be against fn "ABI" name.

We could always require an ABI for consistency, but given the target for Rust is systems programming I expect C to be the target lang for ffi in a large majority of cases. Therefore, I see nothing wrong with privileging it. It doesn't make calling any other language any harder.

[huonw]

@bjz, there's some empirical evidence that C is the default:

$ git grep 'extern *\("C"\)\? *{' | wc -l # extern { ... }, or extern "C" { ... }
221
$ git grep 'extern *".*" *{' | grep -v "C" | wc -l # extern "non-C abi" { ... }
34

(running in the rust root dir.)

[nikomatsakis]

On Sun, Feb 23, 2014 at 05:22:08PM -0800, Brendan Zabarauskas wrote:

As I commented on #12328, why is this? Wouldn't it make more sense to have extern fn mean extern "Rust" fn? This is looking to the future here. We are our own language.

extern "Rust" fn(S) -> T already has a short version: fn(S) -> T.

As for why one ought to use "C" by default, I think C does occupy a
privileged position, both in general and with respect to Rust. It's
the "lingua franca" for FFIs, and Rust has been specifically designed
to make C interop easy. Other ABIs (stdcall, etc) are simply far less
common, and I don't anticipate we'll ever be able to call into other
languages directly unless they offer some sort of C-compatible
public-facing interface.