Re: [boost] MSVC warnings for BOOST_PP_IS_EMPTY in Boost.Phoenix

On Tuesday 17 March 2015 10:23:43 Damien Buhl wrote:

On 11/03/2015 08:49, Andrey Semashev wrote:

...

On Wed, Mar 11, 2015 at 10:29 AM, Damien Buhl wrote: [...]

...

...

Perhaps, 'auto' would be shorter?

BOOST_FUSION_ADAPT_STRUCT(

demo::employee, (auto, name) (auto, age)

)

It also looks kind of similar to C++14 lambdas.

That looks nice, and it may be great, but I'm a bit concerned in giving a slight different meaning than the official one to a standard keyword.

Could you describe the difference?

Actually there is not much difference, but what I wanted to say is that I am concerned, because it is the responsibilities of the compiler to implement the auto keyword, and if I was just forwarding it in the macros it would make sense to me, but I'm replacing it with BOOST_TYPEOF.

Which is a decltype on recent compiler but an emulation on older compilier.

In fact I'm just unsure if this wouldn't be a mistake by reusing a keyword which is already reserved by the standard and where is well defined usage for it : variable initialization and function return statement.

...and lambda arguments. 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.

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.