------=_Part_1205_658107212.1533516598812
Content-Type: multipart/alternative;
 boundary="----=_Part_1206_1364071779.1533516598812"

------=_Part_1206_1364071779.1533516598812
Content-Type: text/plain; charset="UTF-8"

A major feature that is available with boost::variant but not with
std::variant is the ability to define recursive variant types.  Is there
some technical reason why this feature was left out of std:::variant or was
it just left out to keep the standardese from getting even more
complicated? How difficult would it be to add recursive variants to C++23
(I assume it is too late for C++20).  It would be incredibly useful; for
instance a recursive variant type could be used to define a JSON object
type.

Joe Gottman

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/646b808b-4559-4132-930f-d7b05400e575%40isocpp.org.

------=_Part_1206_1364071779.1533516598812
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">A major feature that is available with boost::variant but =
not with std::variant is the ability to define recursive variant types.=C2=
=A0 Is there some technical reason why this feature was left out of std:::v=
ariant or was it just left out to keep the standardese from getting even mo=
re complicated? How difficult would it be to add recursive variants to C++2=
3 (I assume it is too late for C++20).=C2=A0 It would be incredibly useful;=
 for instance a recursive variant type could be used to define a JSON objec=
t type.<div><br></div><div>Joe Gottman</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/646b808b-4559-4132-930f-d7b05400e575%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/646b808b-4559-4132-930f-d7b05400e575=
%40isocpp.org</a>.<br />

------=_Part_1206_1364071779.1533516598812--

------=_Part_1205_658107212.1533516598812--

.

--0000000000001142450572baa98e
Content-Type: text/plain; charset="UTF-8"

On Sun, Aug 5, 2018, 20:50 <jgottman6@gmail.com> wrote:

> A major feature that is available with boost::variant but not with
> std::variant is the ability to define recursive variant types.  Is there
> some technical reason why this feature was left out of std:::variant or was
> it just left out to keep the standardese from getting even more complicated?
>

The latter. It just wasn't a part of the proposal and variant already was
considerably complicated and controversial. It's possible that the standard
may get something like boost::recursive_wrapper, but I suspect the
most-likely solution is that we will instead get the std::polymorphic_value
proposal, which is possible to be specified in a way that would allow an
incomplete type, meaning that you could use it as a way to get the
equivalent of what boost::recursive_wrapper provides, including proper
value semantics, without variant needing to have intrusive knowledge of
such a facility. Your alternative_type would of course then be
polymorphic_wrapper<T> instead of T, but I think that's reasonable.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DE%3DtToj72%3DUVvQDQ8cPvUk%2Bh9gbQ051XCuth3GNs0RcRbg%40mail.gmail.com.

--0000000000001142450572baa98e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">=
On Sun, Aug 5, 2018, 20:50  &lt;<a href=3D"mailto:jgottman6@gmail.com">jgot=
tman6@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr">A major feature that is available with boost::variant but not =
with std::variant is the ability to define recursive variant types.=C2=A0 I=
s there some technical reason why this feature was left out of std:::varian=
t or was it just left out to keep the standardese from getting even more co=
mplicated?</div></blockquote></div></div><div dir=3D"auto"><br></div><div d=
ir=3D"auto">The latter. It just wasn&#39;t a part of the proposal and varia=
nt already was considerably complicated and controversial. It&#39;s possibl=
e that the standard may get something like boost::recursive_wrapper, but I =
suspect the most-likely solution is that we will instead get the std::polym=
orphic_value proposal, which is possible to be specified in a way that woul=
d allow an incomplete type, meaning that you could use it as a way to get t=
he equivalent of what boost::recursive_wrapper provides, including proper v=
alue semantics, without variant needing to have intrusive knowledge of such=
 a facility. Your alternative_type would of course then be polymorphic_wrap=
per&lt;T&gt; instead of T, but I think that&#39;s reasonable.</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANh8DE%3DtToj72%3DUVvQDQ8cPvUk%2Bh9g=
bQ051XCuth3GNs0RcRbg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DE%3Dt=
Toj72%3DUVvQDQ8cPvUk%2Bh9gbQ051XCuth3GNs0RcRbg%40mail.gmail.com</a>.<br />

--0000000000001142450572baa98e--

.

--000000000000d863b30572baafac
Content-Type: text/plain; charset="UTF-8"

On Sun, Aug 5, 2018, 22:01 Matt Calabrese <calabrese@google.com> wrote:

> Your alternative_type would of course then be polymorphic_wrapper<T>
>> instead of T, but I think that's reasonable.
>>
>
Sorry, should read "polymorphic_value<T>".

>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEk5jvdo3ofB5pt%3DYjKZd4%2B%3DWtDwieKZrQJuXL9TYmO1QQ%40mail.gmail.com.

--000000000000d863b30572baafac
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><br><br><div class=3D"gmail_quote" dir=3D"auto"><div dir=
=3D"ltr">On Sun, Aug 5, 2018, 22:01 Matt Calabrese &lt;<a href=3D"mailto:ca=
labrese@google.com">calabrese@google.com</a>&gt; wrote:</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"auto"><div><div class=3D"gmail_quote"><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr">Your alternative_type would of cour=
se then be polymorphic_wrapper&lt;T&gt; instead of T, but I think that&#39;=
s reasonable.<br></div></blockquote></div></div></div></blockquote></div><d=
iv dir=3D"auto"><br></div><div dir=3D"auto">Sorry, should read &quot;polymo=
rphic_value&lt;T&gt;&quot;.</div><div class=3D"gmail_quote" dir=3D"auto"><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"auto"><div><div class=3D"gmail_quo=
te"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"></div></blockquote></di=
v></div></div>
</blockquote></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANh8DEk5jvdo3ofB5pt%3DYjKZd4%2B%3DWt=
DwieKZrQJuXL9TYmO1QQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEk5jv=
do3ofB5pt%3DYjKZd4%2B%3DWtDwieKZrQJuXL9TYmO1QQ%40mail.gmail.com</a>.<br />

--000000000000d863b30572baafac--

.

This is a multi-part message in MIME format.

--b1_296d741764f462aabb4c61a60ae25a72
Content-Type: text/plain; charset="UTF-8"

The demand for recursive variant support should be to
use the recursive_element<E> in a way indistinguishable
from E; hence that this special type must receive special
treatment inside variant.  If ` polymorphic_value<T>` is
acceptable then `unique_ptr<T>` is also acceptable.

