Strange mapping of struct functions

[mipastgt]

I tried to use a struct from Java/Kotlin code and the mapping of methods seems a bit strange to me. The following test compiles and runs but I would have rather expected static functions here to avoid this dummy instance. It would also be tempting to map structs to real classes with constructors and instance methods but I am not sure whether that would actually be fully compatible with Rust. So, static methods seem to be the safer bet to me at the moment.

    @Test
    fun test_impl() {
        val dummy = NamedCounter()
        val counter = dummy.new("Michael", 99)
        val limit = dummy.get_limit(counter)
        assert(limit == 99L)

// Shouldn't this rather be mapped to static functions like this?
//        val counter = NamedCounter.new("Michael", 99)
//        val limit = NamedCounter.get_limit(counter)
//        assert(limit == 99L)
    }

[IntegralPilot]

Thanks for trying this and noticing the problem. I can try and make something like the below work:

// generates a default constructor with the same order as fields are defined in rust
// but if you use the constructor, you need to specify every field
// also still provides a constructor that takes no arguments
val counter = NamedCounter("Michael", 0, 99, true); 

// methods that do not take a &mut self or self reference in rust are static
val counter2 = NamedCounter.new("Michael", 99);

// methods that DO take a &mut self or self reference in rust are instance methods
val limit = counter2.get_limit();

Would this be the most idiomatic solution in Java/Kotlin, or do you think something else would suit JVM idioms better?

[mipastgt]

Yes, that would be great, but I am just not sure about the no-args constructor and whether this mapping in general is consistent with all possible scenarios in Rust. The no-args constructor means that you can create a class instance without defined values. My gut feeling tells me this is something that should not happen in Rust.

[IntegralPilot]

Yes you are right, it's not something that should happen in Rust. The no-args constructor is part of technical debt, where, before I added the ability to pass arguments, classes (well, Rust enums/structs/tuples) were instanisated by calling the no-args constructor and then immediately setting fields, and this pattern has persisted to this day. So immediately setting the fields afterwards is part of the implied contract with using the no-args constructor, which the Java side is under no obligation to uphold, which can cause some weird behaviour if the Java side doesn't uphold this. But, I couldn't remove the constructor, because this would leave the generated Rust code not working.

I've decided now I'm going to re-write the entire technical debt laden class instanisation and method calling code as part of this update for more idiomatic Java/Kotlin-side method calling. I'll remove no-args constructors (except for types that genuinely have no fields) as part of it because after the re-write they won't have a purpose anymore. Because it's a re-write, this is probably going to take a few days sorry, but I think it's the best way to do it properly, as the debt in this area has also been causing me some trouble when implementing other features so I think it's best to make it clean and idiomatic.

[mipastgt]

It's probably the right thing to do to fix such dept early in the process. Take your time and let me know when there is something new to test.

[mipastgt]

It has become quite quiet here. Any news to share?
Merry Christmas

[IntegralPilot]

Hi! I'm so sorry, I got really busy with other projects and commitments. A (belated) Merry Christmas to you too! I'm working on this again now, just getting back into it. For the new format, most tests are passing, just a couple edge cases I need to debug further. Now, rust nightly has changed the internal API a bit though since I last worked on this, so I'm updating it to compensate for that now.

[IntegralPilot]

@mipastgt - Finally finished! Sorry for the really long wait, I got busy with school and some other stuff as well. Just pushed the big refactor (split into 2 commits) now, I think it addresses all issues here (as well as lots of other technical debt and stuff I wanted to clean up).

You can see an example of the more idiomatic struct function Rust-Java integration (which is part of the test suite and verified) here: https://github.com/IntegralPilot/rustc_codegen_jvm/blob/main/tests/integration/struct_methods/Main.java

Would appreciate your thoughts and if you think anything about this can be further improved.