Hi Lars, others,
On 2020-02-24 12:25, Lars Knoll wrote:
On 21 Feb 2020, at 17:39, Thiago Macieira <thiago.macie...@intel.com>
wrote:
On Friday, 21 February 2020 04:59:02 PST Ville Voutilainen wrote:
Having a keyword-extension to normal C++ is ugly as sin, to some of
us. It causes
fair amounts of "wtf is that?".
That was my reaction when I first saw it, in 1999.
Over 20 years later, I don't bat an eye.
After 20 years, my eyes simply ignore any ‘emit’ in the source code.
In any case, I do understand why Qt added emit as a keyword 25 years
ago. But today, we do have IDEs which should be able to figure out on
the fly whether a function call is a signal emission (as they already
do for virtual vs non virtual methods). So why don’t we move the over
to be a tooling problem? Simply highlight signal emissions differently
in the IDE and you don’t need a keyword for it anymore. It’s also
safer, as the keyword can be forgotten or applied to the wrong places.
Please don't make this only about emit. We had clashes with signals in
boost.signals, we have suffered clashes with Window's min/max and
several X11 #defines, we know we should not inflict (non-all-uppercase)
macros on the world.
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>
Thanks,
Marc
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
