Delegation makes it possible to define C-variadic associated functions

[fmease]

While the following code gets rejected:

#![feature(c_variadic)]

struct S;

impl S {
    unsafe extern "C" fn f(...) {}
    //~^ ERROR only foreign, `unsafe extern "C"`, or `unsafe extern "C-unwind"` functions may have a C-variadic arg
}

The code below doesn't:

#![feature(c_variadic, fn_delegation)]

struct S;

unsafe extern "C" fn f(...) {}

impl S {
    reuse f;
}

And yes, S::f does "appear to behave variadic". I'm not a C-FFI or ABI expert, so I guess it's for a very good reason that variadic associated functions generally get rejected.

[workingjubilee]

I don't actually know any specific reason in principle to reject a function being defined like this:

#![feature(c_variadic)]

struct S;

impl S {
    unsafe extern "C" fn f(...) {}
    //~^ ERROR only foreign, `unsafe extern "C"`, or `unsafe extern "C-unwind"` functions may have a C-variadic arg
}

aside from "it'd be a pain to call from C due to mangling". But we allow people to do things that are wildly incorrect with variadic args and impossible to correctly handle on the other side of C FFI... unless the other side is also Rust.

We absolutely should not allow this though:

#![feature(c_variadic)]

struct S;

impl S {
    unsafe extern "C" fn f(&self, ...) {}
    //~^ ERROR only foreign, `unsafe extern "C"`, or `unsafe extern "C-unwind"` functions may have a C-variadic arg
}