[cfe-dev] Proposal: parsing Qt signals/slots with attributes

[Douglas Gregor]

On Sep 29, 2011, at 12:28 AM, Konstantin Tokarev wrote:

> 
> 
> 29.09.2011, 03:06, "Douglas Gregor" <dgregor at apple.com>:
>> On Sep 28, 2011, at 12:34 PM, Konstantin Tokarev wrote:
>> 
>>>  28.09.2011, 21:50, "Douglas Gregor":
>>>>  Alright, since there haven't been enough crazy ideas today… I think we should consider defining 'signals'  and 'slots'  as context-sensitive keywords, rather than handling these as attributes on the access specifier. The grammar is fairly simple, and one need only look ahead a single token (to the ':') to determine whether we have the signals or slots keyword (vs. using it as an identifier). It shouldn't be much more work than threading attributes through the access specifiers like you've already done.
>>>> 
>>>>  IMO, the end result would be much cleaner than having to #define signals and slots (#define'ing Q_SIGNAL, Q_SLOT, etc. is fine by me), and has the added benefit of  helping resolve my longstanding grudge with Qt :)
>>>> 
>>>>    http://www.boost.org/doc/libs/1_47_0/doc/html/signals/s04.html#id2861476
>>>  It seems to me as there is a danger of keyword misinterpretation in non-QObject contexts.
>> 
>> I don't see any ambiguity. Can you provide an example?
> 
> Since "signals" and "slots" are not language-reserved keywords, there's non-zero probability that some 3rd party can also #define them for some other purposes.

So? You can break any context-sensitive keyword scheme by #define'ing that identifier as a macro. Any code that today defines signals or slots as a macro in a manner that isn't compatible with Qt's use of these keywords, is already broken when using Qt, so we've lost nothing. 

> So, IMHO it's needed to check if class inherits QObject.


To direct parsing? We don't want to do that, because we can't know whether this class inherits QObject, and we have to decide at parse time what these keywords mean:

	template<typename T>
	class X : public T {
	slots: // does X inherit QObject? Maybe it does, maybe it doesn't
	};

Whether MOC can actually handle this kind of thing today is, IMO, irrelevant; we shouldn't design the feature in a way that's broken in templates.

	- Doug