(In my own copy of `variant` I used `T[]` to indicate a
recursive element:
https://github.com/lichray/oneof/blob/master/include/stdex/oneof.h#L389-L403)

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________

From: 'Matt Calabrese' via ISO C++ Standard - Future Proposals <std-proposals@isocpp.org>
Sent: Sunday, August 5, 2018 9:04 PM

On Sun, Aug 5, 2018, 22:01 Matt Calabrese <calabrese@google.com> wrote:

>> Your alternative_type would of course then be polymorphic_wrapper<T> instead of T, but I think that's reasonable.

Sorry, should read "polymorphic_value<T>".

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7frdea6q9-AcMUFr1GNUxexALUWi87CUjA3bl_59qZOjhRsXOpy3AoHkF4z2A6yPVmsSNNkOfB2SVDeFirZp5yGZ2luH20Pz4LZr3-lutQc%3D%40miator.net.

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

<html><head></head><body><div class=3D"WordSection1"><p class=3D"MsoNormal"=
>The demand for recursive variant support should be to<br/>use the recursiv=
e_element&lt;E&gt; in a way indistinguishable<br/>from E; hence that this s=
pecial type must receive special<br/>treatment inside variant.=C2=A0 If ` p=
olymorphic_value&lt;T&gt;` is<br/>acceptable then `unique_ptr&lt;T&gt;` is =
also acceptable.<br/><br/>(In my own copy of `variant` I used `T[]` to indi=
cate a<br/>recursive element:<br/>https://github.com/lichray/oneof/blob/mas=
ter/include/stdex/oneof.h#L389-L403)<o:p></o:p></p><p class=3D"MsoNormal"><=
o:p>=C2=A0</o:p></p><p class=3D"MsoNormal">--<br/>Zhihao Yuan, ID lichray<b=
r/>The best way to predict the future is to invent it.<br/>________________=
_______________________________<o:p></o:p></p><p class=3D"MsoNormal"><o:p>=
=C2=A0</o:p></p><div style=3D"border:none;border-left:solid blue 1.5pt;padd=
ing:0in 0in 0in 4.0pt"><p class=3D"MsoNormal"><b>From:</b> &#39;Matt Calabr=
ese&#39; via ISO C++ Standard - Future Proposals &lt;std-proposals@isocpp.o=
rg&gt; <br/><b>Sent:</b> Sunday, August 5, 2018 9:04 PM<o:p></o:p></p><p cl=
ass=3D"MsoNormal"><o:p>=C2=A0</o:p></p><div><div><div><p class=3D"MsoNormal=
">On Sun, Aug 5, 2018, 22:01 Matt Calabrese &lt;<a href=3D"mailto:calabrese=
@google.com">calabrese@google.com</a>&gt; wrote:<o:p></o:p></p></div><block=
quote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in =
0in 6.0pt;margin-left:4.8pt;margin-right:0in"><div><div><div><blockquote st=
yle=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0p=
t;margin-left:4.8pt;margin-right:0in"><div><p class=3D"MsoNormal">Your alte=
rnative_type would of course then be polymorphic_wrapper&lt;T&gt; instead o=
f T, but I think that&#39;s reasonable.<o:p></o:p></p></div></blockquote></=
div></div></div></blockquote></div><div><p class=3D"MsoNormal"><o:p>=C2=A0<=
/o:p></p></div><div><p class=3D"MsoNormal">Sorry, should read &#34;polymorp=
hic_value&lt;T&gt;&#34;.<o:p></o:p></p></div></div></div></div></body></htm=
l>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7frdea6q9-AcMUFr1GNUxexALUWi87CUjA3bl=
_59qZOjhRsXOpy3AoHkF4z2A6yPVmsSNNkOfB2SVDeFirZp5yGZ2luH20Pz4LZr3-lutQc%3D%4=
0miator.net?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7frdea6q9-AcMUFr1GNUxexALUWi87CUjA3bl=
_59qZOjhRsXOpy3AoHkF4z2A6yPVmsSNNkOfB2SVDeFirZp5yGZ2luH20Pz4LZr3-lutQc%3D%4=
0miator.net</a>.<br />

--b1_296d741764f462aabb4c61a60ae25a72--


.

--000000000000f52bfc0572c57fba
Content-Type: text/plain; charset="UTF-8"

On Sun, Aug 5, 2018 at 11:53 PM Zhihao Yuan <zy@miator.net> wrote:

> The demand for recursive variant support should be to
> use the recursive_element<E> in a way indistinguishable
> from E; hence that this special type must receive special
> treatment inside variant.
>

Using something like std::polymorphic_value would imply that the
corresponding alternative_type is polymorphic_value<T> as opposed to T,
yes, but I do not believe that it is a requirement to present the
alternative type as T directly for such a recursive variant to be useful.
That is only a convenience, and it is a convenience that implies trade-offs.

Without an updated design, I also suspect that a solution that is close to
boost::recursive_wrapper is currently ill-suited for standardization as-is,
and I say that as a frequent user of recursive boost::variants and also as
an implementer of std::variant and other variant types (similar to your
experiences). The aspects that I think make it difficult to standardize are
that it is intrusive to variant, adding complexity and special-casing
including, notably, how to control the allocation. Would it always directly
use "new"? Would the hypothetical std::recursive_element<T> have a
defaulted second Allocator parameter (if so, how would the user pass an
allocator instance in without variant having further special-casing for
forwarding it along to the implementation when std::recursive_element<E> is
used). Using something like std::polymorphic_value, on the other hand,
requires no special casing, and is "less risky" in the sense that the way
to get the recursive behavior remains not intrinsic to the variant template
itself (people can use whichever indirection technique best suits their
needs). While it is true that you could do this whether or not something
like boost::recursive_wrapper exists, it would be disappointing if we
standardized something that adds complexity to the specification,
implementation, and use of variant that people may potentially avoid anyway.

If the committee finds enough benefit from all of this as opposed to just
using facilities like polymorphic_value, then we certainly will pursue it
-- again, I also use boost::recursive_wrapper -- but I suspect that it will
be controversial and difficult to standardize, and if we do get it, it will
either be after standardization of something like std::polymorphic_value or
at the very least, the same time as std::polymorphic_value. I don't believe
we yet have an implementation in the wild of a recursive_wrapper in a form
that both has considerable usage experience and that would make it through
standardization (that includes both boost::recursive_wrapper and your
approach). I'd be especially disappointed if we tried to design a fitting
solution for something like this in committee.

My personal thoughts for the best route forward is for us to reassess
if/when std::polymorphic_value happens -- assuming that we guarantee that
it can be instantiated with an incomplete T. It may just be that instead of
special-casing variant for a recursive_wrapper type, we may simply want a
function object adaptor that perfect-forwards all types except for
polymorphic_value, which it would unwrap before perfect-forwarding to the
user's lambda, or something similarly non-intrusive to variant itself. One
downside is that polymorphic_value does not provide comparisons, and I
suspect that the author would not want it to take on such operations due to
its intended usage with inheritance. Still, I strongly believe that it'd be
best to put our efforts towards a solution of that ilk, rather than being
intrusive to variant itself.


On Sun, Aug 5, 2018 at 11:53 PM Zhihao Yuan <zy@miator.net> wrote:

>   If ` polymorphic_value<T>` is
> acceptable then `unique_ptr<T>` is also acceptable.
>

One big drawback here for a unique_ptr is that it does not have value
semantics with respect to T. Putting a unique_ptr<T> in a variant means
that it is move-only and also that the comparison operators compile fine,
yet compare pointer values rather than the instances of T. The benefit of
polymorphic_value<T> is that when you have it as an alternative_type of
your variant, your variant's copy operations all work as they should, as-if
the object were logically contained (because it is).

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEmT6oebbVcfk6eJ%3DJ5ajnhQcUfF%3D1RKOeazLVbfX0k%2Bag%40mail.gmail.com.

--000000000000f52bfc0572c57fba
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Sun, Aug 5,=
 2018 at 11:53 PM Zhihao Yuan &lt;<a href=3D"mailto:zy@miator.net">zy@miato=
r.net</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div clas=
s=3D"m_6791930801678542753WordSection1"><p class=3D"MsoNormal">The demand f=
or recursive variant support should be to<br>use the recursive_element&lt;E=
&gt; in a way indistinguishable<br>from E; hence that this special type mus=
t receive special<br>treatment inside variant.=C2=A0</p></div></div></block=
quote><div><br class=3D"gmail-Apple-interchange-newline"><span style=3D"fon=
t-size:small;background-color:rgb(255,255,255);text-decoration-style:initia=
l;text-decoration-color:initial;float:none;display:inline">Using something =
like std::polymorphic_value would imply that the corresponding alternative_=
type is polymorphic_value&lt;T&gt; as opposed to T, yes, but I do not belie=
ve that it is a requirement to present the alternative type as T directly f=
or such a recursive variant to be useful. That is only a convenience, and i=
t is a convenience that implies trade-offs.</span></div><div><span style=3D=
"font-size:small;background-color:rgb(255,255,255);text-decoration-style:in=
itial;text-decoration-color:initial;float:none;display:inline"><br></span><=
/div><div>Without an updated design, I also suspect that a solution that is=
 close to boost::recursive_wrapper is currently ill-suited for standardizat=
ion as-is, and I say that as a frequent user of recursive boost::variants a=
nd also as an implementer of std::variant and other variant types (similar =
to your experiences). The aspects that I think make it difficult to standar=
dize are that it is intrusive to variant, adding complexity and special-cas=
ing including, notably, how to control the allocation. Would it always dire=
ctly use &quot;new&quot;? Would the hypothetical std::recursive_element&lt;=
T&gt; have a defaulted second Allocator parameter (if so, how would the use=
r pass an allocator instance in without variant having further special-casi=
ng for forwarding it along to the implementation when std::recursive_elemen=
t&lt;E&gt; is used). Using something like std::polymorphic_value, on the ot=
her hand, requires no special casing, and is &quot;less risky&quot; in the =
sense that the way to get the recursive behavior remains not intrinsic to t=
he variant template itself (people can use whichever indirection technique =
best suits their needs). While it is true that you could do this whether or=
 not something like boost::recursive_wrapper exists, it would be disappoint=
ing if we standardized something that adds complexity to the specification,=
 implementation, and use of variant that people may potentially avoid anywa=
y.</div><div><br></div><div>If the committee finds enough benefit from all =
of this as opposed to just using facilities like polymorphic_value, then we=
 certainly will pursue it -- again, I also use boost::recursive_wrapper -- =
but I suspect that it will be controversial and difficult to standardize, a=
nd if we do get it, it will either be after standardization of something li=
ke std::polymorphic_value or at the very least, the same time as std::polym=
orphic_value. <span style=3D"font-size:small;background-color:rgb(255,255,2=
55);text-decoration-style:initial;text-decoration-color:initial;float:none;=
display:inline">I don&#39;t believe we yet have an implementation in the wi=
ld of a recursive_wrapper in a form that both has considerable usage experi=
ence and that would make it through standardization (that includes both boo=
st::recursive_wrapper and your approach). I&#39;d be especially disappointe=
d if we tried to design a fitting solution for something like this in commi=
ttee.</span></div><div><span style=3D"font-size:small;background-color:rgb(=
255,255,255);text-decoration-style:initial;text-decoration-color:initial;fl=
oat:none;display:inline"><br></span></div><div><span style=3D"font-size:sma=
ll;background-color:rgb(255,255,255);text-decoration-style:initial;text-dec=
oration-color:initial;float:none;display:inline">My personal thoughts for t=
he best route forward is for us to reassess if/when std::polymorphic_value =
happens -- assuming that we guarantee that it can be instantiated with an i=
ncomplete T. It may just be that instead of special-casing variant for a re=
cursive_wrapper type, we may simply want a function object adaptor that per=
fect-forwards all types except for polymorphic_value, which it would unwrap=
 before perfect-forwarding to the user&#39;s lambda, or something similarly=
 non-intrusive to variant itself. One downside is that polymorphic_value do=
es not provide comparisons, and I suspect that the author would not want it=
 to take on such operations due to its intended usage with inheritance. Sti=
ll, I strongly believe that it&#39;d be best to put our efforts towards a s=
olution of that ilk, rather than being intrusive to variant itself.</span><=
/div><div><br></div><div><br></div><div><span style=3D"font-size:small;back=
ground-color:rgb(255,255,255);text-decoration-style:initial;text-decoration=
-color:initial;float:none;display:inline">On Sun, Aug 5, 2018 at 11:53 PM Z=
hihao Yuan &lt;<a href=3D"mailto:zy@miator.net">zy@miator.net</a>&gt; wrote=
:</span>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"m_679=
1930801678542753WordSection1"><p class=3D"MsoNormal">=C2=A0 If ` polymorphi=
c_value&lt;T&gt;` is<br>acceptable then `unique_ptr&lt;T&gt;` is also accep=
table.<br></p></div></div></blockquote><div><br></div><div>One big drawback=
 here for a unique_ptr is that it does not have value semantics with respec=
t to T. Putting a unique_ptr&lt;T&gt; in a variant means that it is move-on=
ly and also that the comparison operators compile fine, yet compare pointer=
 values rather than the instances of T. The benefit of polymorphic_value&lt=
;T&gt; is that when you have it as an alternative_type of your variant, you=
r variant&#39;s copy operations all work as they should, as-if the object w=
ere logically contained (because it is).</div></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANh8DEmT6oebbVcfk6eJ%3DJ5ajnhQcUfF%3=
D1RKOeazLVbfX0k%2Bag%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEmT6o=
ebbVcfk6eJ%3DJ5ajnhQcUfF%3D1RKOeazLVbfX0k%2Bag%40mail.gmail.com</a>.<br />

--000000000000f52bfc0572c57fba--

.

--00000000000055fe390572c5c15b
Content-Type: text/plain; charset="UTF-8"

On Mon, 6 Aug 2018 at 15:57, 'Matt Calabrese' via ISO C++ Standard - Future
Proposals <std-proposals@isocpp.org> wrote:

> On Sun, Aug 5, 2018 at 11:53 PM Zhihao Yuan <zy@miator.net> wrote:
>
>> The demand for recursive variant support should be to
>> use the recursive_element<E> in a way indistinguishable
>> from E; hence that this special type must receive special
>> treatment inside variant.
>>
>
> Using something like std::polymorphic_value would imply that the
> corresponding alternative_type is polymorphic_value<T> as opposed to T,
> yes, but I do not believe that it is a requirement to present the
> alternative type as T directly for such a recursive variant to be useful.
> That is only a convenience, and it is a convenience that implies trade-offs.
>
> Without an updated design, I also suspect that a solution that is close to
> boost::recursive_wrapper is currently ill-suited for standardization as-is,
> and I say that as a frequent user of recursive boost::variants and also as
> an implementer of std::variant and other variant types (similar to your
> experiences). The aspects that I think make it difficult to standardize are
> that it is intrusive to variant, adding complexity and special-casing
> including, notably, how to control the allocation. Would it always directly
> use "new"?
>

Every large c++ project I have worked on in the past 10 years involved a
recursive variant. In none of those projects was whether 'new' was called
or not even the slightest concern.

The fact that recursive variants could model nested structures was so
useful that 'performance' was simply not relevant. Let's face it, without
entering into one's own pointless engineering exercise, boost::variant is
the only sensible choice in such circumstances.

If we really must control allocation, can't this be done with a
specialisation of std::variant_allocator_traits<> or somesuch. Is the
<Alloc> paradigm so perfect that it must be set in stone to the detriment
of the utility of an otherwise game-changing data structure?

At present, std::variant<> is so limited in application that the de-facto
standard remains - as is too often the case in recent std-library additions
- boost.


> Would the hypothetical std::recursive_element<T> have a defaulted second
> Allocator parameter (if so, how would the user pass an allocator instance
> in without variant having further special-casing for forwarding it along to
> the implementation when std::recursive_element<E> is used). Using something
> like std::polymorphic_value, on the other hand, requires no special casing,
> and is "less risky" in the sense that the way to get the recursive behavior
> remains not intrinsic to the variant template itself (people can use
> whichever indirection technique best suits their needs). While it is true
> that you could do this whether or not something like
> boost::recursive_wrapper exists, it would be disappointing if we
> standardized something that adds complexity to the specification,
> implementation, and use of variant that people may potentially avoid anyway.
>
> If the committee finds enough benefit from all of this as opposed to just
> using facilities like polymorphic_value, then we certainly will pursue it
> -- again, I also use boost::recursive_wrapper -- but I suspect that it will
> be controversial and difficult to standardize, and if we do get it, it will
> either be after standardization of something like std::polymorphic_value or
> at the very least, the same time as std::polymorphic_value. I don't
> believe we yet have an implementation in the wild of a recursive_wrapper in
> a form that both has considerable usage experience and that would make it
> through standardization (that includes both boost::recursive_wrapper and
> your approach). I'd be especially disappointed if we tried to design a
> fitting solution for something like this in committee.
>
> My personal thoughts for the best route forward is for us to reassess
> if/when std::polymorphic_value happens -- assuming that we guarantee that
> it can be instantiated with an incomplete T. It may just be that instead of
> special-casing variant for a recursive_wrapper type, we may simply want a
> function object adaptor that perfect-forwards all types except for
> polymorphic_value, which it would unwrap before perfect-forwarding to the
> user's lambda, or something similarly non-intrusive to variant itself. One
> downside is that polymorphic_value does not provide comparisons, and I
> suspect that the author would not want it to take on such operations due to
> its intended usage with inheritance. Still, I strongly believe that it'd be
> best to put our efforts towards a solution of that ilk, rather than being
> intrusive to variant itself.
>
>
> On Sun, Aug 5, 2018 at 11:53 PM Zhihao Yuan <zy@miator.net> wrote:
>
>>   If ` polymorphic_value<T>` is
>> acceptable then `unique_ptr<T>` is also acceptable.
>>
>
> One big drawback here for a unique_ptr is that it does not have value
> semantics with respect to T. Putting a unique_ptr<T> in a variant means
> that it is move-only and also that the comparison operators compile fine,
> yet compare pointer values rather than the instances of T. The benefit of
> polymorphic_value<T> is that when you have it as an alternative_type of
> your variant, your variant's copy operations all work as they should, as-if
> the object were logically contained (because it is).
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEmT6oebbVcfk6eJ%3DJ5ajnhQcUfF%3D1RKOeazLVbfX0k%2Bag%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEmT6oebbVcfk6eJ%3DJ5ajnhQcUfF%3D1RKOeazLVbfX0k%2Bag%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hbB4Am_UBje79gTEE2_XOELEhFDF2YjKGvOO2t%2B_N%3D9BA%40mail.gmail.com.

--00000000000055fe390572c5c15b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon=
, 6 Aug 2018 at 15:57, &#39;Matt Calabrese&#39; via ISO C++ Standard - Futu=
re Proposals &lt;<a href=3D"mailto:std-proposals@isocpp.org">std-proposals@=
isocpp.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Sun, Aug 5, 2018 at=
 11:53 PM Zhihao Yuan &lt;<a href=3D"mailto:zy@miator.net" target=3D"_blank=
">zy@miator.net</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
><div class=3D"m_-6055248831761763408m_6791930801678542753WordSection1"><p =
class=3D"MsoNormal">The demand for recursive variant support should be to<b=
r>use the recursive_element&lt;E&gt; in a way indistinguishable<br>from E; =
hence that this special type must receive special<br>treatment inside varia=
nt.=C2=A0</p></div></div></blockquote><div><br class=3D"m_-6055248831761763=
408gmail-Apple-interchange-newline"><span style=3D"font-size:small;backgrou=
nd-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-col=
or:initial;float:none;display:inline">Using something like std::polymorphic=
_value would imply that the corresponding alternative_type is polymorphic_v=
alue&lt;T&gt; as opposed to T, yes, but I do not believe that it is a requi=
rement to present the alternative type as T directly for such a recursive v=
ariant to be useful. That is only a convenience, and it is a convenience th=
at implies trade-offs.</span></div><div><span style=3D"font-size:small;back=
ground-color:rgb(255,255,255);text-decoration-style:initial;text-decoration=
-color:initial;float:none;display:inline"><br></span></div><div>Without an =
updated design, I also suspect that a solution that is close to boost::recu=
rsive_wrapper is currently ill-suited for standardization as-is, and I say =
that as a frequent user of recursive boost::variants and also as an impleme=
nter of std::variant and other variant types (similar to your experiences).=
 The aspects that I think make it difficult to standardize are that it is i=
ntrusive to variant, adding complexity and special-casing including, notabl=
y, how to control the allocation. Would it always directly use &quot;new&qu=
ot;? </div></div></div></blockquote><div><br></div><div>Every large c++ pro=
ject I have worked on in the past 10 years involved a recursive <font face=
=3D"arial, helvetica, sans-serif">variant</font>. In none of those projects=
 was whether &#39;<font face=3D"monospace, monospace">new</font>&#39; was c=
alled or not even the slightest concern.</div><div><br></div><div>The fact =
that recursive variants could model nested structures was so useful that &#=
39;performance&#39; was simply not relevant. Let&#39;s face it, without ent=
ering into one&#39;s own pointless engineering exercise, <font face=3D"mono=
space, monospace">boost::variant</font> is the only sensible choice in such=
 circumstances.</div><div><br></div><div>If we really must control allocati=
on, can&#39;t this be done with a specialisation of <font face=3D"monospace=
, monospace">std::variant_allocator_traits&lt;&gt;</font> or somesuch. Is t=
he <font face=3D"monospace, monospace">&lt;Alloc&gt;</font> paradigm so per=
fect that it must be set in stone to the detriment of the utility of an oth=
erwise game-changing data structure?</div><div><br></div><div>At present, <=
font face=3D"monospace, monospace">std::variant&lt;&gt;</font> is so limite=
d in application that the de-facto standard remains - as is too often the c=
ase in recent std-library additions - boost.</div><div>=C2=A0<br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div=
>Would the hypothetical std::recursive_element&lt;T&gt; have a defaulted se=
cond Allocator parameter (if so, how would the user pass an allocator insta=
nce in without variant having further special-casing for forwarding it alon=
g to the implementation when std::recursive_element&lt;E&gt; is used). Usin=
g something like std::polymorphic_value, on the other hand, requires no spe=
cial casing, and is &quot;less risky&quot; in the sense that the way to get=
 the recursive behavior remains not intrinsic to the variant template itsel=
f (people can use whichever indirection technique best suits their needs). =
While it is true that you could do this whether or not something like boost=
::recursive_wrapper exists, it would be disappointing if we standardized so=
mething that adds complexity to the specification, implementation, and use =
of variant that people may potentially avoid anyway.</div><div><br></div><d=
iv>If the committee finds enough benefit from all of this as opposed to jus=
t using facilities like polymorphic_value, then we certainly will pursue it=
 -- again, I also use boost::recursive_wrapper -- but I suspect that it wil=
l be controversial and difficult to standardize, and if we do get it, it wi=
ll either be after standardization of something like std::polymorphic_value=
 or at the very least, the same time as std::polymorphic_value. <span style=
=3D"font-size:small;background-color:rgb(255,255,255);text-decoration-style=
:initial;text-decoration-color:initial;float:none;display:inline">I don&#39=
;t believe we yet have an implementation in the wild of a recursive_wrapper=
 in a form that both has considerable usage experience and that would make =
it through standardization (that includes both boost::recursive_wrapper and=
 your approach). I&#39;d be especially disappointed if we tried to design a=
 fitting solution for something like this in committee.</span></div><div><s=
pan style=3D"font-size:small;background-color:rgb(255,255,255);text-decorat=
ion-style:initial;text-decoration-color:initial;float:none;display:inline">=
<br></span></div><div><span style=3D"font-size:small;background-color:rgb(2=
55,255,255);text-decoration-style:initial;text-decoration-color:initial;flo=
at:none;display:inline">My personal thoughts for the best route forward is =
for us to reassess if/when std::polymorphic_value happens -- assuming that =
we guarantee that it can be instantiated with an incomplete T. It may just =
be that instead of special-casing variant for a recursive_wrapper type, we =
may simply want a function object adaptor that perfect-forwards all types e=
xcept for polymorphic_value, which it would unwrap before perfect-forwardin=
g to the user&#39;s lambda, or something similarly non-intrusive to variant=
 itself. One downside is that polymorphic_value does not provide comparison=
s, and I suspect that the author would not want it to take on such operatio=
ns due to its intended usage with inheritance. Still, I strongly believe th=
at it&#39;d be best to put our efforts towards a solution of that ilk, rath=
er than being intrusive to variant itself.</span></div><div><br></div><div>=
<br></div><div><span style=3D"font-size:small;background-color:rgb(255,255,=
255);text-decoration-style:initial;text-decoration-color:initial;float:none=
;display:inline">On Sun, Aug 5, 2018 at 11:53 PM Zhihao Yuan &lt;<a href=3D=
"mailto:zy@miator.net" target=3D"_blank">zy@miator.net</a>&gt; wrote:</span=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"m_-605524883=
1761763408m_6791930801678542753WordSection1"><p class=3D"MsoNormal">=C2=A0 =
If ` polymorphic_value&lt;T&gt;` is<br>acceptable then `unique_ptr&lt;T&gt;=
` is also acceptable.<br></p></div></div></blockquote><div><br></div><div>O=
ne big drawback here for a unique_ptr is that it does not have value semant=
ics with respect to T. Putting a unique_ptr&lt;T&gt; in a variant means tha=
t it is move-only and also that the comparison operators compile fine, yet =
compare pointer values rather than the instances of T. The benefit of polym=
orphic_value&lt;T&gt; is that when you have it as an alternative_type of yo=
ur variant, your variant&#39;s copy operations all work as they should, as-=
if the object were logically contained (because it is).</div></div></div>

<p></p>

-- <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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANh8DEmT6oebbVcfk6eJ%3DJ5ajnhQcUfF%3=
D1RKOeazLVbfX0k%2Bag%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Df=
ooter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std=
-proposals/CANh8DEmT6oebbVcfk6eJ%3DJ5ajnhQcUfF%3D1RKOeazLVbfX0k%2Bag%40mail=
..gmail.com</a>.<br>
</blockquote></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hbB4Am_UBje79gTEE2_XOELEhFDF2Yj=
KGvOO2t%2B_N%3D9BA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hbB4Am_=
UBje79gTEE2_XOELEhFDF2YjKGvOO2t%2B_N%3D9BA%40mail.gmail.com</a>.<br />

--00000000000055fe390572c5c15b--

.

This is a multi-part message in MIME format.

--b1_df11de84e128ee943d865f5051816e79
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Going intrusive does not mean it is not configurable.
Take the allocation problem for instance, it goes away
as soon as users can specify any custom wrappers
(such as polymorphic_value<T>).  The piece of code
I linked to shows the shows a possibility =E2=80=93 we can define
a trait then let users specialize it:

struct MyIncompleteType;

template<class T>

struct variant_internal

{

using type =3D T;

using element_type =3D T;

using model_type =3D T;

          static element_type& unwrap(type& x)

          {

return x;

          }

};

template<>

struct variant_internal<MyIncompleteType(some_tag_t)>

{

              using type =3D polymorphic_value<MyIncompleteType>;

              using element_type =3D MyIncompleteType;

              using model_type =3D type;

          static element_type& unwrap(type& x)

          {

return *x;

          }

};

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________

From: 'Matt Calabrese' via ISO C++ Standard - Future Proposals <std-proposa=
ls@isocpp.org>
Sent: Monday, August 6, 2018 9:58 AM

It may just be that instead of special-casing variant for a recursive_wrapp=
er type, we may simply want a function object adaptor that perfect-forwards=
 all types except for polymorphic_value, which it would unwrap before perfe=
ct-forwarding to the user's lambda, or something similarly non-intrusive to=
 variant itself.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/coPh0_VG17ZH5SO_T7sYZ-14oFCpFce82Wr-ys3d-C3pGo3B=
fOJ6mMyAh3SOJitn1CB8lwiHPlRUSl6qN6Ws8djsWugX_TceQ950bMRNzAk%3D%40miator.net=
..

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

<html><head></head><body><div class=3D"WordSection1"><p class=3D"MsoNormal"=
>Going intrusive does not mean it is not configurable.<br/>Take the allocat=
ion problem for instance, it goes away<br/>as soon as users can specify any=
 custom wrappers<br/>(such as polymorphic_value&lt;T&gt;).=C2=A0 The piece =
of code<br/>I linked to shows the shows a possibility =E2=80=93 we can defi=
ne<br/>a trait then let users specialize it:<o:p></o:p></p><p class=3D"MsoN=
ormal"><o:p>=C2=A0</o:p></p><p class=3D"MsoNormal" style=3D"text-indent:10.=
15pt">struct MyIncompleteType;<o:p></o:p></p><p class=3D"MsoNormal" style=
=3D"text-indent:10.15pt"><o:p>=C2=A0</o:p></p><p class=3D"MsoNormal" style=
=3D"text-indent:10.15pt">template&lt;class T&gt;<o:p></o:p></p><p class=3D"=
MsoNormal" style=3D"text-indent:10.15pt">struct variant_internal<o:p></o:p>=
</p><p class=3D"MsoNormal" style=3D"text-indent:10.15pt">{<o:p></o:p></p><p=
 class=3D"MsoNormal" style=3D"text-indent:.5in">using type =3D T;<o:p></o:p=
></p><p class=3D"MsoNormal" style=3D"text-indent:.5in">using element_type =
=3D T;<o:p></o:p></p><p class=3D"MsoNormal" style=3D"text-indent:.5in">usin=
g model_type =3D T;<o:p></o:p></p><p class=3D"MsoNormal" style=3D"text-inde=
nt:.5in"><o:p>=C2=A0</o:p></p><p class=3D"MsoNormal" style=3D"text-indent:1=
0.15pt">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 static eleme=
nt_type&amp; unwrap(type&amp; x)<o:p></o:p></p><p class=3D"MsoNormal" style=
=3D"text-indent:10.15pt">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 {<o:p></o:p></p><p class=3D"MsoNormal" style=3D"margin-left:.5in;tex=
t-indent:.5in">return x;<o:p></o:p></p><p class=3D"MsoNormal" style=3D"text=
-indent:10.15pt">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<o=
:p></o:p></p><p class=3D"MsoNormal" style=3D"text-indent:10.15pt">};<o:p></=
o:p></p><p class=3D"MsoNormal" style=3D"text-indent:10.15pt"><o:p>=C2=A0</o=
:p></p><p class=3D"MsoNormal" style=3D"text-indent:10.15pt">template&lt;&gt=
;<o:p></o:p></p><p class=3D"MsoNormal" style=3D"text-indent:10.15pt">struct=
 variant_internal&lt;MyIncompleteType(some_tag_t)&gt;<o:p></o:p></p><p clas=
s=3D"MsoNormal" style=3D"text-indent:10.15pt">{<o:p></o:p></p><p class=3D"M=
soNormal">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 using type =3D polymorphic_value&lt;MyIncompleteType&gt;;<o=
:p></o:p></p><p class=3D"MsoNormal">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 using element_type =3D MyIncomplete=
Type;<o:p></o:p></p><p class=3D"MsoNormal">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 using model_type =3D type;=
<o:p></o:p></p><p class=3D"MsoNormal" style=3D"text-indent:10.15pt">=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <o:p></o:p></p><p class=3D=
"MsoNormal" style=3D"text-indent:10.15pt">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 static element_type&amp; unwrap(type&amp; x)<o:p></o:=
p></p><p class=3D"MsoNormal" style=3D"text-indent:10.15pt">=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {<o:p></o:p></p><p class=3D"MsoNorm=
al" style=3D"margin-left:.5in;text-indent:.5in">return *x;<o:p></o:p></p><p=
 class=3D"MsoNormal" style=3D"text-indent:10.15pt">=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<o:p></o:p></p><p class=3D"MsoNormal" style=
=3D"text-indent:10.15pt">};<o:p></o:p></p><p class=3D"MsoNormal"><o:p>=C2=
=A0</o:p></p><p class=3D"MsoNormal">--<br/>Zhihao Yuan, ID lichray<br/>The =
best way to predict the future is to invent it.<br/>_______________________=
________________________<o:p></o:p></p><p class=3D"MsoNormal"><o:p>=C2=A0</=
o:p></p><div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in =
0in 0in 4.0pt"><div><div style=3D"border:none;border-top:solid #E1E1E1 1.0p=
t;padding:3.0pt 0in 0in 0in"><p class=3D"MsoNormal"><b>From:</b> &#39;Matt =
Calabrese&#39; via ISO C++ Standard - Future Proposals &lt;std-proposals@is=
ocpp.org&gt; <br/><b>Sent:</b> Monday, August 6, 2018 9:58 AM<o:p></o:p></p=
></div></div><div><div><div><p class=3D"MsoNormal"><o:p>=C2=A0</o:p></p></d=
iv><div><p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;background:w=
hite">It may just be that instead of special-casing variant for a recursive=
_wrapper type, we may simply want a function object adaptor that perfect-fo=
rwards all types except for polymorphic_value, which it would unwrap before=
 perfect-forwarding to the user&#39;s lambda, or something similarly non-in=
trusive to variant itself.</span><o:p></o:p></p></div></div></div></div></d=
iv></body></html>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/coPh0_VG17ZH5SO_T7sYZ-14oFCpFce82Wr-y=
s3d-C3pGo3BfOJ6mMyAh3SOJitn1CB8lwiHPlRUSl6qN6Ws8djsWugX_TceQ950bMRNzAk%3D%4=
0miator.net?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/coPh0_VG17ZH5SO_T7sYZ-14oFCpFce82Wr-y=
s3d-C3pGo3BfOJ6mMyAh3SOJitn1CB8lwiHPlRUSl6qN6Ws8djsWugX_TceQ950bMRNzAk%3D%4=
0miator.net</a>.<br />

--b1_df11de84e128ee943d865f5051816e79--


.

--0000000000009365e50572c6a682
Content-Type: text/plain; charset="UTF-8"

On Mon, Aug 6, 2018 at 11:16 AM Richard Hodges <hodges.r@gmail.com> wrote:

> The fact that recursive variants could model nested structures was so
> useful that 'performance' was simply not relevant.
>

"Performance" (as-in performance of allocation) is not strictly the reason
that many people use allocators.

On Mon, Aug 6, 2018 at 11:16 AM Richard Hodges <hodges.r@gmail.com> wrote:

> Let's face it, without entering into one's own pointless engineering
> exercise, boost::variant is the only sensible choice in such
> circumstances.
>
> If we really must control allocation, can't this be done with a
> specialisation of std::variant_allocator_traits<> or somesuch. Is the
> <Alloc> paradigm so perfect that it must be set in stone to the detriment
> of the utility of an otherwise game-changing data structure?
>

Simply specifying traits would not allow the passing of a run-time
allocator argument, and it is also not clear which type you are applying
variant_allocator_traits to here. I will not make any comment on the best
way to provide allocator support.

On Mon, Aug 6, 2018 at 11:16 AM Richard Hodges <hodges.r@gmail.com> wrote:

> At present, std::variant<> is so limited in application that the de-facto
> standard remains - as is too often the case in recent std-library additions
> - boost.
>

That's only true for some developers. I was almost certainly the most
vocally against std::variant's design as it went through committee -- I was
very disappointed that we designed variant by committee instead of either
sticking more closely to boost's design or waiting until we actually had a
separate implementation with solid usage experience. That said, I don't
think this is one aspect that I'd suggest we just simply pull in, even
though I want a better answer for recursive variants in the standard.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEn6H3F6gBuf7zONN4-iBAUNSDOryxW6CALp7SCwL5N4jw%40mail.gmail.com.

--0000000000009365e50572c6a682
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Aug 6,=
 2018 at 11:16 AM Richard Hodges &lt;<a href=3D"mailto:hodges.r@gmail.com" =
target=3D"_blank">hodges.r@gmail.com</a>&gt; wrote:=C2=A0<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div></d=
iv><div>The fact that recursive variants could model nested structures was =
so useful that &#39;performance&#39; was simply not relevant.</div></div></=
div></blockquote><div><br></div><div>&quot;Performance&quot; (as-in perform=
ance of allocation) is not strictly the reason that many people use allocat=
ors.</div><div><br></div><div><div dir=3D"ltr">On Mon, Aug 6, 2018 at 11:16=
 AM Richard Hodges &lt;<a href=3D"mailto:hodges.r@gmail.com" target=3D"_bla=
nk">hodges.r@gmail.com</a>&gt; wrote:=C2=A0=C2=A0</div></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div> Let&#39;=
s face it, without entering into one&#39;s own pointless engineering exerci=
se, <font face=3D"monospace, monospace">boost::variant</font> is the only s=
ensible choice in such circumstances.</div><div><br></div><div>If we really=
 must control allocation, can&#39;t this be done with a specialisation of <=
font face=3D"monospace, monospace">std::variant_allocator_traits&lt;&gt;</f=
ont> or somesuch. Is the <font face=3D"monospace, monospace">&lt;Alloc&gt;<=
/font> paradigm so perfect that it must be set in stone to the detriment of=
 the utility of an otherwise game-changing data structure?</div></div></div=
></blockquote><div><br></div><div>Simply specifying traits would not allow =
the passing of a run-time allocator argument, and it is also not clear whic=
h type you are applying variant_allocator_traits to here. I will not make a=
ny comment on the best way to provide allocator support.</div><div></div><d=
iv>=C2=A0</div><div>On Mon, Aug 6, 2018 at 11:16 AM Richard Hodges &lt;<a h=
ref=3D"mailto:hodges.r@gmail.com" target=3D"_blank">hodges.r@gmail.com</a>&=
gt; wrote:=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div =
class=3D"gmail_quote"><div>At present, <font face=3D"monospace, monospace">=
std::variant&lt;&gt;</font> is so limited in application that the de-facto =
standard remains - as is too often the case in recent std-library additions=
 - boost.</div></div></div></blockquote><div><br></div><div>That&#39;s only=
 true for some developers. I was almost certainly the most vocally against =
std::variant&#39;s design as it went through committee -- I was very disapp=
ointed that we designed variant by committee instead of either sticking mor=
e closely to boost&#39;s design or waiting until we actually had a separate=
 implementation with solid usage experience. That said, I don&#39;t think t=
his is one aspect that I&#39;d suggest we just simply pull in, even though =
I want a better answer for recursive variants in the standard.</div></div><=
/div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANh8DEn6H3F6gBuf7zONN4-iBAUNSDOryxW6=
CALp7SCwL5N4jw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEn6H3F6gBuf=
7zONN4-iBAUNSDOryxW6CALp7SCwL5N4jw%40mail.gmail.com</a>.<br />

--0000000000009365e50572c6a682--

.

------=_Part_1403_1641685326.1533574373747
Content-Type: multipart/alternative;
 boundary="----=_Part_1404_1874951243.1533574373748"

------=_Part_1404_1874951243.1533574373748
Content-Type: text/plain; charset="UTF-8"

On Monday, August 6, 2018 at 12:20:09 PM UTC-4, Matt Calabrese wrote:
>
> On Mon, Aug 6, 2018 at 11:16 AM Richard Hodges <hodg...@gmail.com
> <javascript:>> wrote:
>
>> The fact that recursive variants could model nested structures was so
>> useful that 'performance' was simply not relevant.
>>
>
> "Performance" (as-in performance of allocation) is not strictly the reason
> that many people use allocators.
>
> On Mon, Aug 6, 2018 at 11:16 AM Richard Hodges <hodg...@gmail.com
> <javascript:>> wrote:
>
>> Let's face it, without entering into one's own pointless engineering
>> exercise, boost::variant is the only sensible choice in such
>> circumstances.
>>
>> If we really must control allocation, can't this be done with a
>> specialisation of std::variant_allocator_traits<> or somesuch. Is the
>> <Alloc> paradigm so perfect that it must be set in stone to the
>> detriment of the utility of an otherwise game-changing data structure?
>>
>
> Simply specifying traits would not allow the passing of a run-time
> allocator argument, and it is also not clear which type you are applying
> variant_allocator_traits to here. I will not make any comment on the best
> way to provide allocator support.
>

It seems to me that this is yet another place where polymorphic allocators
ought to be employed. `any`, `function`, and similar tools ought to be
using them as their allocation customization mechanism, and these kinds of
variant wrappers would go hand-in-hand with that.

On Mon, Aug 6, 2018 at 11:16 AM Richard Hodges <hodg...@gmail.com
> <javascript:>> wrote:
>
>> At present, std::variant<> is so limited in application that the
>> de-facto standard remains - as is too often the case in recent std-library
>> additions - boost.
>>
>
> That's only true for some developers. I was almost certainly the most
> vocally against std::variant's design as it went through committee -- I was
> very disappointed that we designed variant by committee instead of either
> sticking more closely to boost's design or waiting until we actually had a
> separate implementation with solid usage experience. That said, I don't
> think this is one aspect that I'd suggest we just simply pull in, even
> though I want a better answer for recursive variants in the standard.
>

What we need is a way for `variant` and its various visitation machinery to
allow the types in its type-list to differ from the type that `get` and
visitation uses. The minimum viable feature for this appears to be:

1. A customization point/whatever to allow a `T` to be variant-convertible
to some type `U`.
2. A way to ask a `variant` for the actual types that `get` returns, since
we can no longer rely on its template parameters to know that. This would
require some kind of generic `type_list` type, which is something C++
really needs anyway (pretty much every metaprogramming system of size has
one).

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8872eb73-88af-436c-90ef-6072cdea2563%40isocpp.org.

------=_Part_1404_1874951243.1533574373748
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, August 6, 2018 at 12:20:09 PM UTC-4, Matt Calab=
rese wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><d=
iv class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Aug 6, 2018 at 11:16 AM R=
ichard Hodges &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-=
mailto=3D"VI0NFZpeDgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;ja=
vascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;r=
eturn true;">hodg...@gmail.com</a>&gt; wrote:=C2=A0<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div></div><di=
v>The fact that recursive variants could model nested structures was so use=
ful that &#39;performance&#39; was simply not relevant.</div></div></div></=
blockquote><div><br></div><div>&quot;Performance&quot; (as-in performance o=
f allocation) is not strictly the reason that many people use allocators.</=
div><div><br></div><div><div dir=3D"ltr">On Mon, Aug 6, 2018 at 11:16 AM Ri=
chard Hodges &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-m=
ailto=3D"VI0NFZpeDgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;jav=
ascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;re=
turn true;">hodg...@gmail.com</a>&gt; wrote:=C2=A0=C2=A0</div></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div> L=
et&#39;s face it, without entering into one&#39;s own pointless engineering=
 exercise, <font face=3D"monospace, monospace">boost::variant</font> is the=
 only sensible choice in such circumstances.</div><div><br></div><div>If we=
 really must control allocation, can&#39;t this be done with a specialisati=
on of <font face=3D"monospace, monospace">std::variant_allocator_traits&lt;=
<wbr>&gt;</font> or somesuch. Is the <font face=3D"monospace, monospace">&l=
t;Alloc&gt;</font> paradigm so perfect that it must be set in stone to the =
detriment of the utility of an otherwise game-changing data structure?</div=
></div></div></blockquote><div><br></div><div>Simply specifying traits woul=
d not allow the passing of a run-time allocator argument, and it is also no=
t clear which type you are applying variant_allocator_traits to here. I wil=
l not make any comment on the best way to provide allocator support.</div><=
/div></div></blockquote><div><br></div><div>It seems to me that this is yet=
 another place where polymorphic allocators ought to be employed. `any`, `f=
