Would Rust introduce Qt signal slot mechanism?

Currently, I use C++ with QT a lot. And I quite appreciate the Signal/Slots m echanism. Because it is really convenient to connect different functions of different objects. And there is no data racing through different threads.

I know there no data racing in RUST when doing multi-thread programming. But I think it more convenient to organize the connection over different objects with syntax like "connect(producerFunc,consumerFunc)", especially when there are complex message channels over several objects.

Maybe this idea is superficial, as I just got the idea. But if it does not violate the design of RUST, I hope this could be a new trait. Thanks.

QT signal/slot is not a mechanism of C++, it's just a C++ library which provides such functionality. You can implement it yourself with Rust, or even use it directly with ffi bridge code. But I don't think using it through ffi will be easy as signal/slot is quiet template-heavy use case though.

I haven't used it, but the qt_core crate says it implements signals and slots for Rust:

I'm not sure if I'm missing some fine detail about signals and slots, but I think they can be implemented in bare Rust like this:

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=d72f704724efb426d6369ed2db70a0e3

This does have some syntax noise around Arc/Mutex that could be hidden behind helper funcitons. Qt solution presumably has this either built-in into QtObject, or just doesn't care.

I'm pretty sure the actual implementation of QtObject is logically Arc<UnsafeCell<_>>. They should only be called in GUI thread so ideally it can be Rc but well it's C++.

My understanding is that Qt signals/slots can be used across threads (e.g., search for 'thread' in https://doc.qt.io/qt-5/signalsandslots.html). They are based on QObjects (which includes QWidgets but also many non-GUI classes.) So while it is true that GUI objects must only be used in the GUI thread, that restriction doesn't apply to non-GUI QObjects.

I didn't noticed there's some non-gui qt classes. But as per the docs, signal handling is synchronous so every linked slots are executed in the thread that emitted the signal. And slots are plain method call so we should not assume they're thread safe if not explicitly documented as so.

Rust will not introduce a runtime or runtime components but this would be an excellent library crate.

The situation is more subtle than that. Slots are normally called synchronously, but if different threads are involved they are called asynchronously. See ConnectionType.

1 Like

Note that C# also offers this feature under the name of delegates

As far as I know, If two objects belong to 2 different thread, then even the parameter is parsed as reference type, QT would COPY it to make thread safe.

Indeed, it is offered by QT library but not C++. And Personally, if QT is endorsed by a company like Microsoft, I do think the signal/slots mechanism would become one of C++ standard.

And for why I hope Rust could introduce it, one reason is that I think it would be complex, unsafe and usually inefficient to create such a crate at user level, with Rust traits (ownership and lifttime). If it is introduced more officially (even it is just a sub-crate of rust standard lib), it would be more acceptable.

In this case I don't see how libstd could make it faster or less unsafe. If there are some language features that libstd could use to do so, Rust would rather add these language features for all crates to use.