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.