> -----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. > > 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. > 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
