nikomatsakis
Thread-safety
Generally GObject is thread-safe, but many subclasses are not (notably all of GTK is not, and especially can only be used from the main thread).
Having support for generating thread-safe GObject subclasses, as long as the parent classes allow for that (how to detect that? probably a new marker trait for this: we can't mark GObject as Send+Sync because otherwise all subclasses would be).
This would involve using mutexes or otherwise Send+Sync wrappers around the instance data.
You can never safely have a thread-safe GObject, or any non-final subclass thereof. Even if you create a class that is thread-safe, as long as someone can subclass, you never know if all children are.
As such there is no point in when to allow to create a thread-safe subclass or not, because safe Rust code will never be able to use it as thread-safe.
This is not just a Rust issue, this is an OO issue in general.
Sure, you have to enforce that all subclasses are thread-safe as well from the point where a class appears that is marked as thread-safe. I don't see the problem here
Hmm, I didn't actually think of a scenario where GObject is not considered thread safe, but that would indeed work.