-
Notifications
You must be signed in to change notification settings - Fork 7
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
Default method names #35
Comments
This seems fine to me. For me new and delete tend to imply allocation but I think that's fine. We can say, new is where allocation may or may not happen (depending on opaqueptr), and same with delete. |
Hmm well I guess allocation will never happen if we always use opaquebytes for anything that has a public constructor. I'm liking this less now that I think about it. what about |
OK so how about Foo() // -> Foo_ctor
Foo(const Foo&) // -> Foo_ctor_copy
~Foo() //-> Foo_dtor
Foo& operator=(const Foo&) // -> Foo_assign
Foo& operator++() // -> Foo_op_inc
Foor& operator--() // -> Foo_op_dec |
And of course Foo& operator[](int i) // -> Foo_index
const Foo& operator[](int i) const // -> Foo_index_const |
Fine by me. |
I think this is done now too. |
Reopening this discussion. We should provide default name transformations for cons/destructors, operators and polymorpic functions so that the generated code will at least compile, even if the names are ugly, and then someone writing a binding can go back and fix it afterwards.
Overloads
This is easy, just enumerate the overloads as they're found:
Constructors & destructors
I think
new
anddelete
are probably the most sensible, orconstruct
anddestruct
. In the previous discussion,new
anddelete
felt overloaded because I was anticipating using opaqueptr for everything and mallocing in the API layer, but I feel like we're now leaning towards opaquebytes for most things and leave opaqueptr for things that can't be constructed by the user, in which case the library will be providing the creation methods manually so there's less worry about confusion.Operators
We should just take the function names from the equivalent Rust traits here since they're logical, concise and consistent.
The text was updated successfully, but these errors were encountered: