Subject: Re: [boost] MSVC warnings for BOOST_PP_IS_EMPTY in Boost.Phoenix
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2015-03-17 05:56:28
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 <damien.buhl_at_[hidden]>
> > 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.