Feature: rename signals to Camel Case

[ratijas]

Summary

Feature request to add support for renaming signals, say from lowercase_underscore in Rust to camelCase in Qt meta system.

Description

Currently, after renaming one of my signals to underscored in Rust:

#[derive(QObject)]
#[allow(non_snake_case)]
struct MyDriver {
    base: qt_base_class!(trait QObject),

    address: qt_property!(QString; NOTIFY address_changed READ get_address WRITE set_address),
    address_changed: qt_signal!(),

I saw this code generated by qmlplugindump in plugins.qmltypes:

Module {
    Component {
        name: "MyDriver"

        Property { name: "address"; type: "string" }
        Signal { name: "address_changed" }

It's not playing very nice with QML. First, both handlers are available: onAddress_changed and onAddressChanged, and each of them gets called on actual change. Second, signal address_changed is explicitly exposed, and can be auto-completed and called by third-party.

Note that normal properties with compliant READ WRITE NOTIFY names are exposed as a simple Property { name: "something"; type: "string" }. This can be verified with the following code:

#[derive(QObject)]
#[allow(non_snake_case)]
struct Test {
    base: qt_base_class!(trait QObject),

    something: qt_property!(QString; NOTIFY somethingChanged READ something WRITE setSomething),
    somethingChanged: qt_signal!(),
}

Rationale

Pros

• Keep code styles consistent with their respective ecosystems
• Get rid of explicit extra signal exposed via meta property system

Cons

• Harder to grep code
• Not in the Qt
• Might be confusing to declare, but really depends on implementation

Implementation ideas

Automatic way

Parse signal name to detect when it is named in lower_case, then keep it lower_case in Rust but rename to camelCase in meta data. This is a very bad idea because of its implicitness. It might rename too much, or not enough (e.g. what if multiple_words_inTheMiddle must be named as such for whatever reason?)

Manual way

There's already ALIAS support in qt_property! pseudo-macro. Similarly, we could have it qt_signal!() counterpart too.

The question is, which one signal name should be used in qt_property!: original or aliased? In practice, however, there's not much difference. We know all members at the time of parsing, so we could even allow specifying both (I mean, any one of them).