unction`, and similar tools ought to be using them as their allocation cust=
omization mechanism, and these kinds of variant wrappers would go hand-in-h=
and with that.<br></div><div><br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><div dir=3D"ltr"><div class=3D"gmail_quote"><div></div><div></div>=
<div>On Mon, Aug 6, 2018 at 11:16 AM Richard Hodges &lt;<a href=3D"javascri=
pt:" target=3D"_blank" gdf-obfuscated-mailto=3D"VI0NFZpeDgAJ" rel=3D"nofoll=
ow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=
=3D"this.href=3D&#39;javascript:&#39;;return true;">hodg...@gmail.com</a>&g=
t; wrote:=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div c=
lass=3D"gmail_quote"><div>At present, <font face=3D"monospace, monospace">s=
td::variant&lt;&gt;</font> is so limited in application that the de-facto s=
tandard remains - as is too often the case in recent std-library additions =
- boost.</div></div></div></blockquote><div><br></div><div>That&#39;s only =
true for some developers. I was almost certainly the most vocally against s=
td::variant&#39;s design as it went through committee -- I was very disappo=
inted that we designed variant by committee instead of either sticking more=
 closely to boost&#39;s design or waiting until we actually had a separate =
implementation with solid usage experience. That said, I don&#39;t think th=
is is one aspect that I&#39;d suggest we just simply pull in, even though I=
 want a better answer for recursive variants in the standard.</div></div></=
div></blockquote><div><br></div><div>What we need is a way for `variant` an=
d its various visitation machinery to allow the types in its type-list to d=
iffer from the type that `get` and visitation uses. The minimum viable feat=
ure for this appears to be:</div><div><br></div><div>1. A customization poi=
nt/whatever to allow a `T` to be variant-convertible to some type `U`.</div=
><div>2. A way to ask a `variant` for the actual types that `get` returns, =
since we can no longer rely on its template parameters to know that. This w=
ould require some kind of generic `type_list` type, which is something C++ =
really needs anyway (pretty much every metaprogramming system of size has o=
ne).<br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8872eb73-88af-436c-90ef-6072cdea2563%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8872eb73-88af-436c-90ef-6072cdea2563=
%40isocpp.org</a>.<br />

------=_Part_1404_1874951243.1533574373748--

------=_Part_1403_1641685326.1533574373747--

.

--00000000000036a8b70572c74ab3
Content-Type: text/plain; charset="UTF-8"

On Mon, Aug 6, 2018 at 12:52 PM Nicol Bolas <jmckesson@gmail.com> wrote:

> On Monday, August 6, 2018 at 12:20:09 PM UTC-4, Matt Calabrese wrote:
>>
>> On Mon, Aug 6, 2018 at 11:16 AM Richard Hodges <hodg...@gmail.com>
>> wrote:
>>
>>> The fact that recursive variants could model nested structures was so
>>> useful that 'performance' was simply not relevant.
>>>
>>
>> "Performance" (as-in performance of allocation) is not strictly the
>> reason that many people use allocators.
>>
>> On Mon, Aug 6, 2018 at 11:16 AM Richard Hodges <hodg...@gmail.com>
>> wrote:
>>
>>> Let's face it, without entering into one's own pointless engineering
>>> exercise, boost::variant is the only sensible choice in such
>>> circumstances.
>>>
>>> If we really must control allocation, can't this be done with a
>>> specialisation of std::variant_allocator_traits<> or somesuch. Is the
>>> <Alloc> paradigm so perfect that it must be set in stone to the
>>> detriment of the utility of an otherwise game-changing data structure?
>>>
>>
>> Simply specifying traits would not allow the passing of a run-time
>> allocator argument, and it is also not clear which type you are applying
>> variant_allocator_traits to here. I will not make any comment on the best
>> way to provide allocator support.
>>
>
> It seems to me that this is yet another place where polymorphic allocators
> ought to be employed. `any`, `function`, and similar tools ought to be
> using them as their allocation customization mechanism, and these kinds of
> variant wrappers would go hand-in-hand with that.
>

Yes, I agree that that's the better solution if we were to make variant
allocator-aware. Also note that std::variant lost its allocator support
during standardization (rather last-minute).

On Mon, Aug 6, 2018 at 12:52 PM Nicol Bolas <jmckesson@gmail.com> wrote:

> What we need is a way for `variant` and its various visitation machinery
> to allow the types in its type-list to differ from the type that `get` and
> visitation uses. The minimum viable feature for this appears to be:
>
> 1. A customization point/whatever to allow a `T` to be variant-convertible
> to some type `U`.
> 2. A way to ask a `variant` for the actual types that `get` returns, since
> we can no longer rely on its template parameters to know that.
>

Yes, we can build in a publicly-exposed and general facility for doing
conversions of each `T` to an internally contained type and make it so that
to get the true alternative_type, users would have to use a metafunction or
decltype, etc. and then use the customization point internally when
implementing facilities such as get, but this all adds complexity to
specification, implementation, constraints on variant template parameter
types, and complicates documentation for users as well. I am not totally
against this route, I'm just skeptical that it provides enough benefits
over simply using something like std::polymorphic_value<T> as an
alternative type.

Also, we do have the #2 facility, just not in type list form. It's
std::variant_alternative (similar to what std::tuple_element is for tuple).
If you want the cv-ref type that get() returns for some input, you can also
use decltype directly.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEmF_3i_a_Pm4f%3DLE5Nd9ZfXs9FpFgKsyweTyy3e8A3_oQ%40mail.gmail.com.

--00000000000036a8b70572c74ab3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Aug 6,=
 2018 at 12:52 PM Nicol Bolas &lt;<a href=3D"mailto:jmckesson@gmail.com">jm=
ckesson@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr">On Monday, August 6, 2018 at 12:20:09 PM UTC-4, Matt Calabre=
se wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div clas=
s=3D"gmail_quote"><div dir=3D"ltr">On Mon, Aug 6, 2018 at 11:16 AM Richard =
Hodges &lt;<a rel=3D"nofollow">hodg...@gmail.com</a>&gt; wrote:=C2=A0<br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quo=
te"><div></div><div>The fact that recursive variants could model nested str=
uctures was so useful that &#39;performance&#39; was simply not relevant.</=
div></div></div></blockquote><div><br></div><div>&quot;Performance&quot; (a=
s-in performance of allocation) is not strictly the reason that many people=
 use allocators.</div><div><br></div><div><div dir=3D"ltr">On Mon, Aug 6, 2=
018 at 11:16 AM Richard Hodges &lt;<a rel=3D"nofollow">hodg...@gmail.com</a=
>&gt; wrote:=C2=A0=C2=A0</div></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div class=3D"gmail_quote"><div> Let&#39;s face it, without enteri=
ng into one&#39;s own pointless engineering exercise, <font face=3D"monospa=
ce, monospace">boost::variant</font> is the only sensible choice in such ci=
rcumstances.</div><div><br></div><div>If we really must control allocation,=
 can&#39;t this be done with a specialisation of <font face=3D"monospace, m=
onospace">std::variant_allocator_traits&lt;&gt;</font> or somesuch. Is the =
<font face=3D"monospace, monospace">&lt;Alloc&gt;</font> paradigm so perfec=
t that it must be set in stone to the detriment of the utility of an otherw=
ise game-changing data structure?</div></div></div></blockquote><div><br></=
div><div>Simply specifying traits would not allow the passing of a run-time=
 allocator argument, and it is also not clear which type you are applying v=
ariant_allocator_traits to here. I will not make any comment on the best wa=
y to provide allocator support.</div></div></div></blockquote><div><br></di=
v><div>It seems to me that this is yet another place where polymorphic allo=
cators ought to be employed. `any`, `function`, and similar tools ought to =
be using them as their allocation customization mechanism, and these kinds =
of variant wrappers would go hand-in-hand with that.<br></div></div></block=
quote><div><br></div><div>Yes, I agree that that&#39;s the better solution =
if we were to make variant allocator-aware. Also note that std::variant los=
t its allocator support during standardization (rather last-minute).</div><=
div>=C2=A0</div><div><div dir=3D"ltr">On Mon, Aug 6, 2018 at 12:52 PM Nicol=
 Bolas &lt;<a href=3D"mailto:jmckesson@gmail.com">jmckesson@gmail.com</a>&g=
t; wrote:</div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>W=
hat we need is a way for `variant` and its various visitation machinery to =
allow the types in its type-list to differ from the type that `get` and vis=
itation uses. The minimum viable feature for this appears to be:</div><div>=
<br></div><div>1. A customization point/whatever to allow a `T` to be varia=
nt-convertible to some type `U`.</div><div>2. A way to ask a `variant` for =
the actual types that `get` returns, since we can no longer rely on its tem=
plate parameters to know that.</div></div></blockquote><div><br></div><div>=
Yes, we can build in a publicly-exposed and general facility for doing conv=
ersions of each `T` to an internally contained type and make it so that to =
get the true alternative_type, users would have to use a metafunction or de=
cltype, etc. and then use the customization point internally when implement=
ing facilities such as get, but this all adds complexity to specification, =
implementation, constraints on variant template parameter types, and compli=
cates documentation for users as well. I am not totally against this route,=
 I&#39;m just skeptical that it provides enough benefits over simply using =
something like std::polymorphic_value&lt;T&gt; as an alternative type.=C2=
=A0=C2=A0</div><div><br></div><div>Also, we do have the #2 facility, just n=
ot in type list form. It&#39;s std::variant_alternative (similar to what st=
d::tuple_element is for tuple). If you want the cv-ref type that get() retu=
rns for some input, you can also use decltype directly.</div></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANh8DEmF_3i_a_Pm4f%3DLE5Nd9ZfXs9FpFg=
KsyweTyy3e8A3_oQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEmF_3i_a_=
Pm4f%3DLE5Nd9ZfXs9FpFgKsyweTyy3e8A3_oQ%40mail.gmail.com</a>.<br />

--00000000000036a8b70572c74ab3--

.

------=_Part_94_335884681.1534537509243
Content-Type: multipart/alternative;
 boundary="----=_Part_95_2073618612.1534537509243"

------=_Part_95_2073618612.1534537509243
Content-Type: text/plain; charset="UTF-8"

hello.

i am make joke code.but are you need like this?

#include <iostream>
#include <memory>
#include <variant>
#include <string>
template<class... Ts> struct overloaded : Ts... { using Ts::operator()...;
};
template<class... Ts> overloaded(Ts...)->overloaded<Ts...>;
class Holder;
typedef std::variant<std::monostate,Holder> Item;
class Holder {
public:
 Holder(Item& i) :I(&i) {}
 std::string ToString() {
  return std::visit(overloaded{ [](auto&)->std::string {return "Error";
},[](Holder& H)->std::string {return H.ToString(); } },*I) +
std::to_string(i++);
 }
protected:
 Item* I;
 int i = 0;
};
int main()
{
 Item I;
 Holder H(I);
 I = H;
 H.ToString();
 return 0;
}


--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/29680047-ec1d-4bb7-b153-894c076973db%40isocpp.org.

------=_Part_95_2073618612.1534537509243
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>hello.</div><div><br></div><div>i am make joke code.b=
ut are you need like this?</div><div><br></div><div><div class=3D"prettypri=
nt" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; b=
ackground-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div clas=
s=3D"subprettyprint"><span class=3D"styled-by-prettify" style=3D"color: #66=
0;"><font color=3D"#004000" style=3D"background-color: transparent;">#inclu=
de &lt;iostream&gt;<br>#include &lt;memory&gt;<br>#include &lt;variant&gt;<=
br>#include &lt;string&gt;</font></span></div><div class=3D"subprettyprint"=
><span class=3D"styled-by-prettify" style=3D"color: #660;"><font color=3D"#=
004000" style=3D"background-color: transparent;">template&lt;class... Ts&gt=
; struct overloaded : Ts... { using Ts::operator()...; };<br>template&lt;cl=
ass... Ts&gt; overloaded(Ts...)-&gt;overloaded&lt;Ts...&gt;;</font></span><=
/div><div class=3D"subprettyprint"><span class=3D"styled-by-prettify" style=
=3D"color: #660;"><font color=3D"#004000" style=3D"background-color: transp=
arent;">class Holder;<br>typedef std::variant&lt;std::monostate,Holder&gt; =
Item;</font></span></div><div class=3D"subprettyprint"><span class=3D"style=
d-by-prettify" style=3D"color: #660;"><font color=3D"#004000" style=3D"back=
ground-color: transparent;">class Holder {<br>public:<br>=C2=A0Holder(Item&=
amp; i) :I(&amp;i) {}</font></span></div><div class=3D"subprettyprint"><spa=
n class=3D"styled-by-prettify" style=3D"color: #660;"><font color=3D"#00400=
0" style=3D"background-color: transparent;">=C2=A0std::string ToString() {<=
br>=C2=A0=C2=A0return std::visit(overloaded{ [](auto&amp;)-&gt;std::string =
{return &quot;Error&quot;; },[](Holder&amp; H)-&gt;std::string {return H.To=
String(); } },*I) + std::to_string(i++);<br>=C2=A0}</font></span></div><div=
 class=3D"subprettyprint"><span class=3D"styled-by-prettify" style=3D"color=
: #660;"><font color=3D"#004000" style=3D"background-color: transparent;">p=
rotected:<br>=C2=A0Item* I;<br>=C2=A0int i =3D 0;<br>};</font></span></div>=
<div class=3D"subprettyprint"><span class=3D"styled-by-prettify" style=3D"c=
olor: #660;"><font color=3D"#004000" style=3D"background-color: transparent=
;">int main()<br>{<br>=C2=A0Item I;<br>=C2=A0Holder H(I);<br>=C2=A0I =3D H;=
</font></span></div><div class=3D"subprettyprint"><span class=3D"styled-by-=
prettify" style=3D"color: #660;"><font color=3D"#004000" style=3D"backgroun=
d-color: transparent;">=C2=A0H.ToString();</font></span></div><div class=3D=
"subprettyprint"><span class=3D"styled-by-prettify" style=3D"color: #660;">=
<font color=3D"#004000" style=3D"background-color: transparent;">=C2=A0retu=
rn 0;<br>}</font></span></div></code></div><br><br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/29680047-ec1d-4bb7-b153-894c076973db%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/29680047-ec1d-4bb7-b153-894c076973db=
%40isocpp.org</a>.<br />

------=_Part_95_2073618612.1534537509243--

------=_Part_94_335884681.1534537509243--

.