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

[Erik Verbruggen]

Hi all,

So to sum up the options from both the mailing-list and irc, I can go either of these routes:

1) just go with attributes as with my first patch
   - pro: only a few changes to go, and it is done
   - con: yet another toolkit specific extension which doesn't help everyone
2) implement GCC's user attributes:  __attribute__((user("your_funky_attribute")))
   - pro: more GCC compatibility, also useful for projects already using it (i.e. Mozilla)
   - con: would need significantly more work than the other routes
   - con: very GCC and very non standard, possibly obsoleted by:
3) c++0x attribute namespaces
   - pro: very standard
   - con: support seems to be minimal (if I got it right), so needs some work
   - con (?): c++0x specific, so we would need to support it for other language standards than just c++0x

So, before I spend time implementing all of them, what is the best way (or "the clang way") to go?

Then independent of that (because it can be exposed/implemented through any of the previous 3 options):

On 28 Sep, 2011,at 07:50 PM, Douglas Gregor <dgregor at apple.com> wrote:

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
 
From a Qt+clang point of view, this would definitely solve some problems. However, I think that this would give "funny" surprises when using boost+Qt with any other compiler.

Then a final note on time constraints: I *was* hoping to get enough support into (lib)clang 3.0, mainly for the "it just works and it rocks" factor. However, the amount of (good!) feedback indicates that this is not a trivial extension, so I am more than happy to go with the motto I often use: "If it ain't ready yes, then there is always a next release with more new cool features" (and no, marketing is not aware of this, yet, so there is little pressure ;-) ).

-- Erik.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110929/9a7c2f46/attachment.html>