-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Damien Buhl Sent: 17 March 2015 14:28 To: boost@lists.boost.org 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