Consider if cxx_type and return_cxx_type are still required

[ahayzen-kdab]

Do we still need the cxx_type and return_cxx_type ? If they can be removed then signal emits don't need a wrapper. And macro attribute parsing may be simpler. And the templates for converts can be removed.

[ahayzen-kdab]

Workarounds if this was to be removed, eg if you have a UniquePtr / &T in Rust and T in C++

Properties

Create a getter/setter with UniquePtr / &T invokables in Rust, then create a subclass in C++ that defines the Q_PROPERTY, getter/setter/signal with T that wrap the Rust getter/setter

Invokables

Create an invokable using taking/returning the UniquePtr / &T in Rust, then create a subclass in C++ with a second invokable that wraps Rust invokable

Signals

Create the signal using UniquePtr in Rust, then create a subclass in C++ with a second signal that connects the first and does the conversion.

Inherit from base class

Create a C++ subclass of the base that has T, which exposes a method with UniquePtr / &T then Rust / CXX can bind to this.

@LeonMatthesKDAB @Be-ing Now that most Qt types are trivial and we can easily inherit from classes, can we see any other scenarios where our old cxx_type or return_cxx_type would be useful ? Or should we just remove it as it adds complexity to our generator code, the generated code, and it appears that the use cases for it can be worked around simply with a C++ proxy in the right place. And this is probably a small use case anyway ?

[LeonMatthesKDAB]

I'd like to do further testing with CXX-Qt in a real project before making decisions like this.
Hopefully I'll find time for my Markdown-combiner again, then I can report if I ever needed this.

But I suspect this can go to the chopping block.

[ahayzen-kdab]

I'd like to do further testing with CXX-Qt in a real project before making decisions like this. Hopefully I'll find time for my Markdown-combiner again, then I can report if I ever needed this.

But I suspect this can go to the chopping block.

My hope is that these are needed to rarely that the workarounds listed above using a bit of C++ are enough for the few use cases one might have. As this would reduce complexity on our side quite a lot :-)