Is there any reason there's no constexpr version of placement new? I
think it should only set the vptr and call a constexpr ctor if
available.

--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On 2015-08-31 17:49, dgutson . wrote:
> Is there any reason there's no constexpr version of placement new? I
> think it should only set the vptr and call a constexpr ctor if
> available.
>

This assumes that the implementation uses a vptr. That's not required by
the rest of the standard.


Bo Persson


--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Mon, Aug 31, 2015 at 12:59 PM, Bo Persson <bop@gmb.dk> wrote:
> On 2015-08-31 17:49, dgutson . wrote:
>>
>> Is there any reason there's no constexpr version of placement new? I
>> think it should only set the vptr and call a constexpr ctor if
>> available.
>>
>
> This assumes that the implementation uses a vptr. That's not required by =
the
> rest of the standard.

I'm not actually assuming it, but giving an example. It should do what
placement new currently does, but constexpr-declared (and call the
constexpr ctor if available).

>
>
> Bo Persson
>
>
> --
>
> --- You received this message because you are subscribed to the Google
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.



--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On 08/31/2015 10:49 AM, dgutson . wrote:
> Is there any reason there's no constexpr version of placement new? I
> think it should only set the vptr and call a constexpr ctor if
> available.
>
Please see essentially the same question in general newsgroup.
That post had headers:

From: Larry Evans <cppljevans@suddenlink.net>
Newsgroups: gmane.comp.lang.c++.isocpp.general
Subject: why placement new not allowed in constexpr?
Date: Mon, 13 Apr 2015 04:35:51 -0500

-regards,
Larry




--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Mon, Aug 31, 2015 at 1:54 PM, Larry Evans <cppljevans@suddenlink.net> wr=
ote:
> On 08/31/2015 10:49 AM, dgutson . wrote:
>> Is there any reason there's no constexpr version of placement new? I
>> think it should only set the vptr and call a constexpr ctor if
>> available.
>>
> Please see essentially the same question in general newsgroup.
> That post had headers:
>
> From: Larry Evans <cppljevans@suddenlink.net>
> Newsgroups: gmane.comp.lang.c++.isocpp.general
> Subject: why placement new not allowed in constexpr?
> Date: Mon, 13 Apr 2015 04:35:51 -0500

Thanks.
We need this in our static_alloc feature (I mentioned it in a previous
message), so this is something like
chicken-egg issue. We will have to address this in the proposal.

   Daniel.

>
> -regards,
> Larry
>
>
>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups=
 "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
 email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at http://groups.google.com/a/isocpp.org/group/std-propo=
sals/.



--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

--001a1134e21285a56f051e9f8bfa
Content-Type: text/plain; charset=UTF-8

On Mon, Aug 31, 2015 at 8:49 AM, dgutson . <danielgutson@gmail.com> wrote:

> Is there any reason there's no constexpr version of placement new? I
> think it should only set the vptr and call a constexpr ctor if
> available.
>

Note that the inability to invoke constexpr placement new prevents certain
types from being fully constexpr, such as variant/optional/expected, etc.
Without constexpr placement new, you can't currently even copy or move such
a sum type unless all of the types involved have trivial copy/move and
destroy. You can't, in the general case, even return them from functions.
Not having constexpr placement new hurts some fairly fundamental code in
practice.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a1134e21285a56f051e9f8bfa
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Aug 31, 2015 at 8:49 AM, dgutson . <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:danielgutson@gmail.com" target=3D"_blank">danielgutson@gmail.com</a>&gt=
;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex">Is there any reason there=
&#39;s no constexpr version of placement new? I<br>
think it should only set the vptr and call a constexpr ctor if<br>
available.<br></blockquote><div><br></div><div>Note that the inability to i=
nvoke constexpr placement new prevents certain types from being fully const=
expr, such as variant/optional/expected, etc. Without constexpr placement n=
ew, you can&#39;t currently even copy or move such a sum type unless all of=
 the types involved have trivial copy/move and destroy. You can&#39;t, in t=
he general case, even return them from functions. Not having constexpr plac=
ement new hurts some fairly fundamental code in practice.</div></div></div>=
</div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1134e21285a56f051e9f8bfa--

.

On Mon, Aug 31, 2015 at 3:24 PM, 'Matt Calabrese' via ISO C++ Standard
- Future Proposals <std-proposals@isocpp.org> wrote:
> On Mon, Aug 31, 2015 at 8:49 AM, dgutson . <danielgutson@gmail.com> wrote=
:
>>
>> Is there any reason there's no constexpr version of placement new? I
>> think it should only set the vptr and call a constexpr ctor if
>> available.
>
>
> Note that the inability to invoke constexpr placement new prevents certai=
n
> types from being fully constexpr, such as variant/optional/expected, etc.
> Without constexpr placement new, you can't currently even copy or move su=
ch
> a sum type unless all of the types involved have trivial copy/move and
> destroy. You can't, in the general case, even return them from functions.
> Not having constexpr placement new hurts some fairly fundamental code in
> practice.

We developed static_alloc<T>.
Now we are working on having a static_new<T> which is a combination of
static_alloc and (constexpr) placement new. We will investigate & try
further and will come back.

This is critical before facing any attempt to solve the
static_allocators / current STL containers in ROM as discussed
previously in the other thread.

>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.



--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

--Apple-Mail=_FB3FDB36-B44A-4978-BBDF-E8E591D07778
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9309=E2=80=9301, at 2:24 AM, 'Matt Calabrese' via ISO C++ S=
tandard - Future Proposals <std-proposals@isocpp.org> wrote:
>=20
> Note that the inability to invoke constexpr placement new prevents certai=
n types from being fully constexpr, such as variant/optional/expected, etc.=
 Without constexpr placement new, you can't currently even copy or move suc=
h a sum type unless all of the types involved have trivial copy/move and de=
stroy. You can't, in the general case, even return them from functions. Not=
 having constexpr placement new hurts some fairly fundamental code in pract=
ice.

It also showed up in the recent thread, "Tuple Construction Order is Unspec=
ified.=E2=80=9D Because tuple is constexpr, its members cannot be implement=
ed as optimally-packed optionals with left-to-right initialization order.

Towards a solution, it would be nice if the extension could be restricted:

=E2=80=94 Only allow the standard library placement new from <new>. We don=
=E2=80=99t need any kind of allocation function, and this guarantees that t=
he returned address is exactly the argument.
=E2=80=94 The argument must be the address of an inactive union member of t=
he same type as the type-id given to new. The constexpr interpreter shouldn=
=E2=80=99t need to allow putting any object at any address within a buffer.

