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.