Boost logo

Boost :

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
 


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk