Subject: Re: [boost] MSVC warnings for BOOST_PP_IS_EMPTY in Boost.Phoenix
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2015-03-17 05:56:28
On Tuesday 17 March 2015 10:23:43 Damien Buhl wrote:
> On 11/03/2015 08:49, Andrey Semashev wrote:
> > On Wed, Mar 11, 2015 at 10:29 AM, Damien Buhl <damien.buhl_at_[hidden]>
> > wrote: [...]
> >>> Perhaps, 'auto' would be shorter?
> >>> BOOST_FUSION_ADAPT_STRUCT(
> >>> demo::employee,
> >>> (auto, name)
> >>> (auto, age)
> >>> )
> >>> It also looks kind of similar to C++14 lambdas.
> >> That looks nice, and it may be great, but I'm a bit concerned in giving
> >> a slight different meaning than the official one to a standard keyword.
> > Could you describe the difference?
> Actually there is not much difference, but what I wanted to say is that
> I am concerned, because it is the responsibilities of the compiler to
> implement the auto keyword, and if I was just forwarding it in the
> macros it would make sense to me, but I'm replacing it with BOOST_TYPEOF.
> Which is a decltype on recent compiler but an emulation on older compilier.
> In fact I'm just unsure if this wouldn't be a mistake by reusing a
> keyword which is already reserved by the standard and where is well
> defined usage for it : variable initialization and function return
...and lambda arguments.
Well, you're not actually using auto as a language keyword. IIUC the
implementation will be the same as the current one, only replacing the long
Fusion macro-like token with auto. The appealing point for auto is that as far
as I can tell, type deduction rules for the adapted members should be very
similar to those of auto.
Actually, my suggestion of auto is only partly motivated by semantics
similarity. What I also wanted is to have a shorter keyword instead of
BOOST_FUSION_ADAPT_AUTO which is way too long IMHO, and which I'll certainly
forget. I'm ok if you feel that auto does not suit well, but I would still
like a shorter alternative. The problem is that it has to be either
sufficiently qualified in order not to clash with user types or macros (in
which case we're back to BOOST_FUSION_ADAPT_AUTO) or be a language keyword. I
could also suggest the "_" placeholder, which is less informative but short.
> Possibly decltype would make more sense ? Or even typeof ?
Both these require an argument, which I don't think makes sense in this
context. Using these keywords without an argument makes even less sense to me.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk