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: Damien Buhl (damien.buhl_at_[hidden])
Date: 2015-03-17 10:28:02

On 17/03/2015 10:56, Andrey Semashev wrote:
> 
> ...and lambda arguments.
> 

Thanks for completeness :).

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

I agree with you, and I'm trying to reduce to AUTO at least, if I get
courageous enough I'll try to put lowercase auto, but currently
BOOST_FUSION_ADAPT_AUTO is just a fallback when no BOOST_PP_VARIADICS
support is active.

I have added this only for support on older preprocessors. Most have
BOOST_PP_VARIADICS, and if it's a question of being short or
remembering, then you don't need to remember anything else than you can
completely omit the type or mix it with type declaration. As such :

BOOST_FUSION_ADAPT_STRUCT(
      demo::employee,
        (int, name),
        age,
        (std::string, location)
        (int, salary),
        gender
)

But usually one has no reason to repeat the type, it's mainly for
backward compatibility and possibly for people using implicit-conversion
to some other common type that I added this. So normally today, one
would write :

BOOST_FUSION_ADAPT_STRUCT(
      demo::employee,
        name,
        age,
        location,
        salary,
        gender
)

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

yes it's even worse when I think more after it.

I'll send you the link to the pull-request when I'll be done with a
proposal in this sense. Thanks to your input I'm getting more confident
in using auto as keyword for the fallback. :p.