This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [Patch] Implement std::experimental::variant
- From: Tim Shen <timshen at google dot com>
- To: Jonathan Wakely <jwakely at redhat dot com>
- Cc: "libstdc++" <libstdc++ at gcc dot gnu dot org>, Axel Naumann <Axel dot Naumann at cern dot ch>
- Date: Mon, 16 May 2016 10:00:32 -0700
- Subject: Re: [Patch] Implement std::experimental::variant
- Authentication-results: sourceware.org; auth=none
- References: <CAG4ZjNnKxAhg6nNjPFZjoFji50StG9LURa_Wt=OdejLJ=NkSUw at mail dot gmail dot com> <20160516130235 dot GX27545 at redhat dot com>
On Mon, May 16, 2016 at 6:02 AM, Jonathan Wakely wrote:
> Those constructors should be constexpr because in each case the
> alternative being constructed is 'literal' which has a constexpr
> constructor. I believe this is the hardest part of 'variant' to
> implement, so it would be good to know if your current approach is
> fundamentally incompatible with this requirement before it's too late
> to change it.
Good catch :). I believe that my current approach is fundamentally
incompatible with this requirement.
I current have two approaches to implement variant:
1) recursive union
2) placement-newed raw buffer
For 1), the following code example fails to compile:
struct literal {
constexpr literal() = default;
};
struct nonliteral {
nonliteral() { }
};
union A {
constexpr A() : a{} {}
literal a;
nonliteral b;
};
constexpr A a{};
The potential solution is to change the standard definition of
constexpr to allow the above case.
For 2), constexpr constructor body cannot have placement new. I found
some discussion here
<https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/_s7vi9pOhfY>,
but it seems to be complicated to implement & get standardized.
Do you have any other apporaches to make this work? Notice that the
"variadic multiple inheritance" appraoch doesn't work here, because it
aggregates data, instead of creating a data union.
The third option is to change the variant proposal to require all
alternatives to be literal type in order to have a literal variant
type. It's a safe and forward-compatible move in standardization's
perspective.
I'm not sure if in the future "constexpr" variable may not imply const
anymore, for example:
constexpr int a = 0; // not constexpr const int a = 0;
constexpr int iota() { return a++; }
If this may be the future, then a literal variant variant should
definitely hold literal alternatives only (so that it supports
mutation at compile-time for changing to all alternatives).
--
Regards,
Tim Shen