> On 26 Feb 2020, at 13:30, Lars Knoll <lars.kn...@qt.io> wrote: > > > >> On 26 Feb 2020, at 10:38, Alex Blasche <alexander.blas...@qt.io> wrote: >> >> >> >>> -----Original Message----- >>> From: Lars Knoll <lars.kn...@qt.io> >>>>> I’m not trying to make this only about emit. But it’s the concrete >>>>> problem we’re facing now, and emit is IMO the one keyword where we >>>>> simply don’t need a replacement because it has no real semantic meaning in >>> C++. >>>> >>>> I don't think semantics matter here. It is all about annotation and >>>> readability. >>> With the same arguments we design APIs. While Kai's survey is inconclusive >>> about the actual solution, it is conclusive in one aspect. There is a clear >>> majority >>> to have sth in place for annotation/readability purposes. >>> >>> As Kai said, in this case a comment would do the trick just as well, no >>> need for a >>> keyword or macro: >>> >>> /*emit*/ mySignal(); or >>> mySignal(); // emit >> >> Can you see us adopting a coding style that enforces the use of such >> comments? Otherwise this will quickly change to comments being forgotten >> which makes the above suggestion less valuable. Although the alternatives >> have no semantics either they impress a stronger coding style than comments >> IMO. > > We’re neither enforcing the use of ‘emit’ currently. And I honestly find most > of the alternatives to be worse than no annotation at all.
I agree. As others have argued, a signal is not special, in the sense that any function can do anything, including emitting signals, so annotating it doesn’t seem critical, as we apparently are fine without in all other cases. We don’t need one rule to rule them all either. Many signals are named fooChanged(), and can perfectly well stand on their own, without annotations. Corner cases like "emit pressed();” can be annotated with Q_EMIT or a comment to make it clearer what’s going on. Tor Arne _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
