Boost logo

Boost :

Subject: Re: [boost] Another variant type (was: [peer review queue tardiness] [was Cleaning out the Boost review queue] Review Queue mem
From: Matt Calabrese (rivorus_at_[hidden])
Date: 2015-04-08 14:17:06


On Wed, Apr 8, 2015 at 6:14 AM, Larry Evans <cppljevans_at_[hidden]>
wrote:
>
> I can see how a new expression which is not a placement new
> would be disallowed; however, I don't see a reason why
> placement new would be disallowed when the void* 2nd argument
> is a pointer to a constexpr aligned_union member variable.
> Could you please provide a reference or explanation of why
> placement new is not allowed in a constexpr?

+1

Regardless of how it is achieved, there should really be some way of
getting this functionality with a literal type. Even with a recursive union
implementation, users are heavily limited in terms of what they can do. For
instance, copying/moving the variant (at least in the general case) cannot
be accomplished in the language with constexpr currently, at least as far
as I'm aware. In other words, you sadly cannot even return one from a
function in the constexpr world.

It's unfortunate because there is nothing that logically prohibits such a
type from being much more capable at compile-time, and the ramifications
could be pretty powerful. IIRC, Eric's work uses a discriminated union
behind the scenes for some ranges (joined ranges and probably others?).
Being able to make a discriminated union that is a regular type could
therefore make it much more feasible to work with high order functions that
operate on ranges at compile-time, including complicated transformed and
composite ranges. With such facilities, and if Faisal's constexpr lambda
efforts eventually make it into the language, compile-time programs could
potentially get significantly more powerful and easier to write. More of
the STL range algorithms and literal types of the future could have
implementations that are shared between the run-time and compile-time world.

-- 
-Matt Calabrese

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