The latter requirement seems to rule out variant, but it would be nice anyw=
ay if the language had some way to expand a pack into a union, such as inhe=
ritance.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_FB3FDB36-B44A-4978-BBDF-E8E591D07778
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9309=
=E2=80=9301, at 2:24 AM, 'Matt Calabrese' via ISO C++ Standard - Future Pro=
posals &lt;<a href=3D"mailto:std-proposals@isocpp.org" class=3D"">std-propo=
sals@isocpp.org</a>&gt; wrote:</div><br class=3D"Apple-interchange-newline"=
><div class=3D""><span style=3D"font-family: Helvetica; font-size: 12px; fo=
nt-style: normal; font-variant: normal; font-weight: normal; letter-spacing=
: normal; line-height: normal; orphans: auto; text-align: start; text-inden=
t: 0px; text-transform: none; white-space: normal; widows: auto; word-spaci=
ng: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !impo=
rtant;" class=3D"">Note that the inability to invoke constexpr placement ne=
w prevents certain types from being fully constexpr, such as variant/option=
al/expected, etc. Without constexpr placement new, you can't currently even=
 copy or move such a sum type unless all of the types involved have trivial=
 copy/move and destroy. You can't, in the general case, even return them fr=
om functions. Not having constexpr placement new hurts some fairly fundamen=
tal code in practice.</span></div></blockquote></div><br class=3D""><div cl=
ass=3D"">It also showed up in the recent thread, "Tuple Construction Order =
is Unspecified.=E2=80=9D Because tuple is constexpr, its members cannot be =
implemented as optimally-packed optionals with left-to-right initialization=
 order.</div><div class=3D""><br class=3D""></div><div class=3D"">Towards a=
 solution, it would be nice if the extension could be restricted:</div><div=
 class=3D""><br class=3D""></div><div class=3D"">=E2=80=94 Only allow the s=
tandard library placement new from <font face=3D"Courier" class=3D"">&lt;ne=
w&gt;</font>. We don=E2=80=99t need any kind of allocation function, and th=
is guarantees that the returned address is exactly the argument.</div><div =
class=3D"">=E2=80=94 The argument must be the address of an inactive union =
member of the same type as the type-id given to <font face=3D"Courier" clas=
s=3D"">new</font>. The constexpr interpreter shouldn=E2=80=99t need to allo=
w putting any object at any address within a buffer.</div><div class=3D""><=
br class=3D""></div><div class=3D"">The latter requirement seems to rule ou=
t variant, but it would be nice anyway if the language had some way to expa=
nd a pack into a union, such as inheritance.</div><div class=3D""><br class=
=3D""></div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_FB3FDB36-B44A-4978-BBDF-E8E591D07778--

.

--Apple-Mail=_A754B39A-E52F-401C-B187-70E0C740645E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9309=E2=80=9301, at 11:46 AM, David Krauss <potswa@gmail.co=
m> wrote:
>=20
> The latter requirement seems to rule out variant, but it would be nice an=
yway if the language had some way to expand a pack into a union, such as in=
heritance.

To be sure, we have aligned_union (or the like; I=E2=80=99m not looking up =
references now, sorry), but it=E2=80=99s not really a union and I don=E2=80=
=99t suppose the core language should be tied to it.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_A754B39A-E52F-401C-B187-70E0C740645E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><div class=3D""><b=
r class=3D""></div><div><blockquote type=3D"cite" class=3D""><div class=3D"=
">On 2015=E2=80=9309=E2=80=9301, at 11:46 AM, David Krauss &lt;<a href=3D"m=
ailto:potswa@gmail.com" class=3D"">potswa@gmail.com</a>&gt; wrote:</div><br=
 class=3D"Apple-interchange-newline"><div class=3D""><span style=3D"font-fa=
mily: Helvetica; font-size: 12px; font-style: normal; font-variant: normal;=
 font-weight: normal; letter-spacing: normal; line-height: normal; orphans:=
 auto; text-align: start; text-indent: 0px; text-transform: none; white-spa=
ce: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px=
; float: none; display: inline !important;" class=3D"">The latter requireme=
nt seems to rule out variant, but it would be nice anyway if the language h=
ad some way to expand a pack into a union, such as inheritance.</span></div=
></blockquote></div><br class=3D""><div class=3D"">To be sure, we have <fon=
t face=3D"Courier" class=3D"">aligned_union</font>&nbsp;(or the like; I=E2=
=80=99m not looking up references now, sorry), but it=E2=80=99s not <i clas=
s=3D"">really</i>&nbsp;a union and I don=E2=80=99t suppose the core languag=
e should be tied to it.</div><div class=3D""><br class=3D""></div></body></=
html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_A754B39A-E52F-401C-B187-70E0C740645E--

.

--Apple-Mail=_865C6F27-78AF-4441-9B75-811D8249C993
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9309=E2=80=9301, at 11:50 AM, David Krauss <potswa@gmail.co=
m> wrote:
>=20
>=20
>> On 2015=E2=80=9309=E2=80=9301, at 11:46 AM, David Krauss <potswa@gmail.c=
om <mailto:potswa@gmail.com>> wrote:
>>=20
>> The latter requirement seems to rule out variant, but it would be nice a=
nyway if the language had some way to expand a pack into a union, such as i=
nheritance.
>=20
> To be sure, we have aligned_union (or the like; I=E2=80=99m not looking u=
p references now, sorry), but it=E2=80=99s not really a union and I don=E2=
=80=99t suppose the core language should be tied to it.

Here=E2=80=99s a solution: A variadic union with proper members and an acce=
ssor. What do folks think?

#if __cplusplus =3D=3D 201411
#   define CXX14( X ) X // X should be unnecessary with the proposed extens=
ion.
#endif

template< typename ... >
union variant_union {}; // result type of std::aligned_union

// Generic cast to undo type erasure. Other cases not shown.
template< typename to, typename head, typename ... tail >
to & recover_cast( variant_union< head, tail ... > & in )
    { return recover_cast< to >( in.t ); }

template< typename head, typename ... tail >
union variant_union< head, tail ... > {
    constexpr variant_union() CXX14( : disabled {} ) {}
    ~ variant_union() {}

    template< typename to >
    friend
    std::enable_if_t< std::is_same< head, to >::value, head & >
    recover_cast( variant_union & in )
        { return in.h; }

    template< typename to, typename head_, typename ... tail_ >
    friend to & recover_cast( variant_union< head_, tail_ ... > & in );

private:
    CXX14( char disabled; )
    head h;
    variant_union< tail ... > t;
};

This can=E2=80=99t be merged into aligned_union because a union with a non-=
POD member is not POD as aligned_union::type is required to be.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_865C6F27-78AF-4441-9B75-811D8249C993
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9309=
=E2=80=9301, at 11:50 AM, David Krauss &lt;<a href=3D"mailto:potswa@gmail.c=
om" class=3D"">potswa@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-inte=
rchange-newline"><div class=3D""><meta http-equiv=3D"Content-Type" content=
=3D"text/html charset=3Dutf-8" class=3D""><div style=3D"word-wrap: break-wo=
rd; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=
=3D""><div class=3D""><br class=3D""></div><div class=3D""><blockquote type=
=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9309=E2=80=9301, at 11:4=
6 AM, David Krauss &lt;<a href=3D"mailto:potswa@gmail.com" class=3D"">potsw=
a@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-interchange-newline"><di=
v class=3D""><span style=3D"font-family: Helvetica; font-size: 12px; font-s=
tyle: normal; font-variant: normal; font-weight: normal; letter-spacing: no=
rmal; line-height: normal; orphans: auto; text-align: start; text-indent: 0=
px; text-transform: none; white-space: normal; widows: auto; word-spacing: =
0px; -webkit-text-stroke-width: 0px; float: none; display: inline !importan=
t;" class=3D"">The latter requirement seems to rule out variant, but it wou=
ld be nice anyway if the language had some way to expand a pack into a unio=
n, such as inheritance.</span></div></blockquote></div><br class=3D""><div =
class=3D"">To be sure, we have <font face=3D"Courier" class=3D"">aligned_un=
ion</font>&nbsp;(or the like; I=E2=80=99m not looking up references now, so=
rry), but it=E2=80=99s not <i class=3D"">really</i>&nbsp;a union and I don=
=E2=80=99t suppose the core language should be tied to it.</div></div></div=
></blockquote><br class=3D""></div><div>Here=E2=80=99s a solution: A variad=
ic union with proper members and an accessor. What do folks think?</div><di=
v><br class=3D""></div><div><span style=3D"font-family: Courier;" class=3D"=
">#if __cplusplus =3D=3D 201411</span></div><div><span style=3D"font-family=
: Courier;" class=3D""># &nbsp; define CXX14( X ) X // X should be unnecess=
ary with the proposed extension.</span></div><div><span style=3D"font-famil=
y: Courier;" class=3D"">#endif</span></div><div><span style=3D"font-family:=
 Courier;" class=3D""><br class=3D""></span></div><div><font face=3D"Courie=
r" class=3D"">template&lt; typename ... &gt;<br class=3D"">union&nbsp;varia=
nt_union&nbsp;{}; // result type of std::aligned_union<br class=3D""><br cl=
ass=3D"">// Generic cast to undo type erasure.&nbsp;Other cases not shown.<=
br class=3D"">template&lt; typename to, typename head, typename ... tail &g=
t;<br class=3D"">to &amp; recover_cast(&nbsp;variant_union&lt; head, tail .=
... &gt; &amp; in )<br class=3D"">&nbsp; &nbsp;&nbsp;{ return recover_cast&l=
t; to &gt;( in.t ); }<br class=3D""><br class=3D"">template&lt; typename he=
ad, typename ... tail &gt;<br class=3D"">union&nbsp;variant_union&lt; head,=
 tail ... &gt; {<br class=3D"">&nbsp; &nbsp;&nbsp;constexpr&nbsp;variant_un=
ion() CXX14( : disabled {} ) {}<br class=3D"">&nbsp; &nbsp;&nbsp;~&nbsp;var=
iant_union() {}<br class=3D""><br class=3D"">&nbsp; &nbsp;&nbsp;template&lt=
; typename to &gt;<br class=3D"">&nbsp; &nbsp;&nbsp;friend</font></div><div=
><font face=3D"Courier" class=3D"">&nbsp; &nbsp; std::enable_if_t&lt; std::=
is_same&lt; head, to &gt;::value, head &amp; &gt;</font></div><div><font fa=
ce=3D"Courier" class=3D"">&nbsp; &nbsp; recover_cast(&nbsp;variant_union&nb=
sp;&amp; in )<br class=3D"">&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;{ return in.h;=
 }<br class=3D""><br class=3D"">&nbsp; &nbsp; template&lt; typename to, typ=
ename head_, typename ... tail_ &gt;<br class=3D"">&nbsp; &nbsp; friend to =
&amp; recover_cast(&nbsp;variant_union&lt; head_, tail_ ... &gt; &amp; in )=
;<br class=3D""><br class=3D"">private:<br class=3D"">&nbsp; &nbsp; CXX14( =
char disabled; )<br class=3D"">&nbsp; &nbsp;&nbsp;head h;<br class=3D"">&nb=
sp; &nbsp;&nbsp;variant_union&lt; tail ... &gt; t;<br class=3D"">};<br clas=
s=3D""></font><br class=3D""></div><div><div>This can=E2=80=99t be merged i=
nto <font face=3D"Courier" class=3D"">aligned_union</font> because a union =
with a non-POD member is not POD as <font face=3D"Courier" class=3D"">align=
ed_union::type</font> is required to be.</div><div><br class=3D""></div></d=
iv></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_865C6F27-78AF-4441-9B75-811D8249C993--

.

On 09/02/2015 10:24 PM, David Krauss wrote:
>=20
>> On 2015=E2=80=9309=E2=80=9301, at 11:50 AM, David Krauss <potswa@gmail.c=
om
>> <mailto:potswa@gmail.com>> wrote:
>>
>>
>>> On 2015=E2=80=9309=E2=80=9301, at 11:46 AM, David Krauss <potswa@gmail.=
com
>>> <mailto:potswa@gmail.com>> wrote:
>>>
>>> The latter requirement seems to rule out variant, but it would be
>>> nice anyway if the language had some way to expand a pack into a
>>> union, such as inheritance.
>>
>> To be sure, we have aligned_union (or the like; I=E2=80=99m not looking =
up
>> references now, sorry), but it=E2=80=99s not /really/ a union and I don=
=E2=80=99t
>> suppose the core language should be tied to it.
>=20
> Here=E2=80=99s a solution: A variadic union with proper members and an ac=
cessor.
> What do folks think?
>=20
> #if __cplusplus =3D=3D 201411
> #   define CXX14( X ) X // X should be unnecessary with the proposed
> extension.
> #endif
>=20
> template< typename ... >
> union variant_union {}; // result type of std::aligned_union
>=20
> // Generic cast to undo type erasure. Other cases not shown.
> template< typename to, typename head, typename ... tail >
> to & recover_cast( variant_union< head, tail ... > & in )
>     { return recover_cast< to >( in.t ); }
>=20
> template< typename head, typename ... tail >
> union variant_union< head, tail ... > {
>     constexpr variant_union() CXX14( : disabled {} ) {}
>     ~ variant_union() {}
>=20
>     template< typename to >
>     friend
>     std::enable_if_t< std::is_same< head, to >::value, head & >
>     recover_cast( variant_union & in )
>         { return in.h; }
>=20
>     template< typename to, typename head_, typename ... tail_ >
>     friend to & recover_cast( variant_union< head_, tail_ ... > & in );
>=20
> private:
>     CXX14( char disabled; )
>     head h;
>     variant_union< tail ... > t;
> };
>=20
Wouldn't:

