lambda support for signalling

[huwpascoe]

This syntax especially

struct S {
    int capture;
    void bar(int, char) { /* ... */ }
};
S instance{ x };
signal.sink().connect<S, &S::bar>(&instance);

Would be very useful to support lambda syntax (c++ converts to the very same pattern internally, I think)

signal.sink().connect([x](int, char) { /* ... */ });

[indianakernick]

The signal stuff is made to be fast. It’s designed to avoid allocations. If you want a lambda with state, you have to store the state somewhere. std::function will allocate space for that state but entt::Delegate will not. Supporting this feature would introduce allocations everywhere.

If your lambda is state-less then it can be cast to a function pointer. Unary plus operator can do that.

signal.sink().connect<+[] (int,char) {
  /* ... */
}>();

I’m not sure how you would go about disconnecting that though.

---

Although, we could make the user in charge of the state. Maybe if the user passes in a pointer to an object, we could grab a pointer to operator() automatically.

S instance{x};
signal.sink().connect<S>(&instance);

All we can really do is make the workaround in the original post a little cleaner.

[skypjack]

What @Kerndog73 said is more or less what I'd have said, but for the fact that lambdas cannot be used as template parameters in any case as far as I remember.

The fact is that SigH is all about template and it isn't in charge of the lifetime of the listeners. Supporting lambdas the way you're proposing requires a completely different design and some allocations around, more or less what Emitter offers. On the other side, SigH allocates only to store erased wrappers around a couple of pointers and the idea is to introduce custom allocators in future so as to reduce the performance hit due to allocations and have a finer control on wrappers.

If you want to create a signal class that accepts lambdas, probably SigH isn't what you're looking for, that's all. The idea behind this class is all the ways different from that.

[indianakernick]

Oh, of course lambdas can’t be used as template parameters! Every lambda expression has a different type. It just wouldn’t make sense. Silly me! I should have compiled that.

[skypjack]

I'm closing the issue because it's invalid, something we cannot implement within SigH, I'm sorry.
Feel free to continue the discussion here if you have any proposal or suggestion. Thank you.

[huwpascoe]

Don't worry it's not vital, wondered if it was overlooked. 👍 @Kerndog73 for the +[] operator

[Snektron]

I understand signals aren't in charge of the lifetime of the listener, however i don't think writing

bool thing_happened = false;
auto listener = [&thing_happened]{
  thing_happened = true;
};
sink.connect<&decltype(listener)::operator()>(&listener);

is quite nice. A possible alternative would be to add an overload of connect that automatically deduces operator() of its parameter:

template <typename Listener>
connection connect(Listener* listener) {
  connect<&Listener::operator()>(listener);
}

This would allow rewriting the first snippet as

bool thing_happened = false;
auto listener = [&thing_happened]{
  thing_happened = true;
};
sink.connect(&listener);

which seems a lot nicer in my opinion.

[indianakernick]

@Snektron I was thinking about this just the other day!

[skypjack]

@Snektron @Kerndog73 a lambda created on the stack and attached this way would result in a dangling pointer and therefore a crash.

[Snektron]

Wouldn't the same thing happen with a listener created on the stack?

[skypjack]

@Snektron indeed, of course. @Kerndog73 correctly commented the decisions behind sigh a while ago:

The signal stuff is made to be fast. It’s designed to avoid allocations. If you want a lambda with state, you have to store the state somewhere. std::function will allocate space for that state but entt::Delegate will not. Supporting this feature would introduce allocations everywhere.

The fact is that the delegate class (and therefore sigh, that you can see as a multi-delegate class in a sense), doesn't allocate nor it has space to store aside lambdas or instances of any type. It gets the job done with just a couple of pointers and that's all. On the other side, fully supporting lambdas would require to design something similar to an std::function that does allocate instead in some cases and for obvious reasons. However, if what I need is an std::function, I can use it directly, it doesn't make much sense to design a drop-in replacement with no benefits at all and with the exact same API.