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: Fletcher, John P (j.p.fletcher_at_[hidden])
Date: 2015-03-24 08:09:29

-----Original Message-----
From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Damien Buhl
Sent: 17 March 2015 14:28
To: boost_at_[hidden]
Subject: Re: [boost] MSVC warnings for BOOST_PP_IS_EMPTY in Boost.Phoenix

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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

My apologies that I missed that these messages are about Phoenix.  Is there a change of some sort needed in Phoenix?

I am not able to run any versions of MSVC so I cannot check, but will put up tests as needed.

John