>     head h;
>     variant_union< tail ... > t;

mean:
   sizeof(variant_union<T1,T2,...Tn>)
>=3D sizeof(T1)+sizeof(T2)+..._sizeof(Tn)

?  Maybe you meant:

> union{
>   head h;
>   variant_union< tail ... > t;
> }

which is, AFAICT, pretty close to what was proposed here:

https://github.com/eggs-cpp/variant/blob/master/include/eggs/variant/detail=
/storage.hpp#L88

-regards,
Larry



--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

--Apple-Mail=_8021AEFB-E5ED-4848-8992-97A27ADB452B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9309=E2=80=9303, at 6:45 PM, Larry Evans <cppljevans@sudden=
link.net> wrote:
>=20
> ?  Maybe you meant:
>=20
>> union{
>>  head h;
>>  variant_union< tail ... > t;
>> }
>=20
> which is, AFAICT, pretty close to what was proposed here:

That=E2=80=99s just what I wrote: the template is a union. Unions can have =
member functions too.

> https://github.com/eggs-cpp/variant/blob/master/include/eggs/variant/deta=
il/storage.hpp#L88

Yep, that=E2=80=99s the idea. I left out the trivially destructible part fo=
r brevity.

Again, I=E2=80=99m suggesting this as a foundation for constexpr facilities=
, not only for its own sake. The idea is that optional can be engaged withi=
n a constant expression after construction, variant can likewise switch act=
ive members, and tuple can reorder nontrivial constructors, as long as they=
=E2=80=99re all built on variant_union, and placement new is allowed within=
 the narrowest possible constraints.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_8021AEFB-E5ED-4848-8992-97A27ADB452B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9309=
=E2=80=9303, at 6:45 PM, Larry Evans &lt;<a href=3D"mailto:cppljevans@sudde=
nlink.net" class=3D"">cppljevans@suddenlink.net</a>&gt; wrote:</div><br cla=
ss=3D"Apple-interchange-newline"><div class=3D"">? &nbsp;Maybe you meant:<b=
r class=3D""><br class=3D""><blockquote type=3D"cite" class=3D"">union{<br =
class=3D""> &nbsp;head h;<br class=3D""> &nbsp;variant_union&lt; tail ... &=
gt; t;<br class=3D"">}<br class=3D""></blockquote><br class=3D"">which is, =
AFAICT, pretty close to what was proposed here:<br class=3D""></div></block=
quote><div><br class=3D""></div><div>That=E2=80=99s just what I wrote: the =
template is a union. Unions can have member functions too.</div><br class=
=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><a href=3D"https=
://github.com/eggs-cpp/variant/blob/master/include/eggs/variant/detail/stor=
age.hpp#L88" class=3D"">https://github.com/eggs-cpp/variant/blob/master/inc=
lude/eggs/variant/detail/storage.hpp#L88</a><br class=3D""></div></blockquo=
te><div><br class=3D""></div><div>Yep, that=E2=80=99s the idea. I left out =
the trivially destructible part for brevity.</div><div><br class=3D""></div=
><div>Again, I=E2=80=99m suggesting this as a foundation for constexpr faci=
lities, not only for its own sake. The idea is that <font face=3D"Courier" =
class=3D"">optional</font> can be engaged within a constant expression afte=
r construction,&nbsp;<font face=3D"Courier" class=3D"">variant</font>&nbsp;=
can likewise switch active members, and <font face=3D"Courier" class=3D"">t=
uple</font> can reorder nontrivial constructors, as long as they=E2=80=99re=
 all built on <font face=3D"Courier" class=3D"">variant_union</font>, and p=
lacement new is allowed within the narrowest possible constraints.</div></d=
iv><br class=3D""></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_8021AEFB-E5ED-4848-8992-97A27ADB452B--

.

On 09/03/2015 09:16 AM, David Krauss wrote:
>
>> On 2015=E2=80=9309=E2=80=9303, at 6:45 PM, Larry Evans <cppljevans@sudde=
nlink.net
>> <mailto:cppljevans@suddenlink.net>> wrote:
>>
>> ?  Maybe you meant:
>>
>>> union{
>>>  head h;
>>>  variant_union< tail ... > t;
>>> }
>>
>> which is, AFAICT, pretty close to what was proposed here:
>
> That=E2=80=99s just what I wrote: the template is a union. Unions can hav=
e
> member functions too.

