UniquePtr's usage and discussions

[ahayzen-kdab]

For opaque C++ types we need to use UniquePtr or references to pass them around on the Rust side of the bridge.

Places where UniquePtr is used

• C++ opaque types in a Q_PROPERTY stored on the Rust struct
• C++ opaque types which are arguments in signals
• C++ opaque types returned from invokables to C++
• C++ opaque types returned from base class methods or other C++ API

Note that parameters in invokables can take a reference to the C++ opaque type so don't need to be a UniquePtr

Problems

• For the three usecases above we need an attribute to tell the generator what type is used on the C++ side
  • Eg #[qproperty(cxx_type = "T")] or #[qinvokable(return_cxx_type = "T")] or #[cxx_type = "T"] on signal arguments
  • This is because Qt/QML expects by value or const ref versions of T for properties, signals, invokables
• To define methods that are on our base class which return an opaque C++ type, we need to wrap them
  • Eg if you have fn base_method(self: &DerivedClass) -> CppOpaqueType this won't work
  • We need instead to add C++ code to create fn base_method(self: &DerivedClass) -> UniquePtr<CppOpaqueType> which would mean the developer needs to write a load of wrapping code for their base class methods
  • Syntax in CXX to state the following could then avoid these wrappers needing to be written
    • Opaque C++ type T coming from C++ to Rust needs to become UniquePtr
    • Opaque C++ type UniquePtr coming from Rust to C++ needs to become T
    • CXX talks about the possibility of this in Sugar Needed? dtolnay/cxx#228 (comment)
  • Of course there is autocxx which has solutions for this and could be used for general Qt API wrapping, but it's not clear how this would work for describing methods on the base class of the QObject described in Rust.

Solutions

• Being able to signify explicit conversion of the type to/from C++/Rust could result in
  • setter types in properties being defined as ValueToUniquePtr so that they convert to UniquePtr in Rust
  • args in signals being defined as UniquePtrToValue so that they convert to T in C++
  • returns from invokables being defined as UniquePtrToValue so that they convert to T in C++
  • returns from base class methods being defined as ValueToUniquePtr so that they convert to UniquePtr in Rust
• Properties getters are a problem because we don't want to consume the UniquePtr from the Rust struct but provide a reference, we need to go from &UniquePtr to &T. as_ref() can be used here
  • how can we tell when the developer wants UniquePtr<QColor> to become a reference
  • when it shouldn't be a reference ? Or should all UniquePtr's in property getters be by reference?
  • can we tell if something has as_ref() ? can we look for if it implements UniquePtr ?
    • Yes use Deref ? So just *self.prop ?

[ahayzen-kdab]

This is now less relevant as we pass around items as trivial as we can as Qt if they are relocatable :-)