Re: [boost] MSVC warnings for BOOST_PP_IS_EMPTY in Boost.Phoenix

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
> statement.

...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.