> On 25 Feb 2020, at 20:17, Matthew Woehlke <mwoehlke.fl...@gmail.com> wrote: > > On 21/02/2020 09.02, Ville Voutilainen wrote: >> Getting back to macro vs. function.. I think using a function wrapper >> is fine, considering that signals can't >> meaningfully return, so the prvalue/xvalue issue doesn't arise. > > AFAIK, signals *can't* return, period. The signal body is written by > moc, not the developer, and I'm not aware of any way to generate a > signal method body that involves returning something.
We’re on a tangent here, but signals and slots can have return values, and these are passed correctly through the generated signal emission code. It’s not recommended as it violates some of the principles signals/slots have been designed for, but there are some valid use cases. The way it works is that in case more than one slot is connected to such a signal, the return value of the last slot connected is returned, if nothing is connected a default constructed value is returned. > >> Yeah, I'm sure we'll have no trouble finding people who think >> >> qEmit(mah_bucket_callback()); >> >> is unacceptably ugly compared to >> >> qEmit mah_bucket_callback(); > > Personally, I would vote for: > > template <typename Signal, typename... Args> > QObject::emit(Signal, Args&&...) > > ...which not only avoids an extra set of parentheses, but could actually > *verify* that what you're trying to emit is really a signal. (It has to > be a member function, because it needs `this`.) Sure we could do that, but it (as some of the other proposals) leads to a rather ugly syntax without solving any real problem. Signals/slots are a success because they are easy to use and just a simple function call on the emitting side. Cheers, Lars _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
