Somewhat off-topic, but why are extern functions written as

    extern "ABI" fn(T) -> U

Rather than using an attribute?

    #[abi = "ABI"]
    extern fn(T) -> U

It seems like a very bizarre special case.


On Wed, Mar 13, 2013 at 6:33 AM, Niko Matsakis <[email protected]> wrote:

> A quick opinion poll:
>
> As some of you may know, I am working on enabling pointers to functions
> (as opposed to closures, which we offer now).  Such pointers will be
> written `extern "ABI" fn(T) -> U`, where `ABI` is, well, the ABI that is
> expected.  This naming reflects the primary use for function pointers,
> which is to interface with C libraries and the like.  Extern fn pointers
> *can* also be used to point to Rust functions.
>
> To that end, I was wondering what the ABI names ought to be and whether to
> make the ABI mandatory or supply a default.
>
> Here are some options on the ABI names.  Note that these names would also
> appear in extern blocks (i.e., `pub extern "cdecl" { ... }`):
>
> Option 1. Names "C", "Rust", "StdCall", etc.
> Option 2. Names "C", "rust", "stdcall", etc.
> Option 3. Names "cdecl", "rust", "stdcall", etc.
>
> And here are the options on the default:
>
> Option A. Mandatory ABI.
> Option B. Default to "rust" (however it winds up being spelled)
> Option C. Default to "cdecl" (however it winds up being spelled)
>
> I am personally leaning towards options (3) and (C).  The ABI names in (3)
> seem most standard, and I imagine cdecl function pointers are the most
> common.  My only hesitation is that in C++ you mark C functions as `extern
> "C" { ... }` not `extern "cdecl" {...}`, but as strcat pointed out, this
> has to do more with name mangling than calling convention.
>
>
> Niko
> ______________________________**_________________
> Rust-dev mailing list
> [email protected]
> https://mail.mozilla.org/**listinfo/rust-dev<https://mail.mozilla.org/listinfo/rust-dev>
>
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev

Reply via email to