Ah! Sorry. I had blinders on because I didn't notice union in front
of the variant_union (because I'm so used to seeing struct instead).

>>
https://github.com/eggs-cpp/variant/blob/master/include/eggs/variant/detail=
/storage.hpp#L88

> Yep, that=E2=80=99s the idea. I left out the trivially
> destructible part for brevity.

I Bcc'ed one of the authors of the eggs-cpp/variant in my
previous reply; hence, maybe he'll reply explaining why he
didn't used union instead of struct.

However, one *possible* problem with this recursive union is
compile times. I would guess that such a recursive union
would have similar compile time issues as a recursively
defined tuple as described by Richard Smith in this post:

http://article.gmane.org/gmane.comp.lang.c%2B%2B.isocpp.general/6583

Does a variant_union avoid these same problems somehow?

>
> Again, I=E2=80=99m suggesting this as a foundation for constexpr
> facilities, not only for its own sake. The idea is that
> optional can be engaged within a constant expression after
> construction, variant can likewise switch active members,
> and tuple can reorder nontrivial constructors, as long as
> they=E2=80=99re all built on variant_union, and placement new is
> allowed within the narrowest possible constraints.
>

Sorry, I still can't see how a variant_union could be used
to create a tuple. Could you post a brief outline of how
that could be done?

TIA.

-regards,
Larry



--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On 09/03/2015 10:10 AM, Larry Evans wrote:
> On 09/03/2015 09:16 AM, David Krauss wrote:
[snip]
>>
>> Again, I=E2=80=99m suggesting this as a foundation for constexpr
>> facilities, not only for its own sake. The idea is that
>> optional can be engaged within a constant expression after
>> construction, variant can likewise switch active members,
>> and tuple can reorder nontrivial constructors, as long as
>> they=E2=80=99re all built on variant_union, and placement new is
>> allowed within the narrowest possible constraints.
>>
>
> Sorry, I still can't see how a variant_union could be used
> to create a tuple. Could you post a brief outline of how
> that could be done?
>
[snip]

I did reread your reply:

  http://article.gmane.org/gmane.comp.lang.c%2B%2B.isocpp.general/6585

but the only way I can figure how to use variant_union is
as:

  template<typename ...T>
  struct tuple
  : tuple_impl<make_index_sequence<N>, variant_union<T>...>
  { /*...*/ };

which is simply a slight modification of the code posted
here:

  http://article.gmane.org/gmane.comp.lang.c%2B%2B.isocpp.general/6536

Is that what you had in mind?

-regards,
Larry



--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On 9/3/2015 12:10 PM, Larry Evans wrote:
> On 09/03/2015 09:16 AM, David Krauss wrote:
>>
> https://github.com/eggs-cpp/variant/blob/master/include/eggs/variant/deta=
il/storage.hpp#L88
>
>> Yep, that=E2=80=99s the idea. I left out the trivially
>> destructible part for brevity.
>
> I Bcc'ed one of the authors of the eggs-cpp/variant in my
> previous reply; hence, maybe he'll reply explaining why he
> didn't used union instead of struct.

No, you didn't, as far as I can tell.

I went with `struct` simply because I am later inheriting from it (for=20
convenience). Otherwise, there is not really much difference between:

     union U { ... };

and

     struct U { union { ... } };

Both are union-like classes.

> However, one *possible* problem with this recursive union is
> compile times. I would guess that such a recursive union
> would have similar compile time issues as a recursively
> defined tuple as described by Richard Smith in this post:
>
> http://article.gmane.org/gmane.comp.lang.c%2B%2B.isocpp.general/6583
>
> Does a variant_union avoid these same problems somehow?

Those problems do indeed apply to any recursive implementation. Here's=20
an attempt at mitigating them:

https://github.com/eggs-cpp/variant/tree/log2

Currently blocked on https://llvm.org/bugs/show_bug.cgi?id=3D24058

Regards,
--=20
Agust=C3=ADn K-ballo Berg=C3=A9.-
http://talesofcpp.fusionfenix.com

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On 09/03/2015 11:03 AM, Agust=C3=ADn K-ballo Berg=C3=A9 wrote:
> On 9/3/2015 12:10 PM, Larry Evans wrote:
>> On 09/03/2015 09:16 AM, David Krauss wrote:
>>>
>> https://github.com/eggs-cpp/variant/blob/master/include/eggs/variant/det=
ail/storage.hpp#L88
>>
>>
>>> Yep, that=E2=80=99s the idea. I left out the trivially
>>> destructible part for brevity.
>>
>> I Bcc'ed one of the authors of the eggs-cpp/variant in my
>> previous reply; hence, maybe he'll reply explaining why he
>> didn't used union instead of struct.
>=20
> No, you didn't, as far as I can tell.

I should have been more specific.
I Bcc'ed to Gonzalo.  I picked his name
because it was on:

  http://lists.boost.org/Archives/boost/2015/04/221325.php

Sorry for not Bcc'ing you also.

>=20
> I went with `struct` simply because I am later inheriting from it (for
> convenience). Otherwise, there is not really much difference between:
>=20
>     union U { ... };
>=20
> and
>=20
>     struct U { union { ... } };
>=20
> Both are union-like classes.

OK.  Thanks for the rationale.

[snip]


--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On 9/3/2015 1:29 PM, Larry Evans wrote:
> On 09/03/2015 11:03 AM, Agust=C3=ADn K-ballo Berg=C3=A9 wrote:
>> On 9/3/2015 12:10 PM, Larry Evans wrote:
>>> On 09/03/2015 09:16 AM, David Krauss wrote:
>>>>
>>> https://github.com/eggs-cpp/variant/blob/master/include/eggs/variant/de=
tail/storage.hpp#L88
>>>
>>>
>>>> Yep, that=E2=80=99s the idea. I left out the trivially
>>>> destructible part for brevity.
>>>
>>> I Bcc'ed one of the authors of the eggs-cpp/variant in my
>>> previous reply; hence, maybe he'll reply explaining why he
>>> didn't used union instead of struct.
>>
>> No, you didn't, as far as I can tell.
>
> I should have been more specific.
> I Bcc'ed to Gonzalo.  I picked his name
> because it was on:
>
>    http://lists.boost.org/Archives/boost/2015/04/221325.php

Maybe I should have been more specific too, I am the only author of=20
Eggs.Variant ;)

Regards,
--=20
Agust=C3=ADn K-ballo Berg=C3=A9.-
http://talesofcpp.fusionfenix.com

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

--Apple-Mail=_FF9445FF-6A9F-421D-93EF-73D15680C40A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9309=E2=80=9303, at 11:41 PM, Larry Evans <cppljevans@sudde=
nlink.net> wrote:
>=20
> but the only way I can figure how to use variant_union is
> as:
>=20
>  template<typename ...T>
>  struct tuple
>  : tuple_impl<make_index_sequence<N>, variant_union<T>...>
>  { /*...*/ };
>=20
> which is simply a slight modification of the code posted
> here:
>=20
>  http://article.gmane.org/gmane.comp.lang.c%2B%2B.isocpp.general/6536
>=20
> Is that what you had in mind?

More or less. variant_union is only used with one argument, so maybe it=E2=
=80=99s overkill. The only class that would use its recursion is variant. (=
On the other hand, it=E2=80=99s maybe useful for that char member which cou=
ld still be needed if the proposal does not remove the requirement that a c=
onstexpr union constructor must set an active member.)

I was suggesting to separate storage from initialization, so it would be mo=
re like this (just a draft, not compiled):

// Indexed storage for members
template< std::size_t index, typename elem, typename =3D void >
struct dumb_storage_leaf {
    variant_union< elem > s;
};

// Store empty members as proper base subobjects in empty owners, canceling=
 dumb storage.
template< std::size_t index, typename elem >
struct dumb_storage_leaf< index, elem, std::enable_if_t< std::is_empy< elem=
 >::value > >
    {};

// Find indexed dumb storage.
template< typename derived, std::size_t index, typename elem, typename =3D =
void >
struct empty_owner_access {
    elem & get() {
        return recover_cast< elem & >(
            static_cast< dumb_storage_leaf< index, elem > & >(
                static_cast< derived & >( * this )
            ).s
        );
    }
};

// Find in-owner storage.
template< typename derived, std::size_t index, typename elem >
struct empty_owner_access< derived, index, elem, std::enable_if_t< std::is_=
empy< elem >::value > >
    : private elem
    { elem & get() { return * this; } };

// Take ownership and construct/destroy the tuple element.
template< typename derived, std::size_t index, typename elem >
struct empty_owner_leaf
    : empty_owner_access< derived, index, elem > {
    template< typename ... arg >
    empty_owner( arg && ... a )
        { new( (void*) & this->get() ) elem( std::forward< arg >( a ) ... )=
; }

    ~ empty_owner()
        { this->get().elem:: ~ elem(); }
};

template< typename tuple, typename index >
struct tuple_impl;

template< typename ... elem >
struct tuple;

// Collect all the leaves in one base class list to maximize EBCO.
template< typename ... elem, std::size_t ... index >
struct tuple_impl< tuple< elem ... >, std::index_sequence< index ... > >
    : optimally_pack_permute_bases< dumb_storage_leaf< index, elem > ... >
    , empty_owner_leaf< tuple_impl< tuple< elem ... >, std::index_sequence<=
 index ... > >, // CRTP
                         index, elem > ...
    {};

template< typename ... elem >
struct tuple {
    tuple_impl< tuple, std::make_index_sequence< sizeof ... (elem) > > impl=
;
};

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_FF9445FF-6A9F-421D-93EF-73D15680C40A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9309=
=E2=80=9303, at 11:41 PM, Larry Evans &lt;<a href=3D"mailto:cppljevans@sudd=
enlink.net" class=3D"">cppljevans@suddenlink.net</a>&gt; wrote:</div><br cl=
ass=3D"Apple-interchange-newline"><div class=3D"">but the only way I can fi=
gure how to use variant_union is<br class=3D"">as:<br class=3D""><br class=
=3D""> &nbsp;template&lt;typename ...T&gt;<br class=3D""> &nbsp;struct tupl=
e<br class=3D""> &nbsp;: tuple_impl&lt;make_index_sequence&lt;N&gt;, varian=
t_union&lt;T&gt;...&gt;<br class=3D""> &nbsp;{ /*...*/ };<br class=3D""><br=
 class=3D"">which is simply a slight modification of the code posted<br cla=
ss=3D"">here:<br class=3D""><br class=3D""> &nbsp;<a href=3D"http://article=
..gmane.org/gmane.comp.lang.c%2B%2B.isocpp.general/6536" class=3D"">http://a=
rticle.gmane.org/gmane.comp.lang.c%2B%2B.isocpp.general/6536</a><br class=
=3D""><br class=3D"">Is that what you had in mind?<br class=3D""></div></bl=
ockquote></div><br class=3D""><div class=3D"">More or less. <font face=3D"C=
ourier" class=3D"">variant_union</font> is only used with one argument, so =
maybe it=E2=80=99s overkill. The only class that would use its recursion is=
 <font face=3D"Courier" class=3D"">variant</font>. (On the other hand, it=
=E2=80=99s maybe useful for that <font face=3D"Courier" class=3D"">char</fo=
nt> member which could still be needed if the proposal does not remove the =
requirement that a constexpr union constructor must set an active member.)<=
/div><div class=3D""><br class=3D""></div><div class=3D"">I was suggesting =
to separate storage from initialization, so it would be more like this (jus=
t a draft, not compiled):</div><div class=3D""><br class=3D""></div><div cl=
ass=3D""><div class=3D""><font face=3D"Courier" class=3D"">// Indexed stora=
ge for members</font></div><div class=3D""><font face=3D"Courier" class=3D"=
">template&lt; std::size_t index, typename elem, typename =3D void &gt;</fo=
nt></div><div class=3D""><font face=3D"Courier" class=3D"">struct dumb_stor=
age_leaf {</font></div><div class=3D""><font face=3D"Courier" class=3D"">&n=
bsp; &nbsp; variant_union&lt; elem &gt; s;</font></div><div class=3D""><fon=
t face=3D"Courier" class=3D"">};</font></div></div><div class=3D""><font fa=
ce=3D"Courier" class=3D""><br class=3D""></font></div><div class=3D""><font=
 face=3D"Courier" class=3D"">// Store empty members as proper base subobjec=
ts in empty owners,&nbsp;canceling dumb storage.</font></div><div class=3D"=
"><div class=3D""><font face=3D"Courier" class=3D"">template&lt; std::size_=
t index, typename elem &gt;</font></div><div class=3D""><font face=3D"Couri=
er" class=3D"">struct dumb_storage_leaf&lt; index, elem, std::enable_if_t&l=
t; std::is_empy&lt; elem &gt;::value &gt; &gt;</font></div><div class=3D"">=
<font face=3D"Courier" class=3D"">&nbsp; &nbsp; {};</font></div><div class=
=3D""><font face=3D"Courier" class=3D""><br class=3D""></font></div><div cl=
ass=3D""><span style=3D"font-family: Courier;" class=3D"">// Find indexed d=
umb storage.</span></div></div><div class=3D""><font face=3D"Courier" class=
=3D"">template&lt; typename derived, std::size_t index, typename elem, type=
name =3D void &gt;</font></div><div class=3D""><font face=3D"Courier" class=
=3D"">struct empty_owner_access {</font></div><div class=3D""><font face=3D=
"Courier" class=3D"">&nbsp; &nbsp; elem &amp; get() {</font></div><div clas=
s=3D""><font face=3D"Courier" class=3D"">&nbsp; &nbsp; &nbsp; &nbsp; return=
 recover_cast&lt; elem &amp; &gt;(</font></div><div class=3D""><font face=
=3D"Courier" class=3D"">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; static_ca=
st&lt; dumb_storage_leaf&lt; index, elem &gt; &amp; &gt;(</font></div><div =
class=3D""><font face=3D"Courier" class=3D"">&nbsp; &nbsp; &nbsp; &nbsp; &n=
bsp; &nbsp; &nbsp; &nbsp; static_cast&lt; derived &amp; &gt;( * this )</fon=
t></div><div class=3D""><font face=3D"Courier" class=3D"">&nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; ).s</font></div><div class=3D""><font face=3D"Cour=
ier" class=3D"">&nbsp; &nbsp; &nbsp; &nbsp; );</font></div><div class=3D"">=
<font face=3D"Courier" class=3D"">&nbsp; &nbsp; }</font></div><div class=3D=
""><font face=3D"Courier" class=3D"">};</font></div><div class=3D""><font f=
ace=3D"Courier" class=3D""><br class=3D""></font></div><div class=3D""><fon=
t face=3D"Courier" class=3D"">// Find in-owner storage.</font></div><div cl=
ass=3D""><div class=3D""><font face=3D"Courier" class=3D"">template&lt; typ=
ename derived, std::size_t index, typename elem &gt;</font></div><div class=
=3D""><font face=3D"Courier" class=3D"">struct empty_owner_access&lt; deriv=
ed, index, elem, std::enable_if_t&lt; std::is_empy&lt; elem &gt;::value &gt=
; &gt;</font></div><div class=3D""><font face=3D"Courier" class=3D"">&nbsp;=
 &nbsp; : private elem</font></div><div class=3D""><font face=3D"Courier" c=
lass=3D"">&nbsp; &nbsp; { elem &amp; get() { return * this; } };</font></di=
v><div class=3D""><font face=3D"Courier" class=3D""><br class=3D""></font><=
/div><div class=3D""><font face=3D"Courier" class=3D"">// Take ownership an=
d construct/destroy the tuple element.</font></div><div class=3D""><div cla=
ss=3D""><font face=3D"Courier" class=3D"">template&lt; typename derived, st=
d::size_t index, typename elem &gt;</font></div></div></div><div class=3D""=
><font face=3D"Courier" class=3D"">struct empty_owner_leaf</font></div><div=
 class=3D""><font face=3D"Courier" class=3D"">&nbsp; &nbsp; : empty_owner_a=
ccess&lt; derived, index, elem &gt; {</font></div><div class=3D""><font fac=
e=3D"Courier" class=3D"">&nbsp; &nbsp; template&lt; typename ... arg &gt;</=
font></div><div class=3D""><font face=3D"Courier" class=3D"">&nbsp; &nbsp; =
empty_owner( arg &amp;&amp; ... a )</font></div><div class=3D""><font face=
=3D"Courier" class=3D"">&nbsp; &nbsp; &nbsp; &nbsp; { new( (void*) &amp; th=
is-&gt;get() ) elem( std::forward&lt; arg &gt;( a ) ... ); }</font></div><d=
iv class=3D""><font face=3D"Courier" class=3D""><br class=3D""></font></div=
><div class=3D""><font face=3D"Courier" class=3D"">&nbsp; &nbsp; ~ empty_ow=
ner()</font></div><div class=3D""><font face=3D"Courier" class=3D"">&nbsp; =
&nbsp; &nbsp; &nbsp; { this-&gt;get().elem:: ~ elem(); }</font></div><div c=
lass=3D""><font face=3D"Courier" class=3D"">};</font></div><div class=3D"">=
<br class=3D""></div><div class=3D""><font face=3D"Courier" class=3D"">temp=
late&lt; typename tuple, typename index &gt;</font></div><div class=3D""><f=
ont face=3D"Courier" class=3D"">struct tuple_impl;</font></div><div class=
=3D""><font face=3D"Courier" class=3D""><br class=3D""></font></div><div cl=
ass=3D""><font face=3D"Courier" class=3D"">template&lt; typename ... elem &=
gt;</font></div><div class=3D""><font face=3D"Courier" class=3D"">struct tu=
ple;</font></div><div class=3D""><font face=3D"Courier" class=3D""><br clas=
s=3D""></font></div><div class=3D""><font face=3D"Courier" class=3D"">// Co=
llect all the leaves in one base class list to maximize EBCO.</font></div><=
div class=3D""><font face=3D"Courier" class=3D"">template&lt; typename ... =
elem, std::size_t ... index &gt;</font></div><div class=3D""><font face=3D"=
Courier" class=3D"">struct tuple_impl&lt; tuple&lt; elem ... &gt;, std::ind=
ex_sequence&lt; index ... &gt; &gt;</font></div><div class=3D""><font face=
=3D"Courier" class=3D"">&nbsp; &nbsp; : optimally_pack_permute_bases&lt; du=
mb_storage_leaf&lt; index, elem &gt; ... &gt;</font></div><div class=3D""><=
font face=3D"Courier" class=3D"">&nbsp; &nbsp; , empty_owner_leaf&lt; tuple=
_impl&lt; tuple&lt; elem ... &gt;, std::index_sequence&lt; index ... &gt; &=
gt;, // CRTP</font></div><div class=3D""><font face=3D"Courier" class=3D"">=
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp;index, elem &gt; ...</font></div><div class=3D""><font face=
=3D"Courier" class=3D"">&nbsp; &nbsp; {};</font></div><div class=3D""><font=
 face=3D"Courier" class=3D""><br class=3D""></font></div><div class=3D""><f=
ont face=3D"Courier" class=3D"">template&lt; typename ... elem &gt;</font><=
/div><div class=3D""><font face=3D"Courier" class=3D"">struct tuple {</font=
></div><div class=3D""><font face=3D"Courier" class=3D"">&nbsp; &nbsp; tupl=
e_impl&lt; tuple, std::make_index_sequence&lt; sizeof ... (elem) &gt; &gt; =
impl;</font></div><div class=3D""><font face=3D"Courier" class=3D"">};</fon=
t></div><div class=3D""><br class=3D""></div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_FF9445FF-6A9F-421D-93EF-73D15680C40A--

.

On 08/31/2015 10:46 PM, David Krauss wrote:
[snip]
>
> =E2=80=94 The argument must be the address of an inactive union member of=
 the
> same type as the type-id given to new. The constexpr interpreter
> shouldn=E2=80=99t need to allow putting any object at any address within =
a buffer.
>
> The latter requirement seems to rule out variant, but it would be nice
> anyway if the language had some way to expand a pack into a union, such
> as inheritance.
>
Do you mean something like:

  template<typename... T>
  struct variant
  : union<T...> //*PROPOSED EXTENSION*
    //"inherits" storage "equivalent" to
    //std::aligned_union<T...>::type.
    //This is *maybe* the "expand into a union,
    //such as inheritance" suggested by
    //David Krauss above.
  {
      std::size_t
    which
      //run-time value indicating which of the
      //T's is currently "active" in
      //union<T...>
      ;
  };

?

-regards,
Larry


--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

> On 2015=E2=80=9309=E2=80=9306, at 2:51 AM, Larry Evans <cppljevans@sudden=
link.net> wrote:
>=20
> On 08/31/2015 10:46 PM, David Krauss wrote:
> [snip]
>>=20
>> =E2=80=94 The argument must be the address of an inactive union member o=
f the
>> same type as the type-id given to new. The constexpr interpreter
>> shouldn=E2=80=99t need to allow putting any object at any address within=
 a buffer.
>>=20
>> The latter requirement seems to rule out variant, but it would be nice
>> anyway if the language had some way to expand a pack into a union, such
>> as inheritance.
>>=20
> Do you mean something like:
>=20
>  template<typename... T>
>  struct variant
>  : union<T...> //*PROPOSED EXTENSION*

The proposed extension in this thread is constexpr placement new, not varia=
dic unions or union inheritance. It looks like the union problem is already=
 solved using TMP. See the last few posts.

It=E2=80=99s not clear that it=E2=80=99s allowed to change the active union=
 member by performing a member access expression on an inactive member, and=
 then using placement new on the result of that access expression. Even out=
side a constexpr context that doesn=E2=80=99t seem to abide by the current =
rules. However, current lifetime rules often don=E2=80=99t work and I don=
=E2=80=99t imagine any implementation balking at K-ballo=E2=80=99s usage.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On 9/5/2015 8:47 PM, David Krauss wrote:
>
>> On 2015=E2=80=9309=E2=80=9306, at 2:51 AM, Larry Evans <cppljevans@sudde=
nlink.net> wrote:
>> Do you mean something like:
>>
>>   template<typename... T>
>>   struct variant
>>   : union<T...> //*PROPOSED EXTENSION*
>
> The proposed extension in this thread is constexpr placement new, not var=
iadic unions or union inheritance. It looks like the union problem is alrea=
dy solved using TMP. See the last few posts.
>
> It=E2=80=99s not clear that it=E2=80=99s allowed to change the active uni=
on member by performing a member access expression on an inactive member, a=
nd then using placement new on the result of that access expression. Even o=
utside a constexpr context that doesn=E2=80=99t seem to abide by the curren=
t rules. However, current lifetime rules often don=E2=80=99t work and I don=
=E2=80=99t imagine any implementation balking at K-ballo=E2=80=99s usage.

Taking the address of an inactive member of a union is allowed.=20
Switching the active member of a union via placement new is the way it=20
is depicted in the standard since relaxed unions. 9.5 [class.union]/4:

[Note: In general, one must use explicit destructor calls and placement=20
new operators to change the active member of a union. =E2=80=94 end note]=
=20
[Example: Consider an object u of a union type U having non-static data=20
members m of type M and n of type N. If M has a  non-trivial destructor=20
and N has a non-trivial constructor (for instance, if they declare or=20
inherit virtual functions), the active member of u can be safely=20
switched from m to n using the destructor and placement new operator as=20
follows:

     u.m.~M();
     new (&u.n) N;

=E2=80=94 end example]

Regards,
--=20
Agust=C3=ADn K-ballo Berg=C3=A9.-
http://talesofcpp.fusionfenix.com

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

> On 2015=E2=80=9309=E2=80=9306, at 11:01 PM, Agust=C3=ADn K-ballo Berg=C3=
=A9 <kaballo86@hotmail.com> wrote:
>=20
> Taking the address of an inactive member of a union is allowed. Switching=
 the active member of a union via placement new is the way it is depicted i=
n the standard since relaxed unions. 9.5 [class.union]/4:

The main problem is that using placement new to create a nested subobject u=
nion doesn=E2=80=99t start the lifetime of the super-unions or structs up t=
he chain.

It would be kosher to use in-place construction at the top level and bring =
the constructor arguments through the nesting by perfect forwarding, but th=
at would lose some generality, it would involve a lot more templates, and i=
t would be a pain.

IMHO a good approach is to start hacking the compiler first, find a model w=
here constexpr variant works, and then make the lifetime rules fit. Far as =
I=E2=80=99ve seen, discussion about ambiguous lifetimes is ongoing but not =
making much headway. Nailing down what=E2=80=99s tolerable for the constexp=
r interpreter could provide some useful direction.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On 09/03/2015 08:27 PM, David Krauss wrote:
[snip]
> I was suggesting to separate storage from initialization, so it would be
> more like this (just a draft, not compiled):
>
> // Indexed storage for members
> template< std::size_t index, typename elem, typename = void >
> struct dumb_storage_leaf {
>     variant_union< elem > s;
> };
[snip]

David, I know it's just a draft, but I just thought I'd
warn people who might want to try the code that,
after slight modification to allow compilation without
instantiation, and then adding an instantiation of
tuple<int,int> in the main of code located here:

https://gist.github.com/cppljevans/c074fef51b1caf702fc5

I got compile errors with clang3.6:

tuple.krauss.cpp:147:14: error: member 'get' found in multiple base
classes of different types
  return tii.get<0>();
             ^
tuple.krauss.cpp:85:10: note: member found by ambiguous name lookup
  elem & get() {
         ^
tuple.krauss.cpp:85:10: note: member found by ambiguous name lookup
tuple.krauss.cpp:147:21: error: expected expression
  return tii.get<0>();
                    ^
..
..
..

Similar errors happened with gcc5.2.0.

I will try and correct these.

-regards,
Larry


--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--Apple-Mail=_B5AFE1BA-712C-4409-8670-5C19175B7A5C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9309=E2=80=9307, at 11:58 PM, Larry Evans <cppljevans@sudde=
nlink.net> wrote:
>=20
> I got compile errors with clang3.6:
>=20
> tuple.krauss.cpp:147:14: error: member 'get' found in multiple base
> classes of different types
>  return tii.get<0>();
>             ^

The problem is that I didn=E2=80=99t show any actual public accessor. The g=
et() member is just an implementation detail internal to the individual lea=
ves. Note that it=E2=80=99s not a template :P

> I will try and correct these.

Appreciate the effort. Let=E2=80=99s take development effort off this maili=
ng list, though.

Also, just to be clear, it all won=E2=80=99t do anything really interesting=
 until you plug in a useful optimally_pack_permute_bases metafunction.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_B5AFE1BA-712C-4409-8670-5C19175B7A5C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9309=
=E2=80=9307, at 11:58 PM, Larry Evans &lt;<a href=3D"mailto:cppljevans@sudd=
enlink.net" class=3D"">cppljevans@suddenlink.net</a>&gt; wrote:</div><br cl=
ass=3D"Apple-interchange-newline"><div class=3D"">I got compile errors with=
 clang3.6:<br class=3D""><br class=3D"">tuple.krauss.cpp:147:14: error: mem=
ber 'get' found in multiple base<br class=3D"">classes of different types<b=
r class=3D""> &nbsp;return tii.get&lt;0&gt;();<br class=3D""> &nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;^<br class=3D"">=
</div></blockquote><div><br class=3D""></div><div>The problem is that I did=
n=E2=80=99t show any actual public accessor. The <font face=3D"Courier" cla=
ss=3D"">get()</font> member is just an implementation detail internal to th=
e individual leaves. Note that it=E2=80=99s not a template :P</div><br clas=
s=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">I will try and =
correct these.<br class=3D""></div></blockquote></div><br class=3D""><div c=
lass=3D"">Appreciate the effort. Let=E2=80=99s take development effort off =
this mailing list, though.</div><div class=3D""><br class=3D""></div><div c=
lass=3D"">Also, just to be clear, it all won=E2=80=99t do anything really i=
nteresting until you plug in a useful&nbsp;<span style=3D"font-family: Cour=
ier;" class=3D"">optimally_pack_permute_bases</span>&nbsp;metafunction.</di=
v><div class=3D""><br class=3D""></div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_B5AFE1BA-712C-4409-8670-5C19175B7A5C--

.