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

[Kai Köhne]

Hi,

Another alternative is to actually use C++ attributes for this:

  [[qt::emit]] somethingChanged();

C++ attributes are required since C++11, and since C++17 the compiler is also required to just ignore one's it doesn't know [1]. Because it is part of the core language, It is also something every C++ IDE and tool does accept (and could even check for) ...

Kai

[1]: In C++11, gcc and clang seem to still warn. However, there are options to disable this.

> -----Original Message-----
> From: Development <development-bounces at qt-project.org> On Behalf Of Kai
> Köhne
> Sent: Thursday, February 20, 2020 2:44 PM
> To: Marc Mutz <marc.mutz at kdab.com>; development at qt-project.org
> Subject: Re: [Development] A modest proposal: disable lower-case keywords
> (emit, foreach, forever, signals, slots) by default
> 
> > -----Original Message-----
> > From: Development <development-bounces at qt-project.org> On Behalf Of
> > Marc Mutz via Development
> > Sent: Saturday, February 15, 2020 3:24 PM
> > To: development at qt-project.org
> > Subject: [Development] A modest proposal: disable lower-case keywords
> > (emit, foreach, forever, signals, slots) by default
> >
> > Hi,
> >
> > C++20 will contain new classes with emit() member functions
> > (wg21.link/P0053). While that will only pose problems for users that
> > include the new <osyncstream> header after (almost) any Qt header,
> > this should serve as a second shot across the bows (after namespace
> > boost::signals) that we should change something.
> >
> > To that effect, I'd like to propose that we switch the default for
> > QT_NO_KEYWORDS around.
> 
> As a counter proposal that (I hope) would get broader consensus,  I suggest to
> just do this for 'emit': QTBUG-82379 .
> 
> This keyword always seemed a bit odd to me anyway, because it has no
> semantics that's ensured by the compiler. I understand the ratio behind it, and
> there's obviously tons of code that uses it. But if I have the choice between
> 
>   Q_EMIT somethingChanged();
> 
> and just
> 
>  somethingChanged();
> 
> I personally prefer the second.
> 
> My 2 cents,
> 
> Kai
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development