> On 26 Feb 2020, at 09:16, Alex Blasche <alexander.blas...@qt.io> wrote: > > > >> -----Original Message----- >> From: Development <development-boun...@qt-project.org> On Behalf Of Lars >> Knoll > > >> 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 Both of those are IMO more readable than most of the other proposals we had. > >>> Qt relies on macros a lot, and while I have not followed the latest Modules >> development, I'm sure macros pose a problem for a modularized Qt, too >>> >>> So while emit is the latest in the line of macro clashes, it's not the >>> first and it >> likely won't be the last. So, please, just removing 'emit' because it's easy >> doesn't >> solve the problem for `signals` and `slots`. >>> >>> <dreaming>Can access specifiers have attributes....? >>> public [[qt::slots]]: >>> </dreaming> >> >> Why do we need it, if functions can already have attributes? > > Because it is in the wrong spot. I want to spot the signal call in a cpp file > and not a header. I must assume that the reason why we had emit in the first > place (besides "slots" and "signals") is the same. Marc was asking about the declarations in the headers where we have signals/Q_SIGNALS and slots/Q_SLOTS. Those could be replaced by adding an attribute to the method declaration. Cheers, Lars > >> public: >> [[qt::slot]] void mySlot(); >> >> protected: >> [[qt::signal] void mySignal(); > > I’d love to have this too (in addition to [[qt::emit]]) > > -- > Alex > _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
