-
Notifications
You must be signed in to change notification settings - Fork 20
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
Add support for equality operators via new 'requires' keyword for interfaces #169
base: main
Are you sure you want to change the base?
Add support for equality operators via new 'requires' keyword for interfaces #169
Conversation
…embers of a class-in-a-class Operators.
…uals() & hashCode()
…lock; should fix unit test failure.
December 2024 CI runners don't have sbt anymore Therefore, install it via actions, fix cross-language-cpp#171
…embers of a class-in-a-class Operators.
…uals() & hashCode()
…lock; should fix unit test failure.
…jinni-generator into AndrewAtAvenza/requires
you should be able to fix the formatCheck CI by running if that stopped working, please let me know |
Much obliged! I took a look at that on Monday but thought I had to install it and could figure out how to do that. Glad it's just there, that's really handy. Sorry it's been quiet the last couple of days. I'm landing some big branches and blocking a release. Should be back to this tomorrow or Friday. I took a quick look at how it might look publishing Java to C++ and I've got some thoughts I'll post to the discussion thread later. |
No worries, take your time. This an OS project, so contributing shall also make fun. No stress |
This is the proof-of-concept for adding the new
interface
keywordrequires()
. While this keyword will currently accept botheq
andord
, it only generates code foreq
. Also, it currently only works for Java -> C++ (not even the reverse).Currently,
eq
means defining both 'equals()and
hashCode()in Java and directing them to
operator==(const & other) constand
int32_t hashCode() const` respectively. The former should be fine, but the latter could clash with a user-defined method name. Maybe this is an acceptable trade-off though?