-
Notifications
You must be signed in to change notification settings - Fork 337
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Distinguish static member function on shared structs #447
Comments
A Rust signature should be emitted as a non-static member function if and only if it has a Maybe like this? : #[cxx::bridge]
mod ffi {
struct A {
a: f32,
}
extern "Rust" {
#[Self = "A"]
fn foo() -> A;
fn bar(self: &A) -> A;
}
} |
I'm also thinking about this: #[cxx::bridge]
mod ffi {
struct A {
a: f32,
}
extern "Rust" {
#[struct = "A"]
fn foo() -> A;
#[struct = "A"]
fn bar(&self) -> A;
}
}
This will break existing code though. |
I suggest using another approach - using nested modules to declare static member functions: struct SimpleClass {
static void simpleMethod();
} #[cxx::bridge]
mod ffi {
pub mod SimpleClass {
extern "C++" {
fn simpleMethod();
}
}
}
fn main() {
SimpleClass::simpleMethod();
} I think, it was really what we want for static member functions |
I am on board with that! |
My first instinct was to try:
but this fails with
Is there some semantic distinction between a static method and a plain function that we need to maintain? If it's just a matter of names then it seems like |
@dtolnay I'm interested in contributing support for static member functions. There's a few different design possibilities that have been discussed, summarized below. I'd like to agree on one with you and then I'll work on putting together a pull request. 1. Designate static member functions with a new attributeThis was the first option you mentioned above.
I think we'd want to support this attribute applied to the extern block too, similar to We can bikeshed the name of the attribute - 2. Group static member functions in a nested moduleThis option was proposed by @mikhailzagurskiy above.
It's not clear to me whether they intended this syntax to only support classes that only contain static member functions - which seems too limited to be useful - or not. As it is, this syntax feels weird to me because it looks like you'd have an identifier conflict between the type and module. 3. Group static member functions in an impl blockA spin on Option 2 would be to use an
|
Upcasting can change the value of a pointer in C++. This means anything upcasting needs both the parent and child class defined, which is awkward in user code when wrapping functions that accept ownership of a superclass object (it requires C++ code that depends on autocxx-generated C++ code that depends on the main C++ code, which then needs to be depended on by another iteration of autocxx to call it from Rust). Ideally this would be a static function in C++ to avoid some potential name conflicts that this approach produces (with C++ types sharing a name in separate namespaces), but I don't think cxx supports those yet (dtolnay/cxx#1036 and dtolnay/cxx#447).
Are there any workarounds for this at the moment? I can't figure out how to expose a constructor from Rust to C++ without wrapping it with a non-associated function. |
Regard #437, what's your opinion on how to distinguish static member function from non-static ones?
For example:
In the generated header file,
foo
should be a static function whilebar
should be non-static.The text was updated successfully, but these errors were encountered: