[Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[Lars Knoll]

> On 24 Feb 2020, at 23:29, Marc Mutz <marc.mutz at kdab.com> wrote:
> 
> Hi Lars, others,
> 
> On 2020-02-24 12:25, Lars Knoll wrote:
>>> On 21 Feb 2020, at 17:39, Thiago Macieira <thiago.macieira at 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.

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

public:
[[qt::slot]] void mySlot();

protected:
[[qt::signal] void mySignal();

Cheers,
Lars