It's been almost a year and I don't know if any discussion has happened in the discord but I could imagine signals continuing to look like this:

#[derive(GodotClass)]
#[class(init)]
pub struct MyRefCounted {
    base: Base<RefCounted>,
}

#[godot_api]
impl MyRefCounted {
    #[signal]
    fn foo_signal();

    #[signal]
    fn bar_signal(parameter: Gd<Node>) -> String;
}

So from a magic macro DSL standpoint, nothing has changed.
However, behind the scenes, the following code would be generated:

#[godot_api]
impl MyRefCounted {
    // ZST definitions for FooSignal and BarSignal generated by macro

    fn foo_signal() -> FooSignal {
        // ...
    }

    fn bar_signal() -> BarSignal {
        // ...
    }
}

The generated types would expose an API as you suggest for the member-based solution:

struct FooSignal;

// or trait impl style macro magic, same difference
impl FooSignal {
    pub fn connect(/* signature is implementation detail, can't remember precise callable logic impl */) { } 
    
    pub fn emit(source: &mut MyRefCounted) {}
}

So that'd allow you to interact with signals as follows:

#[godot_api]
impl MyRefCounted {
    #[signal]
    fn foo_signal();

    #[func]
    fn callback() {
        // do things here
    }
}

#[godot_api]
impl INode for MyRefCounted {
    fn on_ready(&mut self) {
        self.foo_signal().emit(self);

        self.foo_signal().connect(Callable::from_object_method(correct_value, "callback"));
    }
}

I think this better models the relationship between signals and Godot classes. The way they work is so detached from the struct definition of a godot class in Rust that I'd push for them to continue using the function representation.

That said, this is firmly in the territory of macro magic. We're rewriting a function signature entirely differently than how it exists in the source code, and adding magic syntax to signals. I'd definitely argue that this is justified (although that's a given because I am currently suggesting it).

And as you said, you would like to see things be able to be implemented in both builder patterns and macro magic.
This system could also be visualized as a half-built builder. If you were to imagine the generated builder to be a specialized kind of SignalBuilder that abstracts over emit and connect operations given a signal's name and signature.

This could be imagined as follows, but it may not fall in line with your vision for a builder API in the future:

#[signal]
fn bar_signal(parameter: Gd<Node>) -> String;

pub fn bar_signal() -> SignalBuilder<Fn(Gd<Node>) -> String> {
    // Instead of a specialized type, we instead provided a pre-initialized builder
    // that you could have just used without the macro magic
    SignalBuilder::new("bar_signal")
}

So we'd be able to just re-use the procedural builder and unify the usage of the pattern with this solution, but the #[signal] macro would 100% be "macro magic" and its not a decision to make lightly.

Uh oh!

Signals #8

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions