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

Tor Arne Vestbø Tor.arne.Vestbo at qt.io
Wed Feb 26 13:42:14 CET 2020



> On 26 Feb 2020, at 13:30, Lars Knoll <lars.knoll at qt.io> wrote:
> 
> 
> 
>> On 26 Feb 2020, at 10:38, Alex Blasche <alexander.blasche at qt.io> wrote:
>> 
>> 
>> 
>>> -----Original Message-----
>>> From: Lars Knoll <lars.knoll at 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


More information about the Development mailing list