In the proposal:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4542.pdf

I found no specific prohibition of std::variant<>; however,
there was an implied prohibition on page 22 where it states
that for constructor variant(), a T_0 is constructed where
T_0 is the 1st alternative; however, if the variant being
constructed is std::variant<>, then there is no T_0; hence,
one must infer that std:variant<> is *not* allowed.

In contrast, for std::tuple, std::tuple<> is allowed, at least
according to:

http://en.cppreference.com/w/cpp/utility/tuple

Why should an empty tuple be allowed but not an empty
variant?  There is the empty product type as well as the
empty sum type in category theory:

https://en.wikipedia.org/wiki/Product_%28category_theory%29
https://en.wikipedia.org/wiki/Coproduct

-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/.

.

------=_Part_1779_1391885370.1446125660513
Content-Type: multipart/alternative;
 boundary="----=_Part_1780_756186388.1446125660514"

------=_Part_1780_756186388.1446125660514
Content-Type: text/plain; charset=UTF-8

On Thursday, October 29, 2015 at 8:24:03 AM UTC-4, Larry Evans wrote:
>
> In the proposal:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4542.pdf
>
> I found no specific prohibition of std::variant<>; however,
> there was an implied prohibition on page 22 where it states
> that for constructor variant(), a T_0 is constructed where
> T_0 is the 1st alternative; however, if the variant being
> constructed is std::variant<>, then there is no T_0; hence,
> one must infer that std:variant<> is *not* allowed.
>
> In contrast, for std::tuple, std::tuple<> is allowed, at least
> according to:
>
> http://en.cppreference.com/w/cpp/utility/tuple
>
> Why should an empty tuple be allowed but not an empty
> variant?  There is the empty product type as well as the
> empty sum type in category theory:
>
> https://en.wikipedia.org/wiki/Product_%28category_theory%29
> https://en.wikipedia.org/wiki/Coproduct


We shouldn't add features based on "theory". We should add them based on
utility.

A `tuple` that has no types is possible for 2 reasons:

1: It allows you to create a `tuple` from any parameter pack via
`make_tuple`, without having to check if it's empty.

2: It still makes sense as an object.

#1 doesn't apply to `variant`, because it's only one of the types, not all
of them. You wouldn't use a parameter pack to initialize one. You could use
a template argument pack to declare a variant over a specific set of types,
but that's a different matter.

#2 is the bigger sticking point. The N4542 `variant` is not allowed to be
empty; every (non-broken) `variant` instance must hold an object that is
one of its specified types. So... which one is it? If there are no
specified types, then what does the `variant` contain? For any `variant`
instance, there must be *something* a user can pass to `get` to retrieve a
value.

Also, how would you construct one? You obviously cannot call one of the
typed/indexed constructors, because there are no types/indices. You cannot
call the default constructor, since there is no initial type to default
construct. And default constructing an invalid `variant` is not acceptable
period.

In short, it just doesn't make sense for the design.

--

---
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/.

------=_Part_1780_756186388.1446125660514
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thursday, October 29, 2015 at 8:24:03 AM UTC-4, Larry Evans wrote:<block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;">In the proposal:
<br>
<br><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n454=
2.pdf" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;h=
ttp://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2F=
wg21%2Fdocs%2Fpapers%2F2015%2Fn4542.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCN=
E6O9TY8hE19VDKZfRlWZdiylnyIA&#39;;return true;" onclick=3D"this.href=3D&#39=
;http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%=
2Fwg21%2Fdocs%2Fpapers%2F2015%2Fn4542.pdf\46sa\75D\46sntz\0751\46usg\75AFQj=
CNE6O9TY8hE19VDKZfRlWZdiylnyIA&#39;;return true;">http://www.open-std.org/j=
tc1/<wbr>sc22/wg21/docs/papers/2015/<wbr>n4542.pdf</a>
<br>
<br>I found no specific prohibition of std::variant&lt;&gt;; however,
<br>there was an implied prohibition on page 22 where it states
<br>that for constructor variant(), a T_0 is constructed where
<br>T_0 is the 1st alternative; however, if the variant being
<br>constructed is std::variant&lt;&gt;, then there is no T_0; hence,
<br>one must infer that std:variant&lt;&gt; is *not* allowed.
<br>
<br>In contrast, for std::tuple, std::tuple&lt;&gt; is allowed, at least
<br>according to:
<br>
<br><a href=3D"http://en.cppreference.com/w/cpp/utility/tuple" target=3D"_b=
lank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.co=
m/url?q\75http%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Futility%2Ftuple\46sa=
\75D\46sntz\0751\46usg\75AFQjCNFhEcHf_r7j_w7vjkN8SpoqFeRmcw&#39;;return tru=
e;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2F=
en.cppreference.com%2Fw%2Fcpp%2Futility%2Ftuple\46sa\75D\46sntz\0751\46usg\=
75AFQjCNFhEcHf_r7j_w7vjkN8SpoqFeRmcw&#39;;return true;">http://en.cpprefere=
nce.com/w/<wbr>cpp/utility/tuple</a>
<br>
<br>Why should an empty tuple be allowed but not an empty
<br>variant? =C2=A0There is the empty product type as well as the
<br>empty sum type in category theory:
<br>
<br><a href=3D"https://en.wikipedia.org/wiki/Product_%28category_theory%29"=
 target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https:/=
/www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FProduct_%25=
28category_theory%2529\46sa\75D\46sntz\0751\46usg\75AFQjCNHk1utLAEmEcpIUC0p=
BscVa-QI3iA&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.goog=
le.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FProduct_%2528categor=
y_theory%2529\46sa\75D\46sntz\0751\46usg\75AFQjCNHk1utLAEmEcpIUC0pBscVa-QI3=
iA&#39;;return true;">https://en.wikipedia.org/wiki/<wbr>Product_%28categor=
y_theory%29</a>
<br><a href=3D"https://en.wikipedia.org/wiki/Coproduct" target=3D"_blank" r=
el=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.google.com/url?=
q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FCoproduct\46sa\75D\46sntz\0751\=
46usg\75AFQjCNFju455cAAwUR7in6JNT-N3jEg-dA&#39;;return true;" onclick=3D"th=
is.href=3D&#39;https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.or=
g%2Fwiki%2FCoproduct\46sa\75D\46sntz\0751\46usg\75AFQjCNFju455cAAwUR7in6JNT=
-N3jEg-dA&#39;;return true;">https://en.wikipedia.org/wiki/<wbr>Coproduct</=
a></blockquote><div><br>We shouldn&#39;t add features based on &quot;theory=
&quot;. We should add them based on utility.<br><br>A `tuple` that has no t=
ypes is possible for 2 reasons:<br><br>1: It allows you to create a `tuple`=
 from any parameter pack via `make_tuple`, without having to check if it&#3=
9;s empty.<br><br>2: It still makes sense as an object.<br><br>#1 doesn&#39=
;t apply to `variant`, because it&#39;s only one of the types, not all of t=
hem. You wouldn&#39;t use a parameter pack to initialize one. You could use=
 a template argument pack to declare a variant over a specific set of types=
, but that&#39;s a different matter.<br><br>#2 is the bigger sticking point=
.. The N4542 `variant` is not allowed to be empty; every (non-broken) `varia=
nt` instance must hold an object that is one of its specified types. So... =
which one is it? If there are no specified types, then what does the `varia=
nt` contain? For any `variant` instance, there must be <i>something</i> a u=
ser can pass to `get` to retrieve a value.<br><br>Also, how would you const=
ruct one? You obviously cannot call one of the typed/indexed constructors, =
because there are no types/indices. You cannot call the default constructor=
, since there is no initial type to default construct. And default construc=
ting an invalid `variant` is not acceptable period.<br><br>In short, it jus=
t doesn&#39;t make sense for the design.<br></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 />

------=_Part_1780_756186388.1446125660514--
------=_Part_1779_1391885370.1446125660513--

.

------=_Part_202_1226649493.1446127884467
Content-Type: multipart/alternative;
 boundary="----=_Part_203_1551594538.1446127884467"

------=_Part_203_1551594538.1446127884467
Content-Type: text/plain; charset=UTF-8

On Thursday, October 29, 2015 at 1:34:20 PM UTC, Nicol Bolas wrote:
>
> On Thursday, October 29, 2015 at 8:24:03 AM UTC-4, Larry Evans wrote:
>>
>> In the proposal:
>>
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4542.pdf
>>
>> I found no specific prohibition of std::variant<>; however,
>> there was an implied prohibition on page 22 where it states
>> that for constructor variant(), a T_0 is constructed where
>> T_0 is the 1st alternative; however, if the variant being
>> constructed is std::variant<>, then there is no T_0; hence,
>> one must infer that std:variant<> is *not* allowed.
>>
>> In contrast, for std::tuple, std::tuple<> is allowed, at least
>> according to:
>>
>> http://en.cppreference.com/w/cpp/utility/tuple
>>
>> Why should an empty tuple be allowed but not an empty
>> variant?  There is the empty product type as well as the
>> empty sum type in category theory:
>>
>> https://en.wikipedia.org/wiki/Product_%28category_theory%29
>> https://en.wikipedia.org/wiki/Coproduct
>
>
> We shouldn't add features based on "theory". We should add them based on
> utility.
>
>
Theory, without the "scary quotes" is still a good way to guide design.


> A `tuple` that has no types is possible for 2 reasons:
>
> 1: It allows you to create a `tuple` from any parameter pack via
> `make_tuple`, without having to check if it's empty.
>
> 2: It still makes sense as an object.
>
> #1 doesn't apply to `variant`, because it's only one of the types, not all
> of them. You wouldn't use a parameter pack to initialize one. You could use
> a template argument pack to declare a variant over a specific set of types,
> but that's a different matter.
>
>
how's a different matter?


> #2 is the bigger sticking point. The N4542 `variant` is not allowed to be
> empty; every (non-broken) `variant` instance must hold an object that is
> one of its specified types. So... which one is it? If there are no
> specified types, then what does the `variant` contain? For any `variant`
> instance, there must be *something* a user can pass to `get` to retrieve
> a value.
>

exactly the same is true for a tuple. A tuple can't be empty, still tuple<>
is just fine and it is not an empty tuple. 'get' would be a compile time
error for variant<> as it is for tuple<>


>
> Also, how would you construct one? You obviously cannot call one of the
> typed/indexed constructors, because there are no types/indices. You cannot
> call the default constructor, since there is no initial type to default
> construct.
>

Somehow that works just fine for tuple<>. variant<> would be exactly the
same: a unit type.

Disallowing variant<> would simply make generic code more difficult with no
benefit.

--

---
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/.

------=_Part_203_1551594538.1446127884467
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thursday, October 29, 2015 at 1:34:20 PM UTC, Nicol Bolas wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;">On Thursday, October 29, 2015 at 8:24:=
03 AM UTC-4, Larry Evans wrote:<blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">In t=
he proposal:
<br>
<br><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n454=
2.pdf" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;h=
ttp://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2F=
wg21%2Fdocs%2Fpapers%2F2015%2Fn4542.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCN=
E6O9TY8hE19VDKZfRlWZdiylnyIA&#39;;return true;" onclick=3D"this.href=3D&#39=
;http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%=
2Fwg21%2Fdocs%2Fpapers%2F2015%2Fn4542.pdf\46sa\75D\46sntz\0751\46usg\75AFQj=
CNE6O9TY8hE19VDKZfRlWZdiylnyIA&#39;;return true;">http://www.open-std.org/j=
tc1/<wbr>sc22/wg21/docs/papers/2015/<wbr>n4542.pdf</a>
<br>
<br>I found no specific prohibition of std::variant&lt;&gt;; however,
<br>there was an implied prohibition on page 22 where it states
<br>that for constructor variant(), a T_0 is constructed where
<br>T_0 is the 1st alternative; however, if the variant being
<br>constructed is std::variant&lt;&gt;, then there is no T_0; hence,
<br>one must infer that std:variant&lt;&gt; is *not* allowed.
<br>
<br>In contrast, for std::tuple, std::tuple&lt;&gt; is allowed, at least
<br>according to:
<br>
<br><a href=3D"http://en.cppreference.com/w/cpp/utility/tuple" rel=3D"nofol=
low" target=3D"_blank" onmousedown=3D"this.href=3D&#39;http://www.google.co=
m/url?q\75http%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Futility%2Ftuple\46sa=
\75D\46sntz\0751\46usg\75AFQjCNFhEcHf_r7j_w7vjkN8SpoqFeRmcw&#39;;return tru=
e;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2F=
en.cppreference.com%2Fw%2Fcpp%2Futility%2Ftuple\46sa\75D\46sntz\0751\46usg\=
75AFQjCNFhEcHf_r7j_w7vjkN8SpoqFeRmcw&#39;;return true;">http://en.cpprefere=
nce.com/w/<wbr>cpp/utility/tuple</a>
<br>
<br>Why should an empty tuple be allowed but not an empty
<br>variant? =C2=A0There is the empty product type as well as the
<br>empty sum type in category theory:
<br>
<br><a href=3D"https://en.wikipedia.org/wiki/Product_%28category_theory%29"=
 rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;https:/=
/www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FProduct_%25=
28category_theory%2529\46sa\75D\46sntz\0751\46usg\75AFQjCNHk1utLAEmEcpIUC0p=
BscVa-QI3iA&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.goog=
le.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FProduct_%2528categor=
y_theory%2529\46sa\75D\46sntz\0751\46usg\75AFQjCNHk1utLAEmEcpIUC0pBscVa-QI3=
iA&#39;;return true;">https://en.wikipedia.org/wiki/<wbr>Product_%28categor=
y_theory%29</a>
<br><a href=3D"https://en.wikipedia.org/wiki/Coproduct" rel=3D"nofollow" ta=
rget=3D"_blank" onmousedown=3D"this.href=3D&#39;https://www.google.com/url?=
q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FCoproduct\46sa\75D\46sntz\0751\=
46usg\75AFQjCNFju455cAAwUR7in6JNT-N3jEg-dA&#39;;return true;" onclick=3D"th=
is.href=3D&#39;https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.or=
g%2Fwiki%2FCoproduct\46sa\75D\46sntz\0751\46usg\75AFQjCNFju455cAAwUR7in6JNT=
-N3jEg-dA&#39;;return true;">https://en.wikipedia.org/wiki/<wbr>Coproduct</=
a></blockquote><div><br>We shouldn&#39;t add features based on &quot;theory=
&quot;. We should add them based on utility.<br><br></div></blockquote><div=
><br>Theory, without the &quot;scary quotes&quot; is still a good way to gu=
ide design.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v>A `tuple` that has no types is possible for 2 reasons:<br><br>1: It allow=
s you to create a `tuple` from any parameter pack via `make_tuple`, without=
 having to check if it&#39;s empty.<br><br>2: It still makes sense as an ob=
ject.<br><br>#1 doesn&#39;t apply to `variant`, because it&#39;s only one o=
f the types, not all of them. You wouldn&#39;t use a parameter pack to init=
ialize one. You could use a template argument pack to declare a variant ove=
r a specific set of types, but that&#39;s a different matter.<br><br></div>=
</blockquote><div><br>how&#39;s a different matter?<br>=C2=A0</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div>#2 is the bigger sticking point. =
The N4542 `variant` is not allowed to be empty; every (non-broken) `variant=
` instance must hold an object that is one of its specified types. So... wh=
ich one is it? If there are no specified types, then what does the `variant=
` contain? For any `variant` instance, there must be <i>something</i> a use=
r can pass to `get` to retrieve a value.<br></div></blockquote><div><br>exa=
ctly the same is true for a tuple. A tuple can&#39;t be empty, still tuple&=
lt;&gt; is just fine and it is not an empty tuple. &#39;get&#39; would be a=
 compile time error for variant&lt;&gt; as it is for tuple&lt;&gt;<br>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div><br>Also, how wo=
uld you construct one? You obviously cannot call one of the typed/indexed c=
onstructors, because there are no types/indices. You cannot call the defaul=
t constructor, since there is no initial type to default construct. </div><=
/blockquote><div><br>Somehow that works just fine for tuple&lt;&gt;. varian=
t&lt;&gt; would be exactly the same: a unit type.<br><br>Disallowing varian=
t&lt;&gt; would simply make generic code more difficult with no benefit.<br=
></div><br>

<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 />

------=_Part_203_1551594538.1446127884467--
------=_Part_202_1226649493.1446127884467--

.

--047d7b3a84c653dc4f05233f81ee
Content-Type: text/plain; charset=UTF-8

On Thu, Oct 29, 2015 at 8:23 AM, Larry Evans <cppljevans@suddenlink.net>
wrote:

> In the proposal:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4542.pdf
>
> I found no specific prohibition of std::variant<>; however,
> there was an implied prohibition on page 22 where it states
> that for constructor variant(), a T_0 is constructed where
> T_0 is the 1st alternative; however, if the variant being
> constructed is std::variant<>, then there is no T_0; hence,
> one must infer that std:variant<> is *not* allowed.
>
> In contrast, for std::tuple, std::tuple<> is allowed, at least
> according to:
>
> http://en.cppreference.com/w/cpp/utility/tuple
>
> Why should an empty tuple be allowed but not an empty
> variant?  There is the empty product type as well as the
> empty sum type in category theory:
>
> https://en.wikipedia.org/wiki/Product_%28category_theory%29
> https://en.wikipedia.org/wiki/Coproduct
>
> -regards,
> Larry
>
>
This has been discussed inside and outside the committee.
The consensus is, I think, that variant<> should be a valid type, but you
can't instantiate it, because it has 0 values.

ie similar to (if I do it correctly) :

struct zero
{
    zero() = delete;
};

So

template <typename T> int foo() { return 17; }

int x = foo<zero>(); // works
zero z; // fails

int xx = foo<variant<>>(); // should work


Tony

--

---
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/.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Thu, Oct 29, 2015 at 8:23 AM, Larry Evans <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:cppljevans@suddenlink.net" target=3D"_blank">cppljevans@sudde=
nlink.net</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">In the p=
roposal:<br>
<br>
<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4542.pd=
f" rel=3D"noreferrer" target=3D"_blank">http://www.open-std.org/jtc1/sc22/w=
g21/docs/papers/2015/n4542.pdf</a><br>
<br>
I found no specific prohibition of std::variant&lt;&gt;; however,<br>
there was an implied prohibition on page 22 where it states<br>
that for constructor variant(), a T_0 is constructed where<br>
T_0 is the 1st alternative; however, if the variant being<br>
constructed is std::variant&lt;&gt;, then there is no T_0; hence,<br>
one must infer that std:variant&lt;&gt; is *not* allowed.<br>
<br>
In contrast, for std::tuple, std::tuple&lt;&gt; is allowed, at least<br>
according to:<br>
<br>
<a href=3D"http://en.cppreference.com/w/cpp/utility/tuple" rel=3D"noreferre=
r" target=3D"_blank">http://en.cppreference.com/w/cpp/utility/tuple</a><br>
<br>
Why should an empty tuple be allowed but not an empty<br>
variant?=C2=A0 There is the empty product type as well as the<br>
empty sum type in category theory:<br>
<br>
<a href=3D"https://en.wikipedia.org/wiki/Product_%28category_theory%29" rel=
=3D"noreferrer" target=3D"_blank">https://en.wikipedia.org/wiki/Product_%28=
category_theory%29</a><br>
<a href=3D"https://en.wikipedia.org/wiki/Coproduct" rel=3D"noreferrer" targ=
et=3D"_blank">https://en.wikipedia.org/wiki/Coproduct</a><br>
<br>
-regards,<br>
Larry<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></blockquo=
te><div><br></div><div>This has been discussed inside and outside the commi=
ttee.<br></div><div>The consensus is, I think, that variant&lt;&gt; should =
be a valid type, but you can&#39;t instantiate it, because it has 0 values.=
<br><br></div><div>ie similar to (if I do it correctly) :<br><br></div><div=
>struct zero<br>{<br></div><div>=C2=A0=C2=A0=C2=A0 zero() =3D delete;<br>};=
<br><br></div><div>So<br><br></div><div>template &lt;typename T&gt; int foo=
() { return 17; }<br><br></div><div>int x =3D foo&lt;zero&gt;(); // works<b=
r></div><div>zero z; // fails<br><br></div><div>int xx =3D foo&lt;variant&l=
t;&gt;&gt;(); // should work<br><br><br></div><div>Tony<br><br></div><div><=
br></div></div><br></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 />

--047d7b3a84c653dc4f05233f81ee--

.

--089e012293840fb59705233f9ac0
Content-Type: text/plain; charset=UTF-8

On Thu, Oct 29, 2015 at 3:55 PM, Tony V E <tvaneerd@gmail.com> wrote:

>
> On Thu, Oct 29, 2015 at 8:23 AM, Larry Evans <cppljevans@suddenlink.net>
> wrote:
>
>> In the proposal:
>>
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4542.pdf
>>
>> I found no specific prohibition of std::variant<>; however,
>> there was an implied prohibition on page 22 where it states
>> that for constructor variant(), a T_0 is constructed where
>> T_0 is the 1st alternative; however, if the variant being
>> constructed is std::variant<>, then there is no T_0; hence,
>> one must infer that std:variant<> is *not* allowed.
>>
>> In contrast, for std::tuple, std::tuple<> is allowed, at least
>> according to:
>>
>> http://en.cppreference.com/w/cpp/utility/tuple
>>
>> Why should an empty tuple be allowed but not an empty
>> variant?  There is the empty product type as well as the
>> empty sum type in category theory:
>>
>> https://en.wikipedia.org/wiki/Product_%28category_theory%29
>> https://en.wikipedia.org/wiki/Coproduct
>>
>> -regards,
>> Larry
>>
>>
> This has been discussed inside and outside the committee.
> The consensus is, I think, that variant<> should be a valid type, but you
> can't instantiate it, because it has 0 values.
>

This makes sense for an implementation of variant with never-empty
guarantee. I believe the committee is leaning towards variant that can be
empty, in which case there is no problem with creating instances of
variant<>. It's just empty.

Roman Perepelitsa.

--

---
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/.

--089e012293840fb59705233f9ac0
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 T=
hu, Oct 29, 2015 at 3:55 PM, Tony V E <span dir=3D"ltr">&lt;<a href=3D"mail=
to:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gma=
il_extra"><br><div class=3D"gmail_quote"><span class=3D"">On Thu, Oct 29, 2=
015 at 8:23 AM, Larry Evans <span dir=3D"ltr">&lt;<a href=3D"mailto:cppljev=
ans@suddenlink.net" target=3D"_blank">cppljevans@suddenlink.net</a>&gt;</sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">In the proposal:<br>
<br>
<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4542.pd=
f" rel=3D"noreferrer" target=3D"_blank">http://www.open-std.org/jtc1/sc22/w=
g21/docs/papers/2015/n4542.pdf</a><br>
<br>
I found no specific prohibition of std::variant&lt;&gt;; however,<br>
there was an implied prohibition on page 22 where it states<br>
that for constructor variant(), a T_0 is constructed where<br>
T_0 is the 1st alternative; however, if the variant being<br>
constructed is std::variant&lt;&gt;, then there is no T_0; hence,<br>
one must infer that std:variant&lt;&gt; is *not* allowed.<br>
<br>
In contrast, for std::tuple, std::tuple&lt;&gt; is allowed, at least<br>
according to:<br>
<br>
<a href=3D"http://en.cppreference.com/w/cpp/utility/tuple" rel=3D"noreferre=
r" target=3D"_blank">http://en.cppreference.com/w/cpp/utility/tuple</a><br>
<br>
Why should an empty tuple be allowed but not an empty<br>
variant?=C2=A0 There is the empty product type as well as the<br>
empty sum type in category theory:<br>
<br>
<a href=3D"https://en.wikipedia.org/wiki/Product_%28category_theory%29" rel=
=3D"noreferrer" target=3D"_blank">https://en.wikipedia.org/wiki/Product_%28=
category_theory%29</a><br>
<a href=3D"https://en.wikipedia.org/wiki/Coproduct" rel=3D"noreferrer" targ=
et=3D"_blank">https://en.wikipedia.org/wiki/Coproduct</a><br>
<br>
-regards,<br>
Larry<br>
<span><font color=3D"#888888"><br></font></span></blockquote><div><br></div=
></span><div>This has been discussed inside and outside the committee.<br><=
/div><div>The consensus is, I think, that variant&lt;&gt; should be a valid=
 type, but you can&#39;t instantiate it, because it has 0 values.<br></div>=
</div></div></div></blockquote><div><br></div><div>This makes sense for an =
implementation of variant with never-empty guarantee. I believe the committ=
ee is leaning towards variant that can be empty, in which case there is no =
problem with creating instances of variant&lt;&gt;. It&#39;s just empty.</d=
iv><div><br></div><div>Roman Perepelitsa.</div><div><br></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 />

--089e012293840fb59705233f9ac0--

.

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

On 29 October 2015 at 10:02, Roman Perepelitsa <roman.perepelitsa@gmail.com>
wrote:

> This makes sense for an implementation of variant with never-empty
> guarantee. I believe the committee is leaning towards variant that can be
> empty, in which case there is no problem with creating instances of
> variant<>. It's just empty.
>

That would still be a special case, as the only way to get into that state
is when an exception is thrown.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
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/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On 29 October 2015 at 10:02, Roman Perepelitsa <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:roman.perepelitsa@gmail.com" target=3D"_blank">roman.perepelits=
a@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Th=
is makes sense for an implementation of variant with never-empty guarantee.=
 I believe the committee is leaning towards variant that can be empty, in w=
hich case there is no problem with creating instances of variant&lt;&gt;. I=
t&#39;s just empty.</div></blockquote><div><br></div><div>That would still =
be a special case, as the only way to get into that state is when an except=
ion is thrown.=C2=A0</div></div>-- <br><div class=3D"gmail_signature">=C2=
=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@evi=
loverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=C2=A0 (847)=
 691-1404</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 />

--001a113da7d2d28a4105233fa17b--

.

On 29/10/15 15:02, Roman Perepelitsa wrote:
> On Thu, Oct 29, 2015 at 3:55 PM, Tony V E <tvaneerd@gmail.com
> <mailto:tvaneerd@gmail.com>> wrote:
>
>
>     On Thu, Oct 29, 2015 at 8:23 AM, Larry Evans
>     <cppljevans@suddenlink.net <mailto:cppljevans@suddenlink.net>> wrote:
>
>         In the proposal:
>
>         http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4542.pdf
>
>         I found no specific prohibition of std::variant<>; however,
>         there was an implied prohibition on page 22 where it states
>         that for constructor variant(), a T_0 is constructed where
>         T_0 is the 1st alternative; however, if the variant being
>         constructed is std::variant<>, then there is no T_0; hence,
>         one must infer that std:variant<> is *not* allowed.
>
>         In contrast, for std::tuple, std::tuple<> is allowed, at least
>         according to:
>
>         http://en.cppreference.com/w/cpp/utility/tuple
>
>         Why should an empty tuple be allowed but not an empty
>         variant?  There is the empty product type as well as the
>         empty sum type in category theory:
>
>         https://en.wikipedia.org/wiki/Product_%28category_theory%29
>         https://en.wikipedia.org/wiki/Coproduct
>
>         -regards,
>         Larry
>
>
>     This has been discussed inside and outside the committee.
>     The consensus is, I think, that variant<> should be a valid type,
>     but you can't instantiate it, because it has 0 values.
>
>
> This makes sense for an implementation of variant with never-empty
> guarantee. I believe the committee is leaning towards variant that can
> be empty, in which case there is no problem with creating instances of
> variant<>. It's just empty.

No, the committee consensus was that the variant should only ever not
have a value if assignment or emplace-construction threw an exception.

In particular, a default-constructed variant is never empty --- it
constructs the first type, and if that fails the variant construction
fails too.

Anthony
--
Author of C++ Concurrency in Action     http://www.stdthread.co.uk/book/
just::thread C++11 thread library             http://www.stdthread.co.uk
Just Software Solutions Ltd       http://www.justsoftwaresolutions.co.uk
15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

--

---
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/.

.

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

On Thu, Oct 29, 2015 at 11:02 AM, Roman Perepelitsa <
roman.perepelitsa@gmail.com> wrote:

> On Thu, Oct 29, 2015 at 3:55 PM, Tony V E <tvaneerd@gmail.com> wrote:
>
>>
>> On Thu, Oct 29, 2015 at 8:23 AM, Larry Evans <cppljevans@suddenlink.net>
>> wrote:
>>
>>> In the proposal:
>>>
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4542.pdf
>>>
>>> I found no specific prohibition of std::variant<>; however,
>>> there was an implied prohibition on page 22 where it states
>>> that for constructor variant(), a T_0 is constructed where
>>> T_0 is the 1st alternative; however, if the variant being
>>> constructed is std::variant<>, then there is no T_0; hence,
>>> one must infer that std:variant<> is *not* allowed.
>>>
>>> In contrast, for std::tuple, std::tuple<> is allowed, at least
>>> according to:
>>>
>>> http://en.cppreference.com/w/cpp/utility/tuple
>>>
>>> Why should an empty tuple be allowed but not an empty
>>> variant?  There is the empty product type as well as the
>>> empty sum type in category theory:
>>>
>>> https://en.wikipedia.org/wiki/Product_%28category_theory%29
>>> https://en.wikipedia.org/wiki/Coproduct
>>>
>>> -regards,
>>> Larry
>>>
>>>
>> This has been discussed inside and outside the committee.
>> The consensus is, I think, that variant<> should be a valid type, but you
>> can't instantiate it, because it has 0 values.
>>
>
> This makes sense for an implementation of variant with never-empty
> guarantee. I believe the committee is leaning towards variant that can be
> empty, in which case there is no problem with creating instances of
> variant<>. It's just empty.
>
>
The current committee variant (as of last week) can only be "empty" via an
exception.  So you can't create an empty one.

ie
struct zero {
   zero() { throw 42; }
};

In some sense "more creatable" than the previous zero, but still not
creatable. (ie "more creatable" in that you can now compile the constructor
call, but you still can't create one at runtime).

Tony


Roman Perepelitsa.
>
> --
>
> ---
> 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/.
>

--

---
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/.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Thu, Oct 29, 2015 at 11:02 AM, Roman Perepelitsa <span dir=3D"ltr">&=
lt;<a href=3D"mailto:roman.perepelitsa@gmail.com" target=3D"_blank">roman.p=
erepelitsa@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><s=
pan class=3D"">On Thu, Oct 29, 2015 at 3:55 PM, Tony V E <span dir=3D"ltr">=
&lt;<a href=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.=
com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><span>On Thu, O=
ct 29, 2015 at 8:23 AM, Larry Evans <span dir=3D"ltr">&lt;<a href=3D"mailto=
:cppljevans@suddenlink.net" target=3D"_blank">cppljevans@suddenlink.net</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">In the proposal:<br>
<br>
<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4542.pd=
f" rel=3D"noreferrer" target=3D"_blank">http://www.open-std.org/jtc1/sc22/w=
g21/docs/papers/2015/n4542.pdf</a><br>
<br>
I found no specific prohibition of std::variant&lt;&gt;; however,<br>
there was an implied prohibition on page 22 where it states<br>
that for constructor variant(), a T_0 is constructed where<br>
T_0 is the 1st alternative; however, if the variant being<br>
constructed is std::variant&lt;&gt;, then there is no T_0; hence,<br>
one must infer that std:variant&lt;&gt; is *not* allowed.<br>
<br>
In contrast, for std::tuple, std::tuple&lt;&gt; is allowed, at least<br>
according to:<br>
<br>
<a href=3D"http://en.cppreference.com/w/cpp/utility/tuple" rel=3D"noreferre=
r" target=3D"_blank">http://en.cppreference.com/w/cpp/utility/tuple</a><br>
<br>
Why should an empty tuple be allowed but not an empty<br>
variant?=C2=A0 There is the empty product type as well as the<br>
empty sum type in category theory:<br>
<br>
<a href=3D"https://en.wikipedia.org/wiki/Product_%28category_theory%29" rel=
=3D"noreferrer" target=3D"_blank">https://en.wikipedia.org/wiki/Product_%28=
category_theory%29</a><br>
<a href=3D"https://en.wikipedia.org/wiki/Coproduct" rel=3D"noreferrer" targ=
et=3D"_blank">https://en.wikipedia.org/wiki/Coproduct</a><br>
<br>
-regards,<br>
Larry<br>
<span><font color=3D"#888888"><br></font></span></blockquote><div><br></div=
></span><div>This has been discussed inside and outside the committee.<br><=
/div><div>The consensus is, I think, that variant&lt;&gt; should be a valid=
 type, but you can&#39;t instantiate it, because it has 0 values.<br></div>=
</div></div></div></blockquote><div><br></div></span><div>This makes sense =
for an implementation of variant with never-empty guarantee. I believe the =
committee is leaning towards variant that can be empty, in which case there=
 is no problem with creating instances of variant&lt;&gt;. It&#39;s just em=
pty.</div><span class=3D"HOEnZb"><font color=3D"#888888"><div><br></div></f=
ont></span></div></div></div></blockquote><div><br></div><div>The current c=
ommittee variant (as of last week) can only be &quot;empty&quot; via an exc=
eption.=C2=A0 So you can&#39;t create an empty one.<br><br></div><div>ie<br=
></div><div>struct zero {<br></div><div>=C2=A0=C2=A0 zero() { throw 42; }<b=
r>};<br><br></div><div>In some sense &quot;more creatable&quot; than the pr=
evious zero, but still not creatable. (ie &quot;more creatable&quot; in tha=
t you can now compile the constructor call, but you still can&#39;t create =
one at runtime).<br><br></div><div>Tony<br></div><div><br><br></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_extra"><div cl=
ass=3D"gmail_quote"><span class=3D"HOEnZb"><font color=3D"#888888"><div></d=
iv><div>Roman Perepelitsa.</div><div><br></div></font></span></div></div></=
div><div class=3D"HOEnZb"><div class=3D"h5">

<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" 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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></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 />

--001a11c377a2971c8405233fa999--

.

------=_Part_9559_1269576667.1446133363905
Content-Type: multipart/alternative;
 boundary="----=_Part_9560_765020674.1446133363905"

------=_Part_9560_765020674.1446133363905
Content-Type: text/plain; charset=UTF-8

On Thursday, October 29, 2015 at 10:11:24 AM UTC-4, Giovanni Piero Deretta
wrote:
>
> On Thursday, October 29, 2015 at 1:34:20 PM UTC, Nicol Bolas wrote:
>>
>> On Thursday, October 29, 2015 at 8:24:03 AM UTC-4, Larry Evans wrote:
>>>
>>> In the proposal:
>>>
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4542.pdf
>>>
>>> I found no specific prohibition of std::variant<>; however,
>>> there was an implied prohibition on page 22 where it states
>>> that for constructor variant(), a T_0 is constructed where
>>> T_0 is the 1st alternative; however, if the variant being
>>> constructed is std::variant<>, then there is no T_0; hence,
>>> one must infer that std:variant<> is *not* allowed.
>>>
>>> In contrast, for std::tuple, std::tuple<> is allowed, at least
>>> according to:
>>>
>>> http://en.cppreference.com/w/cpp/utility/tuple
>>>
>>> Why should an empty tuple be allowed but not an empty
>>> variant?  There is the empty product type as well as the
>>> empty sum type in category theory:
>>>
>>> https://en.wikipedia.org/wiki/Product_%28category_theory%29
>>> https://en.wikipedia.org/wiki/Coproduct
>>
>>
>> We shouldn't add features based on "theory". We should add them based on
>> utility.
>>
>>
> Theory, without the "scary quotes" is still a good way to guide design.
>
>
>> A `tuple` that has no types is possible for 2 reasons:
>>
>> 1: It allows you to create a `tuple` from any parameter pack via
>> `make_tuple`, without having to check if it's empty.
>>
>> 2: It still makes sense as an object.
>>
>> #1 doesn't apply to `variant`, because it's only one of the types, not
>> all of them. You wouldn't use a parameter pack to initialize one. You could
>> use a template argument pack to declare a variant over a specific set of
>> types, but that's a different matter.
>>
>>
> how's a different matter?
>
>
>> #2 is the bigger sticking point. The N4542 `variant` is not allowed to be
>> empty; every (non-broken) `variant` instance must hold an object that is
>> one of its specified types. So... which one is it? If there are no
>> specified types, then what does the `variant` contain? For any `variant`
>> instance, there must be *something* a user can pass to `get` to retrieve
>> a value.
>>
>
> exactly the same is true for a tuple. A tuple can't be empty, still
> tuple<> is just fine and it is not an empty tuple. 'get' would be a compile
> time error for variant<> as it is for tuple<>
>
>
>>
>> Also, how would you construct one? You obviously cannot call one of the
>> typed/indexed constructors, because there are no types/indices. You cannot
>> call the default constructor, since there is no initial type to default
>> construct.
>>
>
> Somehow that works just fine for tuple<>. variant<> would be exactly the
> same: a unit type.
>
>
Disallowing variant<> would simply make generic code more difficult with no
> benefit.
>

It would make generic code *slightly* more difficult.

Furthermore, what benefit would there be in allowing generic code to
construct such a type? Even if we invent some default construction syntax
that allows it to exist, basically ever named member function either
accomplishes nothing or cannot return a meaningful value.

`index`? What value could it possibly return?

`emplace`? No types to construct.

`valid`? The variant cannot perform any operation to cause it to become
invalid.

The various namespace-scoped operators? No meaningful implementation.

`std::get`? Can't call it.

`std::holds_alternative`? Always returns false.

`std::visit`? What would that even do?

So exactly what operations are you planning to do here?

At the end of the day, `variant` is not a `tuple`, so judging it by that
metric is simply wrongheaded. `tuple` is rather like a struct, so it makes
sense for it to not have any types. An empty struct is a reasonable
construct to talk about.

A never-empty `variant` with no types is not a reasonable construct. A
never-empty discriminated union must have at least one available option.

Can you provide a useful example of generic code that would need to declare
such a type and actually use it?

--

---
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/.

------=_Part_9560_765020674.1446133363905
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thursday, October 29, 2015 at 10:11:24 AM UTC-4, Giovanni Piero Deretta =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Thursday, October 29,=
 2015 at 1:34:20 PM UTC, Nicol Bolas wrote:<blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">On Thursday, October 29, 2015 at 8:24:03 AM UTC-4, Larry Evans wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">In the proposal:
<br>
<br><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n454=
2.pdf" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;h=
ttp://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2F=
wg21%2Fdocs%2Fpapers%2F2015%2Fn4542.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCN=
E6O9TY8hE19VDKZfRlWZdiylnyIA&#39;;return true;" onclick=3D"this.href=3D&#39=
;http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%=
2Fwg21%2Fdocs%2Fpapers%2F2015%2Fn4542.pdf\46sa\75D\46sntz\0751\46usg\75AFQj=
CNE6O9TY8hE19VDKZfRlWZdiylnyIA&#39;;return true;">http://www.open-std.org/j=
tc1/<wbr>sc22/wg21/docs/papers/2015/<wbr>n4542.pdf</a>
<br>
<br>I found no specific prohibition of std::variant&lt;&gt;; however,
<br>there was an implied prohibition on page 22 where it states
<br>that for constructor variant(), a T_0 is constructed where
<br>T_0 is the 1st alternative; however, if the variant being
<br>constructed is std::variant&lt;&gt;, then there is no T_0; hence,
<br>one must infer that std:variant&lt;&gt; is *not* allowed.
<br>
<br>In contrast, for std::tuple, std::tuple&lt;&gt; is allowed, at least
<br>according to:
<br>
<br><a href=3D"http://en.cppreference.com/w/cpp/utility/tuple" rel=3D"nofol=
low" target=3D"_blank" onmousedown=3D"this.href=3D&#39;http://www.google.co=
m/url?q\75http%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Futility%2Ftuple\46sa=
\75D\46sntz\0751\46usg\75AFQjCNFhEcHf_r7j_w7vjkN8SpoqFeRmcw&#39;;return tru=
e;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2F=
en.cppreference.com%2Fw%2Fcpp%2Futility%2Ftuple\46sa\75D\46sntz\0751\46usg\=
75AFQjCNFhEcHf_r7j_w7vjkN8SpoqFeRmcw&#39;;return true;">http://en.cpprefere=
nce.com/w/<wbr>cpp/utility/tuple</a>
<br>
<br>Why should an empty tuple be allowed but not an empty
<br>variant? =C2=A0There is the empty product type as well as the
<br>empty sum type in category theory:
<br>
<br><a href=3D"https://en.wikipedia.org/wiki/Product_%28category_theory%29"=
 rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;https:/=
/www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FProduct_%25=
28category_theory%2529\46sa\75D\46sntz\0751\46usg\75AFQjCNHk1utLAEmEcpIUC0p=
BscVa-QI3iA&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.goog=
le.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FProduct_%2528categor=
y_theory%2529\46sa\75D\46sntz\0751\46usg\75AFQjCNHk1utLAEmEcpIUC0pBscVa-QI3=
iA&#39;;return true;">https://en.wikipedia.org/wiki/<wbr>Product_%28categor=
y_theory%29</a>
<br><a href=3D"https://en.wikipedia.org/wiki/Coproduct" rel=3D"nofollow" ta=
rget=3D"_blank" onmousedown=3D"this.href=3D&#39;https://www.google.com/url?=
q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FCoproduct\46sa\75D\46sntz\0751\=
46usg\75AFQjCNFju455cAAwUR7in6JNT-N3jEg-dA&#39;;return true;" onclick=3D"th=
is.href=3D&#39;https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.or=
g%2Fwiki%2FCoproduct\46sa\75D\46sntz\0751\46usg\75AFQjCNFju455cAAwUR7in6JNT=
-N3jEg-dA&#39;;return true;">https://en.wikipedia.org/wiki/<wbr>Coproduct</=
a></blockquote><div><br>We shouldn&#39;t add features based on &quot;theory=
&quot;. We should add them based on utility.<br><br></div></blockquote><div=
><br>Theory, without the &quot;scary quotes&quot; is still a good way to gu=
ide design.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>A `=
tuple` that has no types is possible for 2 reasons:<br><br>1: It allows you=
 to create a `tuple` from any parameter pack via `make_tuple`, without havi=
ng to check if it&#39;s empty.<br><br>2: It still makes sense as an object.=
<br><br>#1 doesn&#39;t apply to `variant`, because it&#39;s only one of the=
 types, not all of them. You wouldn&#39;t use a parameter pack to initializ=
e one. You could use a template argument pack to declare a variant over a s=
pecific set of types, but that&#39;s a different matter.<br><br></div></blo=
ckquote><div><br>how&#39;s a different matter?<br>=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div>#2 is the bigger sticking point. The N4542 =
`variant` is not allowed to be empty; every (non-broken) `variant` instance=
 must hold an object that is one of its specified types. So... which one is=
 it? If there are no specified types, then what does the `variant` contain?=
 For any `variant` instance, there must be <i>something</i> a user can pass=
 to `get` to retrieve a value.<br></div></blockquote><div><br>exactly the s=
ame is true for a tuple. A tuple can&#39;t be empty, still tuple&lt;&gt; is=
 just fine and it is not an empty tuple. &#39;get&#39; would be a compile t=
ime error for variant&lt;&gt; as it is for tuple&lt;&gt;<br>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div><br>Also, how would you construct=
 one? You obviously cannot call one of the typed/indexed constructors, beca=
use there are no types/indices. You cannot call the default constructor, si=
nce there is no initial type to default construct. </div></blockquote><div>=
<br>Somehow that works just fine for tuple&lt;&gt;. variant&lt;&gt; would b=
e exactly the same: a unit type.<br>=C2=A0</div></blockquote><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"><div>Disallowing variant&lt;&gt; would simpl=
y make generic code more difficult with no benefit.<br></div></blockquote><=
div><br>It would make generic code <i>slightly</i> more difficult.<br><br>F=
urthermore, what benefit would there be in allowing generic code to constru=
ct such a type? Even if we invent some default construction syntax that all=
ows it to exist, basically ever named member function either accomplishes n=
othing or cannot return a meaningful value.<br><br>`index`? What value coul=
d it possibly return?<br><br>`emplace`? No types to construct.<br><br>`vali=
d`? The variant cannot perform any operation to cause it to become invalid.=
<br><br>The various namespace-scoped operators? No meaningful implementatio=
n.<br><br>`std::get`? Can&#39;t call it.<br><br>`std::holds_alternative`? A=
lways returns false.<br><br>`std::visit`? What would that even do?<br><br>S=
o exactly what operations are you planning to do here?<br><br>At the end of=
 the day, `variant` is not a `tuple`, so judging it by that metric is simpl=
y wrongheaded. `tuple` is rather like a struct, so it makes sense for it to=
 not have any types. An empty struct is a reasonable construct to talk abou=
t.<br><br>A never-empty `variant` with no types is not a reasonable constru=
ct. A never-empty discriminated union must have at least one available opti=
on.<br><br>Can you provide a useful example of generic code that would need=
 to declare such a type and actually use it?<br></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 />

------=_Part_9560_765020674.1446133363905--
------=_Part_9559_1269576667.1446133363905--

.

------=_Part_288_1374219965.1446134177609
Content-Type: multipart/alternative;
 boundary="----=_Part_289_527814689.1446134177610"

------=_Part_289_527814689.1446134177610
Content-Type: text/plain; charset=UTF-8

On Thursday, October 29, 2015 at 3:42:44 PM UTC, Nicol Bolas wrote:
>
> On Thursday, October 29, 2015 at 10:11:24 AM UTC-4, Giovanni Piero Deretta
> wrote:
>>
>> On Thursday, October 29, 2015 at 1:34:20 PM UTC, Nicol Bolas wrote:
>>>
>>> On Thursday, October 29, 2015 at 8:24:03 AM UTC-4, Larry Evans wrote:
>>>>
>>>> In the proposal:
>>>>
>>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4542.pdf
>>>>
>>>> I found no specific prohibition of std::variant<>; however,
>>>> there was an implied prohibition on page 22 where it states
>>>> that for constructor variant(), a T_0 is constructed where
>>>> T_0 is the 1st alternative; however, if the variant being
>>>> constructed is std::variant<>, then there is no T_0; hence,
>>>> one must infer that std:variant<> is *not* allowed.
>>>>
>>>> In contrast, for std::tuple, std::tuple<> is allowed, at least
>>>> according to:
>>>>
>>>> http://en.cppreference.com/w/cpp/utility/tuple
>>>>
>>>> Why should an empty tuple be allowed but not an empty
>>>> variant?  There is the empty product type as well as the
>>>> empty sum type in category theory:
>>>>
>>>> https://en.wikipedia.org/wiki/Product_%28category_theory%29
>>>> https://en.wikipedia.org/wiki/Coproduct
>>>
>>>
>>> We shouldn't add features based on "theory". We should add them based on
>>> utility.
>>>
>>>
>> Theory, without the "scary quotes" is still a good way to guide design.
>>
>>
>>> A `tuple` that has no types is possible for 2 reasons:
>>>
>>> 1: It allows you to create a `tuple` from any parameter pack via
>>> `make_tuple`, without having to check if it's empty.
>>>
>>> 2: It still makes sense as an object.
>>>
>>> #1 doesn't apply to `variant`, because it's only one of the types, not
>>> all of them. You wouldn't use a parameter pack to initialize one. You could
>>> use a template argument pack to declare a variant over a specific set of
>>> types, but that's a different matter.
>>>
>>>
>> how's a different matter?
>>
>>
>>> #2 is the bigger sticking point. The N4542 `variant` is not allowed to
>>> be empty; every (non-broken) `variant` instance must hold an object that is
>>> one of its specified types. So... which one is it? If there are no
>>> specified types, then what does the `variant` contain? For any `variant`
>>> instance, there must be *something* a user can pass to `get` to
>>> retrieve a value.
>>>
>>
>> exactly the same is true for a tuple. A tuple can't be empty, still
>> tuple<> is just fine and it is not an empty tuple. 'get' would be a compile
>> time error for variant<> as it is for tuple<>
>>
>>
>>>
>>> Also, how would you construct one? You obviously cannot call one of the
>>> typed/indexed constructors, because there are no types/indices. You cannot
>>> call the default constructor, since there is no initial type to default
>>> construct.
>>>
>>
>> Somehow that works just fine for tuple<>. variant<> would be exactly the
>> same: a unit type.
>>
>>
> Disallowing variant<> would simply make generic code more difficult with
>> no benefit.
>>
>
> It would make generic code *slightly* more difficult.
>
> Furthermore, what benefit would there be in allowing generic code to
> construct such a type? Even if we invent some default construction syntax
> that allows it to exist, basically ever named member function either
> accomplishes nothing or cannot return a meaningful value.
>
> `index`? What value could it possibly return?
>
> `emplace`? No types to construct.
>
> `valid`? The variant cannot perform any operation to cause it to become
> invalid.
>
> The various namespace-scoped operators? No meaningful implementation.
>
> `std::get`? Can't call it.
>
> `std::holds_alternative`? Always returns false.
>
> `std::visit`? What would that even do?
>
> So exactly what operations are you planning to do here?
>
> At the end of the day, `variant` is not a `tuple`, so judging it by that
> metric is simply wrongheaded. `tuple` is rather like a struct, so it makes
> sense for it to not have any types. An empty struct is a reasonable
> construct to talk about.
>
> A never-empty `variant` with no types is not a reasonable construct. A
> never-empty discriminated union must have at least one available option.
>
> Can you provide a useful example of generic code that would need to
> declare such a type and actually use it?
>

template<class... T>
variant<T...> runtime_get(std::tuple<T...>, int index);


--

---
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/.

------=_Part_289_527814689.1446134177610
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thursday, October 29, 2015 at 3:42:44 PM UTC, Nicol Bolas wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;">On Thursday, October 29, 2015 at 10:11=
:24 AM UTC-4, Giovanni Piero Deretta wrote:<blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">On Thursday, October 29, 2015 at 1:34:20 PM UTC, Nicol Bolas wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">On Thursday, October 29, 2015 at 8:=
24:03 AM UTC-4, Larry Evans wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
>In the proposal:
<br>
<br><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n454=
2.pdf" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;h=
ttp://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2F=
wg21%2Fdocs%2Fpapers%2F2015%2Fn4542.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCN=
E6O9TY8hE19VDKZfRlWZdiylnyIA&#39;;return true;" onclick=3D"this.href=3D&#39=
;http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%=
2Fwg21%2Fdocs%2Fpapers%2F2015%2Fn4542.pdf\46sa\75D\46sntz\0751\46usg\75AFQj=
CNE6O9TY8hE19VDKZfRlWZdiylnyIA&#39;;return true;">http://www.open-std.org/j=
tc1/<wbr>sc22/wg21/docs/papers/2015/<wbr>n4542.pdf</a>
<br>
<br>I found no specific prohibition of std::variant&lt;&gt;; however,
<br>there was an implied prohibition on page 22 where it states
<br>that for constructor variant(), a T_0 is constructed where
<br>T_0 is the 1st alternative; however, if the variant being
<br>constructed is std::variant&lt;&gt;, then there is no T_0; hence,
<br>one must infer that std:variant&lt;&gt; is *not* allowed.
<br>
<br>In contrast, for std::tuple, std::tuple&lt;&gt; is allowed, at least
<br>according to:
<br>
<br><a href=3D"http://en.cppreference.com/w/cpp/utility/tuple" rel=3D"nofol=
low" target=3D"_blank" onmousedown=3D"this.href=3D&#39;http://www.google.co=
m/url?q\75http%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Futility%2Ftuple\46sa=
\75D\46sntz\0751\46usg\75AFQjCNFhEcHf_r7j_w7vjkN8SpoqFeRmcw&#39;;return tru=
e;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2F=
en.cppreference.com%2Fw%2Fcpp%2Futility%2Ftuple\46sa\75D\46sntz\0751\46usg\=
75AFQjCNFhEcHf_r7j_w7vjkN8SpoqFeRmcw&#39;;return true;">http://en.cpprefere=
nce.com/w/<wbr>cpp/utility/tuple</a>
<br>
<br>Why should an empty tuple be allowed but not an empty
<br>variant? =C2=A0There is the empty product type as well as the
<br>empty sum type in category theory:
<br>
<br><a href=3D"https://en.wikipedia.org/wiki/Product_%28category_theory%29"=
 rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;https:/=
/www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FProduct_%25=
28category_theory%2529\46sa\75D\46sntz\0751\46usg\75AFQjCNHk1utLAEmEcpIUC0p=
BscVa-QI3iA&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.goog=
le.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FProduct_%2528categor=
y_theory%2529\46sa\75D\46sntz\0751\46usg\75AFQjCNHk1utLAEmEcpIUC0pBscVa-QI3=
iA&#39;;return true;">https://en.wikipedia.org/wiki/<wbr>Product_%28categor=
y_theory%29</a>
<br><a href=3D"https://en.wikipedia.org/wiki/Coproduct" rel=3D"nofollow" ta=
rget=3D"_blank" onmousedown=3D"this.href=3D&#39;https://www.google.com/url?=
q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FCoproduct\46sa\75D\46sntz\0751\=
46usg\75AFQjCNFju455cAAwUR7in6JNT-N3jEg-dA&#39;;return true;" onclick=3D"th=
is.href=3D&#39;https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.or=
g%2Fwiki%2FCoproduct\46sa\75D\46sntz\0751\46usg\75AFQjCNFju455cAAwUR7in6JNT=
-N3jEg-dA&#39;;return true;">https://en.wikipedia.org/wiki/<wbr>Coproduct</=
a></blockquote><div><br>We shouldn&#39;t add features based on &quot;theory=
&quot;. We should add them based on utility.<br><br></div></blockquote><div=
><br>Theory, without the &quot;scary quotes&quot; is still a good way to gu=
ide design.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>A `=
tuple` that has no types is possible for 2 reasons:<br><br>1: It allows you=
 to create a `tuple` from any parameter pack via `make_tuple`, without havi=
ng to check if it&#39;s empty.<br><br>2: It still makes sense as an object.=
<br><br>#1 doesn&#39;t apply to `variant`, because it&#39;s only one of the=
 types, not all of them. You wouldn&#39;t use a parameter pack to initializ=
e one. You could use a template argument pack to declare a variant over a s=
pecific set of types, but that&#39;s a different matter.<br><br></div></blo=
ckquote><div><br>how&#39;s a different matter?<br>=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div>#2 is the bigger sticking point. The N4542 =
`variant` is not allowed to be empty; every (non-broken) `variant` instance=
 must hold an object that is one of its specified types. So... which one is=
 it? If there are no specified types, then what does the `variant` contain?=
 For any `variant` instance, there must be <i>something</i> a user can pass=
 to `get` to retrieve a value.<br></div></blockquote><div><br>exactly the s=
ame is true for a tuple. A tuple can&#39;t be empty, still tuple&lt;&gt; is=
 just fine and it is not an empty tuple. &#39;get&#39; would be a compile t=
ime error for variant&lt;&gt; as it is for tuple&lt;&gt;<br>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div><br>Also, how would you construct=
 one? You obviously cannot call one of the typed/indexed constructors, beca=
use there are no types/indices. You cannot call the default constructor, si=
nce there is no initial type to default construct. </div></blockquote><div>=
<br>Somehow that works just fine for tuple&lt;&gt;. variant&lt;&gt; would b=
e exactly the same: a unit type.<br>=C2=A0</div></blockquote><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div>Disallowing variant&lt;&gt; would simply mak=
e generic code more difficult with no benefit.<br></div></blockquote><div><=
br>It would make generic code <i>slightly</i> more difficult.<br><br>Furthe=
rmore, what benefit would there be in allowing generic code to construct su=
ch a type? Even if we invent some default construction syntax that allows i=
t to exist, basically ever named member function either accomplishes nothin=
g or cannot return a meaningful value.<br><br>`index`? What value could it =
possibly return?<br><br>`emplace`? No types to construct.<br><br>`valid`? T=
he variant cannot perform any operation to cause it to become invalid.<br><=
br>The various namespace-scoped operators? No meaningful implementation.<br=
><br>`std::get`? Can&#39;t call it.<br><br>`std::holds_alternative`? Always=
 returns false.<br><br>`std::visit`? What would that even do?<br><br>So exa=
ctly what operations are you planning to do here?<br><br>At the end of the =
day, `variant` is not a `tuple`, so judging it by that metric is simply wro=
ngheaded. `tuple` is rather like a struct, so it makes sense for it to not =
have any types. An empty struct is a reasonable construct to talk about.<br=
><br>A never-empty `variant` with no types is not a reasonable construct. A=
 never-empty discriminated union must have at least one available option.<b=
r><br>Can you provide a useful example of generic code that would need to d=
eclare such a type and actually use it?<br></div></blockquote><div><br>temp=
late&lt;class... T&gt;<br>variant&lt;T...&gt; runtime_get(std::tuple&lt;T..=
..&gt;, int index);<br>=C2=A0</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 />

------=_Part_289_527814689.1446134177610--
------=_Part_288_1374219965.1446134177609--

.

------=_Part_9515_830792959.1446135344296
Content-Type: multipart/alternative;
 boundary="----=_Part_9516_1825604522.1446135344297"

------=_Part_9516_1825604522.1446135344297
Content-Type: text/plain; charset=UTF-8



On Thursday, October 29, 2015 at 11:56:18 AM UTC-4, Giovanni Piero Deretta
wrote:
>
> On Thursday, October 29, 2015 at 3:42:44 PM UTC, Nicol Bolas wrote:
>>
>> On Thursday, October 29, 2015 at 10:11:24 AM UTC-4, Giovanni Piero
>> Deretta wrote:
>>>
>>> On Thursday, October 29, 2015 at 1:34:20 PM UTC, Nicol Bolas wrote:
>>>>
>>>> On Thursday, October 29, 2015 at 8:24:03 AM UTC-4, Larry Evans wrote:
>>>>>
>>>>> In the proposal:
>>>>>
>>>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4542.pdf
>>>>>
>>>>> I found no specific prohibition of std::variant<>; however,
>>>>> there was an implied prohibition on page 22 where it states
>>>>> that for constructor variant(), a T_0 is constructed where
>>>>> T_0 is the 1st alternative; however, if the variant being
>>>>> constructed is std::variant<>, then there is no T_0; hence,
>>>>> one must infer that std:variant<> is *not* allowed.
>>>>>
>>>>> In contrast, for std::tuple, std::tuple<> is allowed, at least
>>>>> according to:
>>>>>
>>>>> http://en.cppreference.com/w/cpp/utility/tuple
>>>>>
>>>>> Why should an empty tuple be allowed but not an empty
>>>>> variant?  There is the empty product type as well as the
>>>>> empty sum type in category theory:
>>>>>
>>>>> https://en.wikipedia.org/wiki/Product_%28category_theory%29
>>>>> https://en.wikipedia.org/wiki/Coproduct
>>>>
>>>>
>>>> We shouldn't add features based on "theory". We should add them based
>>>> on utility.
>>>>
>>>>
>>> Theory, without the "scary quotes" is still a good way to guide design.
>>>
>>>
>>>> A `tuple` that has no types is possible for 2 reasons:
>>>>
>>>> 1: It allows you to create a `tuple` from any parameter pack via
>>>> `make_tuple`, without having to check if it's empty.
>>>>
>>>> 2: It still makes sense as an object.
>>>>
>>>> #1 doesn't apply to `variant`, because it's only one of the types, not
>>>> all of them. You wouldn't use a parameter pack to initialize one. You could
>>>> use a template argument pack to declare a variant over a specific set of
>>>> types, but that's a different matter.
>>>>
>>>>
>>> how's a different matter?
>>>
>>>
>>>> #2 is the bigger sticking point. The N4542 `variant` is not allowed to
>>>> be empty; every (non-broken) `variant` instance must hold an object that is
>>>> one of its specified types. So... which one is it? If there are no
>>>> specified types, then what does the `variant` contain? For any `variant`
>>>> instance, there must be *something* a user can pass to `get` to
>>>> retrieve a value.
>>>>
>>>
>>> exactly the same is true for a tuple. A tuple can't be empty, still
>>> tuple<> is just fine and it is not an empty tuple. 'get' would be a compile
>>> time error for variant<> as it is for tuple<>
>>>
>>>
>>>>
>>>> Also, how would you construct one? You obviously cannot call one of the
>>>> typed/indexed constructors, because there are no types/indices. You cannot
>>>> call the default constructor, since there is no initial type to default
>>>> construct.
>>>>
>>>
>>> Somehow that works just fine for tuple<>. variant<> would be exactly the
>>> same: a unit type.
>>>
>>>
>> Disallowing variant<> would simply make generic code more difficult with
>>> no benefit.
>>>
>>
>> It would make generic code *slightly* more difficult.
>>
>> Furthermore, what benefit would there be in allowing generic code to
>> construct such a type? Even if we invent some default construction syntax
>> that allows it to exist, basically ever named member function either
>> accomplishes nothing or cannot return a meaningful value.
>>
>> `index`? What value could it possibly return?
>>
>> `emplace`? No types to construct.
>>
>> `valid`? The variant cannot perform any operation to cause it to become
>> invalid.
>>
>> The various namespace-scoped operators? No meaningful implementation.
>>
>> `std::get`? Can't call it.
>>
>> `std::holds_alternative`? Always returns false.
>>
>> `std::visit`? What would that even do?
>>
>> So exactly what operations are you planning to do here?
>>
>> At the end of the day, `variant` is not a `tuple`, so judging it by that
>> metric is simply wrongheaded. `tuple` is rather like a struct, so it makes
>> sense for it to not have any types. An empty struct is a reasonable
>> construct to talk about.
>>
>> A never-empty `variant` with no types is not a reasonable construct. A
>> never-empty discriminated union must have at least one available option.
>>
>> Can you provide a useful example of generic code that would need to
>> declare such a type and actually use it?
>>
>
> template<class... T>
> variant<T...> runtime_get(std::tuple<T...>, int index);
>

It will give a compilation error if you pass nothing in `T`. *Which it
should*, since there is nothing that `runtime_get` could possibly return.

--

---
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/.

------=_Part_9516_1825604522.1446135344297
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br>On Thursday, October 29, 2015 at 11:56:18 AM UTC-4, Giovanni Piero =
Deretta wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Thursday, Oct=
ober 29, 2015 at 3:42:44 PM UTC, Nicol Bolas wrote:<blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">On Thursday, October 29, 2015 at 10:11:24 AM UTC-4, Giovann=
i Piero Deretta wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;m=
argin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On Thursday, =
October 29, 2015 at 1:34:20 PM UTC, Nicol Bolas wrote:<blockquote class=3D"=
gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid=
;padding-left:1ex">On Thursday, October 29, 2015 at 8:24:03 AM UTC-4, Larry=
 Evans wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex">In the proposal:
<br>
<br><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n454=
2.pdf" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;h=
ttp://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2F=
wg21%2Fdocs%2Fpapers%2F2015%2Fn4542.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCN=
E6O9TY8hE19VDKZfRlWZdiylnyIA&#39;;return true;" onclick=3D"this.href=3D&#39=
;http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%=
2Fwg21%2Fdocs%2Fpapers%2F2015%2Fn4542.pdf\46sa\75D\46sntz\0751\46usg\75AFQj=
CNE6O9TY8hE19VDKZfRlWZdiylnyIA&#39;;return true;">http://www.open-std.org/j=
tc1/<wbr>sc22/wg21/docs/papers/2015/<wbr>n4542.pdf</a>
<br>
<br>I found no specific prohibition of std::variant&lt;&gt;; however,
<br>there was an implied prohibition on page 22 where it states
<br>that for constructor variant(), a T_0 is constructed where
<br>T_0 is the 1st alternative; however, if the variant being
<br>constructed is std::variant&lt;&gt;, then there is no T_0; hence,
<br>one must infer that std:variant&lt;&gt; is *not* allowed.
<br>
<br>In contrast, for std::tuple, std::tuple&lt;&gt; is allowed, at least
<br>according to:
<br>
<br><a href=3D"http://en.cppreference.com/w/cpp/utility/tuple" rel=3D"nofol=
low" target=3D"_blank" onmousedown=3D"this.href=3D&#39;http://www.google.co=
m/url?q\75http%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Futility%2Ftuple\46sa=
\75D\46sntz\0751\46usg\75AFQjCNFhEcHf_r7j_w7vjkN8SpoqFeRmcw&#39;;return tru=
e;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2F=
en.cppreference.com%2Fw%2Fcpp%2Futility%2Ftuple\46sa\75D\46sntz\0751\46usg\=
75AFQjCNFhEcHf_r7j_w7vjkN8SpoqFeRmcw&#39;;return true;">http://en.cpprefere=
nce.com/w/<wbr>cpp/utility/tuple</a>
<br>
<br>Why should an empty tuple be allowed but not an empty
<br>variant? =C2=A0There is the empty product type as well as the
<br>empty sum type in category theory:
<br>
<br><a href=3D"https://en.wikipedia.org/wiki/Product_%28category_theory%29"=
 rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;https:/=
/www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FProduct_%25=
28category_theory%2529\46sa\75D\46sntz\0751\46usg\75AFQjCNHk1utLAEmEcpIUC0p=
BscVa-QI3iA&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.goog=
le.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FProduct_%2528categor=
y_theory%2529\46sa\75D\46sntz\0751\46usg\75AFQjCNHk1utLAEmEcpIUC0pBscVa-QI3=
iA&#39;;return true;">https://en.wikipedia.org/wiki/<wbr>Product_%28categor=
y_theory%29</a>
<br><a href=3D"https://en.wikipedia.org/wiki/Coproduct" rel=3D"nofollow" ta=
rget=3D"_blank" onmousedown=3D"this.href=3D&#39;https://www.google.com/url?=
q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FCoproduct\46sa\75D\46sntz\0751\=
46usg\75AFQjCNFju455cAAwUR7in6JNT-N3jEg-dA&#39;;return true;" onclick=3D"th=
is.href=3D&#39;https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.or=
g%2Fwiki%2FCoproduct\46sa\75D\46sntz\0751\46usg\75AFQjCNFju455cAAwUR7in6JNT=
-N3jEg-dA&#39;;return true;">https://en.wikipedia.org/wiki/<wbr>Coproduct</=
a></blockquote><div><br>We shouldn&#39;t add features based on &quot;theory=
&quot;. We should add them based on utility.<br><br></div></blockquote><div=
><br>Theory, without the &quot;scary quotes&quot; is still a good way to gu=
ide design.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>A `=
tuple` that has no types is possible for 2 reasons:<br><br>1: It allows you=
 to create a `tuple` from any parameter pack via `make_tuple`, without havi=
ng to check if it&#39;s empty.<br><br>2: It still makes sense as an object.=
<br><br>#1 doesn&#39;t apply to `variant`, because it&#39;s only one of the=
 types, not all of them. You wouldn&#39;t use a parameter pack to initializ=
e one. You could use a template argument pack to declare a variant over a s=
pecific set of types, but that&#39;s a different matter.<br><br></div></blo=
ckquote><div><br>how&#39;s a different matter?<br>=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div>#2 is the bigger sticking point. The N4542 =
`variant` is not allowed to be empty; every (non-broken) `variant` instance=
 must hold an object that is one of its specified types. So... which one is=
 it? If there are no specified types, then what does the `variant` contain?=
 For any `variant` instance, there must be <i>something</i> a user can pass=
 to `get` to retrieve a value.<br></div></blockquote><div><br>exactly the s=
ame is true for a tuple. A tuple can&#39;t be empty, still tuple&lt;&gt; is=
 just fine and it is not an empty tuple. &#39;get&#39; would be a compile t=
ime error for variant&lt;&gt; as it is for tuple&lt;&gt;<br>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div><br>Also, how would you construct=
 one? You obviously cannot call one of the typed/indexed constructors, beca=
use there are no types/indices. You cannot call the default constructor, si=
nce there is no initial type to default construct. </div></blockquote><div>=
<br>Somehow that works just fine for tuple&lt;&gt;. variant&lt;&gt; would b=
e exactly the same: a unit type.<br>=C2=A0</div></blockquote><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div>Disallowing variant&lt;&gt; would simply mak=
e generic code more difficult with no benefit.<br></div></blockquote><div><=
br>It would make generic code <i>slightly</i> more difficult.<br><br>Furthe=
rmore, what benefit would there be in allowing generic code to construct su=
ch a type? Even if we invent some default construction syntax that allows i=
t to exist, basically ever named member function either accomplishes nothin=
g or cannot return a meaningful value.<br><br>`index`? What value could it =
possibly return?<br><br>`emplace`? No types to construct.<br><br>`valid`? T=
he variant cannot perform any operation to cause it to become invalid.<br><=
br>The various namespace-scoped operators? No meaningful implementation.<br=
><br>`std::get`? Can&#39;t call it.<br><br>`std::holds_alternative`? Always=
 returns false.<br><br>`std::visit`? What would that even do?<br><br>So exa=
ctly what operations are you planning to do here?<br><br>At the end of the =
day, `variant` is not a `tuple`, so judging it by that metric is simply wro=
ngheaded. `tuple` is rather like a struct, so it makes sense for it to not =
have any types. An empty struct is a reasonable construct to talk about.<br=
><br>A never-empty `variant` with no types is not a reasonable construct. A=
 never-empty discriminated union must have at least one available option.<b=
r><br>Can you provide a useful example of generic code that would need to d=
eclare such a type and actually use it?<br></div></blockquote><div><br>temp=
late&lt;class... T&gt;<br>variant&lt;T...&gt; runtime_get(std::tuple&lt;T..=
..&gt;, int index);</div></blockquote><div><br>It will give a compilation er=
ror if you pass nothing in `T`. <i>Which it should</i>, since there is noth=
ing that `runtime_get` could possibly return. <br></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 />

------=_Part_9516_1825604522.1446135344297--
------=_Part_9515_830792959.1446135344296--

.

------=_Part_9523_1354327713.1446135712811
Content-Type: multipart/alternative;
 boundary="----=_Part_9524_390256632.1446135712812"

------=_Part_9524_390256632.1446135712812
Content-Type: text/plain; charset=UTF-8



On Thursday, October 29, 2015 at 12:15:44 PM UTC-4, Nicol Bolas wrote:
>
>
> template<class... T>
>> variant<T...> runtime_get(std::tuple<T...>, int index);
>>
>
> It will give a compilation error if you pass nothing in `T`. *Which it
> should*, since there is nothing that `runtime_get` could possibly return.
>

I want to make that a bit more clear. The implementation of `runtime_get`
must, at some point, call `std::get<>` with some compile-time index. If the
tuple has no types, then there is no way to call `std::get<>` on it with *any
index*. Therefore, `runtime_get` for an empty tuple is equally meaningless.

Yes, you could have a specialization for an empty `T...`. But that's
special case template code. So you could just as easily SFINAE-away
`runtime_get` if `T...` is empty.

--

---
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/.

------=_Part_9524_390256632.1446135712812
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, October 29, 2015 at 12:15:44 PM UTC-4=
, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br><block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div>template&lt;class... T&gt;<br>varian=
t&lt;T...&gt; runtime_get(std::tuple&lt;T...&gt;, int index);</div></blockq=
uote><div><br>It will give a compilation error if you pass nothing in `T`. =
<i>Which it should</i>, since there is nothing that `runtime_get` could pos=
sibly return. <br></div></blockquote><div><br>I want to make that a bit mor=
e clear. The implementation of `runtime_get` must, at some point, call `std=
::get&lt;&gt;` with some compile-time index. If the tuple has no types, the=
n there is no way to call `std::get&lt;&gt;` on it with <i>any index</i>. T=
herefore, `runtime_get` for an empty tuple is equally meaningless.<br><br>Y=
es, you could have a specialization for an empty `T...`. But that&#39;s spe=
cial case template code. So you could just as easily SFINAE-away `runtime_g=
et` if `T...` is empty.<br></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 />

------=_Part_9524_390256632.1446135712812--
------=_Part_9523_1354327713.1446135712811--

.

------=_Part_5965_1548034059.1446137430093
Content-Type: multipart/alternative;
 boundary="----=_Part_5966_503292783.1446137430094"

------=_Part_5966_503292783.1446137430094
Content-Type: text/plain; charset=UTF-8

On Thursday, October 29, 2015 at 4:21:52 PM UTC, Nicol Bolas wrote:
>
>
>
> On Thursday, October 29, 2015 at 12:15:44 PM UTC-4, Nicol Bolas wrote:
>>
>>
>> template<class... T>
>>> variant<T...> runtime_get(std::tuple<T...>, int index);
>>>
>>
>> It will give a compilation error if you pass nothing in `T`. *Which it
>> should*, since there is nothing that `runtime_get` could possibly
>> return.
>>
>
> I want to make that a bit more clear. The implementation of `runtime_get`
> must, at some point, call `std::get<>` with some compile-time index. If the
> tuple has no types, then there is no way to call `std::get<>` on it with *any
> index*.
>

template<class... T>
variant<T...> get_impl(int i, std::integral_constant<int, -1>,
tuple<T...>&) { throw std::out_of_range(); }

template<class... T, int j>
variant<T...> get_impl(int i, std::integral_constant<int, j>, tuple<T...>&x
)  {
     return i == j? get<j>(x) : get_impl(i, integral_constant<int, j-1>{},
x);
}

template<class... T>
variant<T...> runtime_get(int i, tuple<T...>& x) { return get_impl(i,
std::integral_constant<int, sizeof...(T)-1>{}, x);

The above works for any variant, including variant<>, without any special
handling. If variant<> is not valid, suddenly any user of runtime_get need
handle the corner case.

-- gpd

--

---
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/.

------=_Part_5966_503292783.1446137430094
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thursday, October 29, 2015 at 4:21:52 PM UTC, Nicol Bolas wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><br>On Thursday, =
October 29, 2015 at 12:15:44 PM UTC-4, Nicol Bolas wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>tem=
plate&lt;class... T&gt;<br>variant&lt;T...&gt; runtime_get(std::tuple&lt;T.=
...&gt;, int index);</div></blockquote><div><br>It will give a compilation e=
rror if you pass nothing in `T`. <i>Which it should</i>, since there is not=
hing that `runtime_get` could possibly return. <br></div></blockquote><div>=
<br>I want to make that a bit more clear. The implementation of `runtime_ge=
t` must, at some point, call `std::get&lt;&gt;` with some compile-time inde=
x. If the tuple has no types, then there is no way to call `std::get&lt;&gt=
;` on it with <i>any index</i>. </div></div></blockquote><div><br><div styl=
e=3D"text-align: left;"><div dir=3D"ltr"><div>template&lt;class... T&gt;<br=
>variant&lt;T...&gt;
 get_impl(int i, std::integral_constant&lt;int, -1&gt;,=20
tuple&lt;T...&gt;&amp;) { throw std::out_of_range(); }<br><br>template&lt;c=
lass... T, int j&gt;<br>variant&lt;T...&gt; get_impl(int i, std::integral_c=
onstant&lt;int, j&gt;, tuple&lt;T...&gt;&amp;x )=C2=A0 { <br>=C2=A0=C2=A0=
=C2=A0=C2=A0 return i =3D=3D j? get&lt;j&gt;(x) : get_impl(i, integral_cons=
tant&lt;int, j-1&gt;{}, x);<br>}<br><br>template&lt;class... T&gt;<br>varia=
nt&lt;T...&gt;
 runtime_get(int i, tuple&lt;T...&gt;&amp; x) { return get_impl(i,=20
std::integral_constant&lt;int, sizeof...(T)-1&gt;{}, x);<br><br>The=20
above works for any variant, including variant&lt;&gt;, without any=20
special handling. If variant&lt;&gt; is not valid, suddenly any user of=20
runtime_get need handle the corner case. </div></div>=C2=A0</div></div><div=
 dir=3D"ltr"><div>-- gpd <br></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 />

------=_Part_5966_503292783.1446137430094--
------=_Part_5965_1548034059.1446137430093--

.

This is a multi-part message in MIME format.
--------------060708090301010207070109
Content-Type: text/plain; charset=UTF-8; format=flowed

Am 29.10.2015 um 17:21 schrieb Nicol Bolas:
>
>
> On Thursday, October 29, 2015 at 12:15:44 PM UTC-4, Nicol Bolas wrote:
>
>
>         template<class... T>
>         variant<T...> runtime_get(std::tuple<T...>, int index);
>
>
>     It will give a compilation error if you pass nothing in `T`.
>     /Which it should/, since there is nothing that `runtime_get` could
>     possibly return.
>
>
> I want to make that a bit more clear. The implementation of
> `runtime_get` must, at some point, call `std::get<>` with some
> compile-time index. If the tuple has no types, then there is no way to
> call `std::get<>` on it with /any index/. Therefore, `runtime_get` for
> an empty tuple is equally meaningless.
Incorrect. runtime_get needs a plan B if the integer is out of range. If
the parameter pack is empty its expansion would not generate any code to
call std::get<> causing runtime_get to always fall back on plan B.
>
> Yes, you could have a specialization for an empty `T...`. But that's
> special case template code. So you could just as easily SFINAE-away
> `runtime_get` if `T...` is empty.
Or it is implemented in such a way that expanding an empty parameter
pack still works.

--

---
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/.

--------------060708090301010207070109
Content-Type: text/html; charset=UTF-8

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Am 29.10.2015 um 17:21 schrieb Nicol Bolas:<br>
    <blockquote
      cite="mid:5ba22a23-f2a4-4105-ba9c-7eae32dadb8f@isocpp.org"
      type="cite">
      <div dir="ltr"><br>
        <br>
        On Thursday, October 29, 2015 at 12:15:44 PM UTC-4, Nicol Bolas
        wrote:
        <blockquote class="gmail_quote" style="margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>
          <blockquote class="gmail_quote"
            style="margin:0;margin-left:0.8ex;border-left:1px #ccc
            solid;padding-left:1ex">
            <div>template&lt;class... T&gt;<br>
              variant&lt;T...&gt; runtime_get(std::tuple&lt;T...&gt;,
              int index);</div>
          </blockquote>
          <div><br>
            It will give a compilation error if you pass nothing in `T`.
            <i>Which it should</i>, since there is nothing that
            `runtime_get` could possibly return. <br>
          </div>
        </blockquote>
        <div><br>
          I want to make that a bit more clear. The implementation of
          `runtime_get` must, at some point, call `std::get&lt;&gt;`
          with some compile-time index. If the tuple has no types, then
          there is no way to call `std::get&lt;&gt;` on it with <i>any
            index</i>. Therefore, `runtime_get` for an empty tuple is
          equally meaningless.<br>
        </div>
      </div>
    </blockquote>
    Incorrect. runtime_get needs a plan B if the integer is out of
    range. If the parameter pack is empty its expansion would not
    generate any code to call std::get&lt;&gt; causing runtime_get to
    always fall back on plan B.<br>
    <blockquote
      cite="mid:5ba22a23-f2a4-4105-ba9c-7eae32dadb8f@isocpp.org"
      type="cite">
      <div dir="ltr">
        <div><br>
          Yes, you could have a specialization for an empty `T...`. But
          that's special case template code. So you could just as easily
          SFINAE-away `runtime_get` if `T...` is empty.<br>
        </div>
      </div>
    </blockquote>
    Or it is implemented in such a way that expanding an empty parameter
    pack still works.<br>
    <br>
  </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 email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

--------------060708090301010207070109--

.

------=_Part_686_1252822184.1446138096929
Content-Type: multipart/alternative;
 boundary="----=_Part_687_2103124687.1446138096929"

------=_Part_687_2103124687.1446138096929
Content-Type: text/plain; charset=UTF-8



On Thursday, October 29, 2015 at 12:51:14 PM UTC-4, Miro Knejp wrote:
>
> Am 29.10.2015 um 17:21 schrieb Nicol Bolas:
>
> On Thursday, October 29, 2015 at 12:15:44 PM UTC-4, Nicol Bolas wrote:
>>
>>
>> template<class... T>
>>> variant<T...> runtime_get(std::tuple<T...>, int index);
>>>
>>
>> It will give a compilation error if you pass nothing in `T`. *Which it
>> should*, since there is nothing that `runtime_get` could possibly
>> return.
>>
>
> I want to make that a bit more clear. The implementation of `runtime_get`
> must, at some point, call `std::get<>` with some compile-time index. If the
> tuple has no types, then there is no way to call `std::get<>` on it with *any
> index*. Therefore, `runtime_get` for an empty tuple is equally
> meaningless.
>
> Incorrect. runtime_get needs a plan B if the integer is out of range. If
> the parameter pack is empty its expansion would not generate any code to
> call std::get<> causing runtime_get to always fall back on plan B.
>

OK, fair enough. Since it cannot possibly construct a return value in that
instance, the only viable plan B... is to throw something.

A function instantiation that is *guaranteed* to throw, that can never do
anything other than throw, isn't the most useful thing in the world. It'd
say that the user of such a function would prefer getting a compilation
error.

I know I would. But that's just me.

--

---
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/.

------=_Part_687_2103124687.1446138096929
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br>On Thursday, October 29, 2015 at 12:51:14 PM UTC-4, Miro Knejp wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    Am 29.10.2015 um 17:21 schrieb Nicol Bolas:<br><blockquote type=3D"cite=
"><div dir=3D"ltr">
        On Thursday, October 29, 2015 at 12:15:44 PM UTC-4, Nicol Bolas
        wrote:
        <blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex"><br>
          <blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0=
..8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div>template&lt;class... T&gt;<br>
              variant&lt;T...&gt; runtime_get(std::tuple&lt;T...&gt;,
              int index);</div>
          </blockquote>
          <div><br>
            It will give a compilation error if you pass nothing in `T`.
            <i>Which it should</i>, since there is nothing that
            `runtime_get` could possibly return. <br>
          </div>
        </blockquote>
        <div><br>
          I want to make that a bit more clear. The implementation of
          `runtime_get` must, at some point, call `std::get&lt;&gt;`
          with some compile-time index. If the tuple has no types, then
          there is no way to call `std::get&lt;&gt;` on it with <i>any
            index</i>. Therefore, `runtime_get` for an empty tuple is
          equally meaningless.<br>
        </div>
      </div>
    </blockquote>
    Incorrect. runtime_get needs a plan B if the integer is out of
    range. If the parameter pack is empty its expansion would not
    generate any code to call std::get&lt;&gt; causing runtime_get to
    always fall back on plan B.<br></div></blockquote><div><br>OK, fair eno=
ugh. Since it cannot possibly construct a return value in that instance, th=
e only viable plan B... is to throw something.<br><br>A function instantiat=
ion that is <i>guaranteed</i> to throw, that can never do anything other th=
an throw, isn&#39;t the most useful thing in the world. It&#39;d say that t=
he user of such a function would prefer getting a compilation error.<br><br=
>I know I would. But that&#39;s just me.<br></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 />

------=_Part_687_2103124687.1446138096929--
------=_Part_686_1252822184.1446138096929--

.

This is a multi-part message in MIME format.
--------------000800080605040703060300
Content-Type: text/plain; charset=UTF-8; format=flowed

Am 29.10.2015 um 18:01 schrieb Nicol Bolas:
>
>
> On Thursday, October 29, 2015 at 12:51:14 PM UTC-4, Miro Knejp wrote:
>
>     Am 29.10.2015 um 17:21 schrieb Nicol Bolas:
>>     On Thursday, October 29, 2015 at 12:15:44 PM UTC-4, Nicol Bolas
>>     wrote:
>>
>>
>>             template<class... T>
>>             variant<T...> runtime_get(std::tuple<T...>, int index);
>>
>>
>>         It will give a compilation error if you pass nothing in `T`.
>>         /Which it should/, since there is nothing that `runtime_get`
>>         could possibly return.
>>
>>
>>     I want to make that a bit more clear. The implementation of
>>     `runtime_get` must, at some point, call `std::get<>` with some
>>     compile-time index. If the tuple has no types, then there is no
>>     way to call `std::get<>` on it with /any index/. Therefore,
>>     `runtime_get` for an empty tuple is equally meaningless.
>     Incorrect. runtime_get needs a plan B if the integer is out of
>     range. If the parameter pack is empty its expansion would not
>     generate any code to call std::get<> causing runtime_get to always
>     fall back on plan B.
>
>
> OK, fair enough. Since it cannot possibly construct a return value in
> that instance, the only viable plan B... is to throw something.
>
> A function instantiation that is /guaranteed/ to throw, that can never
> do anything other than throw, isn't the most useful thing in the
> world. It'd say that the user of such a function would prefer getting
> a compilation error.
>
> I know I would. But that's just me.
Empty tuples and variants are less likely to be handwritten but rather
appear in code that is already itself generic, so in that case I'd
prefer to have the empty parameter pack to "just work" as to not having
to manually special case it as long as the generic code doesn't generate
calls to the nonsense functions if the pack is empty. If one doesn't
want exceptions from runtime_get make it return optional<variant<T...>>
and problem solved.

--

---
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/.

--------------000800080605040703060300
Content-Type: text/html; charset=UTF-8

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Am 29.10.2015 um 18:01 schrieb Nicol Bolas:<br>
    <blockquote
      cite="mid:766f0667-b8f4-4a5c-b8d3-0952f265c1fc@isocpp.org"
      type="cite"><br>
      <br>
      On Thursday, October 29, 2015 at 12:51:14 PM UTC-4, Miro Knejp
      wrote:
      <blockquote class="gmail_quote" style="margin: 0;margin-left:
        0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
        <div bgcolor="#FFFFFF" text="#000000"> Am 29.10.2015 um 17:21
          schrieb Nicol Bolas:<br>
          <blockquote type="cite">
            <div dir="ltr"> On Thursday, October 29, 2015 at 12:15:44 PM
              UTC-4, Nicol Bolas wrote:
              <blockquote class="gmail_quote"
                style="margin:0;margin-left:0.8ex;border-left:1px #ccc
                solid;padding-left:1ex"><br>
                <blockquote class="gmail_quote"
                  style="margin:0;margin-left:0.8ex;border-left:1px #ccc
                  solid;padding-left:1ex">
                  <div>template&lt;class... T&gt;<br>
                    variant&lt;T...&gt;
                    runtime_get(std::tuple&lt;T...&gt;, int index);</div>
                </blockquote>
                <div><br>
                  It will give a compilation error if you pass nothing
                  in `T`. <i>Which it should</i>, since there is
                  nothing that `runtime_get` could possibly return. <br>
                </div>
              </blockquote>
              <div><br>
                I want to make that a bit more clear. The implementation
                of `runtime_get` must, at some point, call
                `std::get&lt;&gt;` with some compile-time index. If the
                tuple has no types, then there is no way to call
                `std::get&lt;&gt;` on it with <i>any index</i>.
                Therefore, `runtime_get` for an empty tuple is equally
                meaningless.<br>
              </div>
            </div>
          </blockquote>
          Incorrect. runtime_get needs a plan B if the integer is out of
          range. If the parameter pack is empty its expansion would not
          generate any code to call std::get&lt;&gt; causing runtime_get
          to always fall back on plan B.<br>
        </div>
      </blockquote>
      <div><br>
        OK, fair enough. Since it cannot possibly construct a return
        value in that instance, the only viable plan B... is to throw
        something.<br>
        <br>
        A function instantiation that is <i>guaranteed</i> to throw,
        that can never do anything other than throw, isn't the most
        useful thing in the world. It'd say that the user of such a
        function would prefer getting a compilation error.<br>
        <br>
        I know I would. But that's just me.<br>
      </div>
    </blockquote>
    Empty tuples and variants are less likely to be handwritten but
    rather appear in code that is already itself generic, so in that
    case I'd prefer to have the empty parameter pack to "just work" as
    to not having to manually special case it as long as the generic
    code doesn't generate calls to the nonsense functions if the pack is
    empty. If one doesn't want exceptions from runtime_get make it
    return optional&lt;variant&lt;T...&gt;&gt; and problem solved.<br>
    <br>
  </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 email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

--------------000800080605040703060300--

.

--047d7b3a82907f2a5a0523416b04
Content-Type: text/plain; charset=UTF-8

On Thu, Oct 29, 2015 at 12:50 PM, Giovanni Piero Deretta <
gpderetta@gmail.com> wrote:

> On Thursday, October 29, 2015 at 4:21:52 PM UTC, Nicol Bolas wrote:
>>
>>
>>
>> On Thursday, October 29, 2015 at 12:15:44 PM UTC-4, Nicol Bolas wrote:
>>>
>>>
>>> template<class... T>
>>>> variant<T...> runtime_get(std::tuple<T...>, int index);
>>>>
>>>
>>> It will give a compilation error if you pass nothing in `T`. *Which it
>>> should*, since there is nothing that `runtime_get` could possibly
>>> return.
>>>
>>
>> I want to make that a bit more clear. The implementation of `runtime_get`
>> must, at some point, call `std::get<>` with some compile-time index. If the
>> tuple has no types, then there is no way to call `std::get<>` on it with *any
>> index*.
>>
>
> template<class... T>
> variant<T...> get_impl(int i, std::integral_constant<int, -1>,
> tuple<T...>&) { throw std::out_of_range(); }
>
> template<class... T, int j>
> variant<T...> get_impl(int i, std::integral_constant<int, j>,
> tuple<T...>&x )  {
>      return i == j? get<j>(x) : get_impl(i, integral_constant<int, j-1>{},
> x);
> }
>
> template<class... T>
> variant<T...> runtime_get(int i, tuple<T...>& x) { return get_impl(i,
> std::integral_constant<int, sizeof...(T)-1>{}, x);
>
> The above works for any variant, including variant<>, without any special
> handling. If variant<> is not valid, suddenly any user of runtime_get need
> handle the corner case.
>
>

This should work with the latest variant.

You can declare variant<>, just not construct one.

tuple<> empty;
auto x = runtime_get(0, empty);

That should compile, and throw.  x is of type variant<> and it is never
constructed because get_impl throws out_of_range.

Similarly this works:

struct zero {
    zero() = delete;
};

zero f() { throw 42; };

int main() {
    try {
        zero z = f();
    } catch(...) {
    }
    return 0;
}


-- gpd
>
> --
>
> ---
> 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/.
>

--

---
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/.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Thu, Oct 29, 2015 at 12:50 PM, Giovanni Piero Deretta <span dir=3D"l=
tr">&lt;<a href=3D"mailto:gpderetta@gmail.com" target=3D"_blank">gpderetta@=
gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><span class=3D"">On Thursday, October 29, 2015 at 4:21:52 PM UTC=
, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div =
dir=3D"ltr"><br><br>On Thursday, October 29, 2015 at 12:15:44 PM UTC-4, Nic=
ol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex"><div>template&lt;class... T&gt;=
<br>variant&lt;T...&gt; runtime_get(std::tuple&lt;T...&gt;, int index);</di=
v></blockquote><div><br>It will give a compilation error if you pass nothin=
g in `T`. <i>Which it should</i>, since there is nothing that `runtime_get`=
 could possibly return. <br></div></blockquote><div><br>I want to make that=
 a bit more clear. The implementation of `runtime_get` must, at some point,=
 call `std::get&lt;&gt;` with some compile-time index. If the tuple has no =
types, then there is no way to call `std::get&lt;&gt;` on it with <i>any in=
dex</i>. </div></div></blockquote></span><div><br><div style=3D"text-align:=
left"><div dir=3D"ltr"><div>template&lt;class... T&gt;<br>variant&lt;T...&g=
t;
 get_impl(int i, std::integral_constant&lt;int, -1&gt;,=20
tuple&lt;T...&gt;&amp;) { throw std::out_of_range(); }<br><br>template&lt;c=
lass... T, int j&gt;<br>variant&lt;T...&gt; get_impl(int i, std::integral_c=
onstant&lt;int, j&gt;, tuple&lt;T...&gt;&amp;x )=C2=A0 { <br>=C2=A0=C2=A0=
=C2=A0=C2=A0 return i =3D=3D j? get&lt;j&gt;(x) : get_impl(i, integral_cons=
tant&lt;int, j-1&gt;{}, x);<br>}<br><br>template&lt;class... T&gt;<br>varia=
nt&lt;T...&gt;
 runtime_get(int i, tuple&lt;T...&gt;&amp; x) { return get_impl(i,=20
std::integral_constant&lt;int, sizeof...(T)-1&gt;{}, x);<br><br>The=20
above works for any variant, including variant&lt;&gt;, without any=20
special handling. If variant&lt;&gt; is not valid, suddenly any user of=20
runtime_get need handle the corner case. </div></div><span class=3D""><font=
 color=3D"#888888">=C2=A0</font></span></div></div></blockquote><div><br></=
div><div>This should work with the latest variant.<br><br></div><div>You ca=
n declare variant&lt;&gt;, just not construct one.<br><br></div><div>tuple&=
lt;&gt; empty;<br></div><div>auto x =3D runtime_get(0, empty);<br><br></div=
><div>That should compile, and throw.=C2=A0 x is of type variant&lt;&gt; an=
d it is never constructed because get_impl throws out_of_range.<br><br></di=
v><div>Similarly this works:<br><br>struct zero {<br>=C2=A0=C2=A0=C2=A0 zer=
o() =3D delete;<br>};<br><br>zero f() { throw 42; };<br><br>int main() {<br=
>=C2=A0=C2=A0=C2=A0 try {<br>=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 zero z =
=3D f();<br>=C2=A0=C2=A0=C2=A0 } catch(...) {<br>=C2=A0=C2=A0=C2=A0 }<br>=
=C2=A0=C2=A0=C2=A0 return 0;<br>}<br></div><div><br></div><div><br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex"><span class=3D""><font colo=
r=3D"#888888"><div dir=3D"ltr"><div>-- gpd <br></div></div></font></span><d=
iv class=3D""><div class=3D"h5">

<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" 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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></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 />

--047d7b3a82907f2a5a0523416b04--

.

------=_Part_9316_32557556.1446138894926
Content-Type: multipart/alternative;
 boundary="----=_Part_9317_49512963.1446138894926"

------=_Part_9317_49512963.1446138894926
Content-Type: text/plain; charset=UTF-8

On Thursday, October 29, 2015 at 12:50:30 PM UTC-4, Giovanni Piero Deretta
wrote:
>
> On Thursday, October 29, 2015 at 4:21:52 PM UTC, Nicol Bolas wrote:
>>
>>
>>
>> On Thursday, October 29, 2015 at 12:15:44 PM UTC-4, Nicol Bolas wrote:
>>>
>>>
>>> template<class... T>
>>>> variant<T...> runtime_get(std::tuple<T...>, int index);
>>>>
>>>
>>> It will give a compilation error if you pass nothing in `T`. *Which it
>>> should*, since there is nothing that `runtime_get` could possibly
>>> return.
>>>
>>
>> I want to make that a bit more clear. The implementation of `runtime_get`
>> must, at some point, call `std::get<>` with some compile-time index. If the
>> tuple has no types, then there is no way to call `std::get<>` on it with *any
>> index*.
>>
>
> template<class... T>
> variant<T...> get_impl(int i, std::integral_constant<int, -1>,
> tuple<T...>&) { throw std::out_of_range(); }
>
> template<class... T, int j>
> variant<T...> get_impl(int i, std::integral_constant<int, j>,
> tuple<T...>&x )  {
>      return i == j? get<j>(x) : get_impl(i, integral_constant<int, j-1>{},
> x);
> }
>
> template<class... T>
> variant<T...> runtime_get(int i, tuple<T...>& x) { return get_impl(i,
> std::integral_constant<int, sizeof...(T)-1>{}, x);
>

>
The above works for any variant, including variant<>, without any special
> handling. If variant<> is not valid, suddenly any user of runtime_get need
> handle the corner case.
>

Here's the thing: N4542 doesn't make `variant<>` invalid. What it does is
make it *not constructible* (at least, not its default constructor). So
your code would work fine, because it statically never attempts to
construct such a thing.

So where's the problem? You can't make one. You can't use one. But you can
stick it in a function's return type, so long as the function that tries to
return it never actually returns it.

Isn't that good enough?

--

---
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/.

------=_Part_9317_49512963.1446138894926
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thursday, October 29, 2015 at 12:50:30 PM UTC-4, Giovanni Piero Deretta =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Thursday, October 29,=
 2015 at 4:21:52 PM UTC, Nicol Bolas wrote:<blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><br><br>On Thursday, October 29, 2015 at 12:15:44 =
PM UTC-4, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div>template&lt;class... T&gt;<br>var=
iant&lt;T...&gt; runtime_get(std::tuple&lt;T...&gt;, int index);</div></blo=
ckquote><div><br>It will give a compilation error if you pass nothing in `T=
`. <i>Which it should</i>, since there is nothing that `runtime_get` could =
possibly return. <br></div></blockquote><div><br>I want to make that a bit =
more clear. The implementation of `runtime_get` must, at some point, call `=
std::get&lt;&gt;` with some compile-time index. If the tuple has no types, =
then there is no way to call `std::get&lt;&gt;` on it with <i>any index</i>=
.. </div></div></blockquote><div><br><div style=3D"text-align:left"><div dir=
=3D"ltr"><div>template&lt;class... T&gt;<br>variant&lt;T...&gt;
 get_impl(int i, std::integral_constant&lt;int, -1&gt;,=20
tuple&lt;T...&gt;&amp;) { throw std::out_of_range(); }<br><br>template&lt;c=
lass... T, int j&gt;<br>variant&lt;T...&gt; get_impl(int i, std::integral_c=
onstant&lt;int, j&gt;, tuple&lt;T...&gt;&amp;x )=C2=A0 { <br>=C2=A0=C2=A0=
=C2=A0=C2=A0 return i =3D=3D j? get&lt;j&gt;(x) : get_impl(i, integral_cons=
tant&lt;int, j-1&gt;{}, x);<br>}<br><br>template&lt;class... T&gt;<br>varia=
nt&lt;T...&gt;
 runtime_get(int i, tuple&lt;T...&gt;&amp; x) { return get_impl(i,=20
std::integral_constant&lt;int, sizeof...(T)-1&gt;{}, x);<br></div></div></d=
iv></div></blockquote><blockquote style=3D"margin: 0px 0px 0px 0.8ex; borde=
r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_qu=
ote"><div>=C2=A0</div></blockquote><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div><div style=3D"text-align:left"><div dir=3D"ltr"><div>The=20
above works for any variant, including variant&lt;&gt;, without any=20
special handling. If variant&lt;&gt; is not valid, suddenly any user of=20
runtime_get need handle the corner case.</div></div></div></div></blockquot=
e><div><br>Here&#39;s the thing: N4542 doesn&#39;t make `variant&lt;&gt;` i=
nvalid. What it does is make it <i>not constructible</i> (at least, not its=
 default constructor). So your code would work fine, because it statically =
never attempts to construct such a thing.<br><br>So where&#39;s the problem=
? You can&#39;t make one. You can&#39;t use one. But you can stick it in a =
function&#39;s return type, so long as the function that tries to return it=
 never actually returns it.<br><br>Isn&#39;t that good enough?<br></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 />

------=_Part_9317_49512963.1446138894926--
------=_Part_9316_32557556.1446138894926--

.

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

On Thu, Oct 29, 2015 at 5:23 AM, Larry Evans <cppljevans@suddenlink.net>
wrote:\
>
> Why should an empty tuple be allowed but not an empty
> variant?  There is the empty product type as well as the
> empty sum type in category theory:


This exact question was raised at the meeting and it was decided that there
would need to be a paper regarding what semantics would be expected. I've
suggested this as well several years ago, for boost::variant. Such cases
can come up generic code.

A quick example:

/////
template<class... Funs>
std::optional<std::variant<decltype(funs.second())...>>
execute_fun_by_name(std::string name, std::pair<std::string /*name*/,
Funs>... funs);
/////

You can imagine this is useful for something serving remote procedure
calls. It's given a bunch of named functions along with the name of which
function to execute. If there is no matching name to what the user
requests, it returns nullopt, otherwise it returns the result of the
function execution. In the case that the set of possible functions to
execute is 0, this resolves to std::optional<std::variant<>>. Execution of
the function also naturally resolves to always yielding nullopt. In generic
code, it's entirely possible that you encounter such a case.

In brief, when designing most things that are variadic, it's important to
cover the bounding case (usually 0). It's not always obvious why it's
important because those cases generally only appear in generic code, but
when you jump up to a level of abstraction higher, use cases often become
obvious.

As for what the semantics should be, that takes more investigation. I've
explored this before and I forget what my specific conclusion was. If I
recall correctly, I suggested that the type is instantiable, but it is not
actually a model of the variant concept (it doesn't provide which, get,
visit, etc. but the type is Regular). No matter what the semantics are, it
probably does need a paper that examines the use-cases in order to be sure
that whatever semantics are suggested actually make sense and are
consistent with what comes up in generic code.

--

---
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/.

--001a11c2e6ae6494d10523421def
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 T=
hu, Oct 29, 2015 at 5:23 AM, Larry Evans <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:cppljevans@suddenlink.net" target=3D"_blank">cppljevans@suddenlink.ne=
t</a>&gt;</span> wrote:\<blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Why should an empty tuple be allowed but not an empty<br>
variant?=C2=A0 There is the empty product type as well as the<br>
empty sum type in category theory:</blockquote><div><br></div><div>This exa=
ct question was raised at the meeting and it was decided that there would n=
eed to be a paper regarding what semantics would be expected. I&#39;ve sugg=
ested this as well several years ago, for boost::variant. Such cases can co=
me up generic code.</div><div><br></div><div>A quick example:<br></div><div=
><br></div><div>/////</div><div>template&lt;class... Funs&gt;</div><div>std=
::optional&lt;std::variant&lt;decltype(funs.second())...&gt;&gt;</div><div>=
execute_fun_by_name(std::string name, std::pair&lt;std::string /*name*/, Fu=
ns&gt;... funs);</div><div>/////</div><div><br></div><div>You can imagine t=
his is useful for something serving remote procedure calls. It&#39;s given =
a bunch of named functions along with the name of which function to execute=
.. If there is no matching name to what the user requests, it returns nullop=
t, otherwise it returns the result of the function execution. In the case t=
hat the set of possible functions to execute is 0, this resolves to std::op=
tional&lt;std::variant&lt;&gt;&gt;. Execution of the function also naturall=
y resolves to always yielding nullopt. In generic code, it&#39;s entirely p=
ossible that you encounter such a case.</div><div><br></div><div>In brief, =
when designing most things that are variadic, it&#39;s important to cover t=
he bounding case (usually 0). It&#39;s not always obvious why it&#39;s impo=
rtant because those cases generally only appear in generic code, but when y=
ou jump up to a level of abstraction higher, use cases often become obvious=
..</div><div><br></div><div>As for what the semantics should be, that takes =
more investigation. I&#39;ve explored this before and I forget what my spec=
ific conclusion was. If I recall correctly, I suggested that the type is in=
stantiable, but it is not actually a model of the variant concept (it doesn=
&#39;t provide which, get, visit, etc. but the type is Regular). No matter =
what the semantics are, it probably does need a paper that examines the use=
-cases in order to be sure that whatever semantics are suggested actually m=
ake sense and are consistent with what comes up in generic code.</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 />

--001a11c2e6ae6494d10523421def--

.

--047d7b41402876353b052342434f
Content-Type: text/plain; charset=UTF-8

On Thu, Oct 29, 2015 at 7:55 AM, Tony V E <tvaneerd@gmail.com> wrote:
>
> This has been discussed inside and outside the committee.
> The consensus is, I think, that variant<> should be a valid type, but you
> can't instantiate it, because it has 0 values.
>

I'm always skeptical of "0 value non-instantiable types", as I'm sure you
know. In practice, if it is to be useful in generic code, which is main
reason for supporting things like tuple<> and variant<>, you generally at
least need for the type to be able to be returned as a function result,
etc.. I'm not confident enough to state exactly what the semantics should
be without really exploring the use-cases in depth, but it would likely end
up being a monostate Regular type, much like std::tuple<>, but in this case
it would only have a subset of properties of variant<H, 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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--047d7b41402876353b052342434f
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 T=
hu, Oct 29, 2015 at 7:55 AM, Tony V E <span dir=3D"ltr">&lt;<a href=3D"mail=
to:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</span> =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_e=
xtra"><div class=3D"gmail_quote"><div>This has been discussed inside and ou=
tside the committee.<br></div><div>The consensus is, I think, that variant&=
lt;&gt; should be a valid type, but you can&#39;t instantiate it, because i=
t has 0 values.<br></div></div></div></div></blockquote><div><br></div><div=
>I&#39;m always skeptical of &quot;0 value non-instantiable types&quot;, as=
 I&#39;m sure you know. In practice, if it is to be useful in generic code,=
 which is main reason for supporting things like tuple&lt;&gt; and variant&=
lt;&gt;, you generally at least need for the type to be able to be returned=
 as a function result, etc.. I&#39;m not confident enough to state exactly =
what the semantics should be without really exploring the use-cases in dept=
h, but it would likely end up being a monostate Regular type, much like std=
::tuple&lt;&gt;, but in this case it would only have a subset of properties=
 of variant&lt;H, T...&gt;.</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 />

--047d7b41402876353b052342434f--

.

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

On Thu, Oct 29, 2015 at 2:13 PM, 'Matt Calabrese' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

> On Thu, Oct 29, 2015 at 7:55 AM, Tony V E <tvaneerd@gmail.com> wrote:
>>
>> This has been discussed inside and outside the committee.
>> The consensus is, I think, that variant<> should be a valid type, but you
>> can't instantiate it, because it has 0 values.
>>
>
> I'm always skeptical of "0 value non-instantiable types", as I'm sure you
> know.
>

Next you'll be asking for something crazy like making void Regular.  :-)


> In practice, if it is to be useful in generic code, which is main reason
> for supporting things like tuple<> and variant<>, you generally at least
> need for the type to be able to be returned as a function result, etc..
>

You can return it from functions, as long as those functions don't return.
:-)


> I'm not confident enough to state exactly what the semantics should be
> without really exploring the use-cases in depth, but it would likely end up
> being a monostate Regular type, much like std::tuple<>, but in this case it
> would only have a subset of properties of variant<H, T...>.
>

If you could create one, it would obviously be always invalid (or
corrupted_by_exception or whatever).  And things like get<float> wouldn't
compile, same way it doesn't compile for variant<int>.
I don't think it would be hard to specify.
I'm just not sure it is the correct thing to do.



--

>
> ---
> 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/.
>

--

---
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/.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Thu, Oct 29, 2015 at 2:13 PM, &#39;Matt Calabrese&#39; via ISO C++ S=
tandard - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-prop=
osals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"lt=
r"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D"">O=
n Thu, Oct 29, 2015 at 7:55 AM, Tony V E <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</spa=
n> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"=
><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>This has been d=
iscussed inside and outside the committee.<br></div><div>The consensus is, =
I think, that variant&lt;&gt; should be a valid type, but you can&#39;t ins=
tantiate it, because it has 0 values.<br></div></div></div></div></blockquo=
te><div><br></div></span><div>I&#39;m always skeptical of &quot;0 value non=
-instantiable types&quot;, as I&#39;m sure you know. </div></div></div></di=
v></blockquote><div><br></div><div>Next you&#39;ll be asking for something =
crazy like making void Regular.=C2=A0 :-)<br>=C2=A0<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
 rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_ex=
tra"><div class=3D"gmail_quote"><div>In practice, if it is to be useful in =
generic code, which is main reason for supporting things like tuple&lt;&gt;=
 and variant&lt;&gt;, you generally at least need for the type to be able t=
o be returned as a function result, etc..</div></div></div></div></blockquo=
te><div><br>You can return it from functions, as long as those functions do=
n&#39;t return. :-)<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_=
quote"><div> I&#39;m not confident enough to state exactly what the semanti=
cs should be without really exploring the use-cases in depth, but it would =
likely end up being a monostate Regular type, much like std::tuple&lt;&gt;,=
 but in this case it would only have a subset of properties of variant&lt;H=
, T...&gt;.</div></div></div></div></blockquote><div><br></div><div>If you =
could create one, it would obviously be always invalid (or corrupted_by_exc=
eption or whatever).=C2=A0 And things like get&lt;float&gt; wouldn&#39;t co=
mpile, same way it doesn&#39;t compile for variant&lt;int&gt;.<br>I don&#39=
;t think it would be hard to specify.<br></div><div>I&#39;m just not sure i=
t is the correct thing to do.<br></div><div><br></div><div><br></div><div>=
=C2=A0<br></div>-- <br><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><d=
iv class=3D""><div class=3D"h5">
<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" 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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></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 />

--001a11c264a401b53c0523427555--

.

--089e01175e4d23a47d0523429e0d
Content-Type: text/plain; charset=UTF-8

On Thu, Oct 29, 2015 at 11:27 AM, Tony V E <tvaneerd@gmail.com> wrote:

>
>
> On Thu, Oct 29, 2015 at 2:13 PM, 'Matt Calabrese' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
>
>> On Thu, Oct 29, 2015 at 7:55 AM, Tony V E <tvaneerd@gmail.com> wrote:
>>>
>>> This has been discussed inside and outside the committee.
>>> The consensus is, I think, that variant<> should be a valid type, but
>>> you can't instantiate it, because it has 0 values.
>>>
>>
>> I'm always skeptical of "0 value non-instantiable types", as I'm sure you
>> know.
>>
>
> Next you'll be asking for something crazy like making void Regular.  :-)
>

Hehe, exactly ;)

On Thu, Oct 29, 2015 at 11:27 AM, Tony V E <tvaneerd@gmail.com> wrote:

> If you could create one, it would obviously be always invalid (or
> corrupted_by_exception or whatever).  And things like get<float> wouldn't
> compile, same way it doesn't compile for variant<int>.
> I don't think it would be hard to specify.
> I'm just not sure it is the correct thing to do.
>

Yeah, it's definitely not obvious precisely what the semantics should be
and why, so it needs a paper. It's also not that important that it's
handled in the immediate future, since it can always be added later when we
all understand the use-cases better (boost::variant never had it and we've
survived, but with occasional special-casing). I think the way to figure
out what we should have it do is to examine a bunch of real-world use-cases
in generic code that deal with variant<T...>, and that need to invoke
which(), get(), visit(), and corrupted_by_exception(), etc.. Then, see what
would happen in the world today if sizeof...(T) happened to be 0 for those
functions, and determine what would *actually* be expected of variant<> in
order to naturally produce consistent results with the function's specified
behavior for sizeof...(T) > 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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--089e01175e4d23a47d0523429e0d
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 T=
hu, Oct 29, 2015 at 11:27 AM, Tony V E <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-st=
yle:solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_extra"=
><br><div class=3D"gmail_quote"><span class=3D"">On Thu, Oct 29, 2015 at 2:=
13 PM, &#39;Matt Calabrese&#39; via ISO C++ Standard - Future Proposals <sp=
an dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@isocpp.org" target=3D"_b=
lank">std-proposals@isocpp.org</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">=
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><spa=
n>On Thu, Oct 29, 2015 at 7:55 AM, Tony V E <span dir=3D"ltr">&lt;<a href=
=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;=
</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(=
204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div>This has been discussed inside and outside =
the committee.<br></div><div>The consensus is, I think, that variant&lt;&gt=
; should be a valid type, but you can&#39;t instantiate it, because it has =
0 values.<br></div></div></div></div></blockquote><div><br></div></span><di=
v>I&#39;m always skeptical of &quot;0 value non-instantiable types&quot;, a=
s I&#39;m sure you know. </div></div></div></div></blockquote><div><br></di=
v></span><div>Next you&#39;ll be asking for something crazy like making voi=
d Regular.=C2=A0 :-)<br></div></div></div></div></blockquote><div><br></div=
><div>Hehe, exactly ;)</div><div>=C2=A0</div><div>On Thu, Oct 29, 2015 at 1=
1:27 AM, Tony V E=C2=A0<span dir=3D"ltr">&lt;<a href=3D"mailto:tvaneerd@gma=
il.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</span>=C2=A0wrote:</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid=
;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><div>If you could create one, it would obviously be always=
 invalid (or corrupted_by_exception or whatever).=C2=A0 And things like get=
&lt;float&gt; wouldn&#39;t compile, same way it doesn&#39;t compile for var=
iant&lt;int&gt;.<br>I don&#39;t think it would be hard to specify.<br></div=
><div>I&#39;m just not sure it is the correct thing to do.</div></div></div=
></div></blockquote><div><br></div><div>Yeah, it&#39;s definitely not obvio=
us precisely what the semantics should be and why, so it needs a paper. It&=
#39;s also not that important that it&#39;s handled in the immediate future=
, since it can always be added later when we all understand the use-cases b=
etter (boost::variant never had it and we&#39;ve survived, but with occasio=
nal special-casing). I think the way to figure out what we should have it d=
o is to examine a bunch of real-world use-cases in generic code that deal w=
ith variant&lt;T...&gt;, and that need to invoke which(), get(), visit(), a=
nd corrupted_by_exception(), etc.. Then, see what would happen in the world=
 today if sizeof...(T) happened to be 0 for those functions, and determine =
what would <i>actually</i> be expected of variant&lt;&gt; in order to natur=
ally produce consistent results with the function&#39;s specified behavior =
for sizeof...(T) &gt; 0.</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 />

--089e01175e4d23a47d0523429e0d--

.

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

On 29 October 2015 at 13:38, 'Matt Calabrese' via ISO C++ Standard - Future
Proposals <std-proposals@isocpp.org> wrote:

> Yeah, it's definitely not obvious precisely what the semantics should be
> and why, so it needs a paper.
>

It needs a paper because it would be breaking consensus.  variant<> was
already discussed and agreed to in Lenexa, and I hadn't heard that it
changed in Kona.

Are you going to ask for a full plenary/evening session in Jacksonville to
discuss variant yet again?
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
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/.

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

<div dir=3D"ltr">On 29 October 2015 at 13:38, &#39;Matt Calabrese&#39; via =
ISO C++ Standard - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto=
:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&g=
t;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><=
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_extra"><=
div class=3D"gmail_quote"><div>Yeah, it&#39;s definitely not obvious precis=
ely what the semantics should be and why, so it needs a paper.</div></div><=
/div></div></blockquote><div><br></div><div>It needs a paper because it wou=
ld be breaking consensus. =C2=A0variant&lt;&gt; was already discussed and a=
greed to in Lenexa, and I hadn&#39;t heard that it changed in Kona.</div><d=
iv><br></div><div>Are you going to ask for a full plenary/evening session i=
n Jacksonville to discuss variant yet again?</div></div>-- <br><div class=
=3D"gmail_signature">=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a =
href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord=
..com</a>&gt;=C2=A0 (847) 691-1404</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 />

--001a113dccc2250713052342baf6--

.

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

On Thu, Oct 29, 2015 at 2:38 PM, 'Matt Calabrese' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

> On Thu, Oct 29, 2015 at 11:27 AM, Tony V E <tvaneerd@gmail.com> wrote:
>
>>
>>
>> On Thu, Oct 29, 2015 at 2:13 PM, 'Matt Calabrese' via ISO C++ Standard -
>> Future Proposals <std-proposals@isocpp.org> wrote:
>>
>>> On Thu, Oct 29, 2015 at 7:55 AM, Tony V E <tvaneerd@gmail.com> wrote:
>>>>
>>>> This has been discussed inside and outside the committee.
>>>> The consensus is, I think, that variant<> should be a valid type, but
>>>> you can't instantiate it, because it has 0 values.
>>>>
>>>
>>> I'm always skeptical of "0 value non-instantiable types", as I'm sure
>>> you know.
>>>
>>
>> Next you'll be asking for something crazy like making void Regular.  :-)
>>
>
> Hehe, exactly ;)
>
> On Thu, Oct 29, 2015 at 11:27 AM, Tony V E <tvaneerd@gmail.com> wrote:
>
>> If you could create one, it would obviously be always invalid (or
>> corrupted_by_exception or whatever).  And things like get<float> wouldn't
>> compile, same way it doesn't compile for variant<int>.
>> I don't think it would be hard to specify.
>> I'm just not sure it is the correct thing to do.
>>
>
> Yeah, it's definitely not obvious precisely what the semantics should be
> and why,
>

But I think it is obvious.  It would be the same as variant<int> in the
corrupted_by_exception state.  And get<float> would fail the same as it
fails on variant<int>.  which() returns same as it does for a
corrupted_by_exception variant.  etc.  It probably is quite obvious.


> so it needs a paper.
>

Everything needs a paper, even if obvious.

The only obvious part is whether variant<> should be constructible.  We
already decided it shouldn't be.  So you would need strong motivating use
cases.



> It's also not that important that it's handled in the immediate future,
> since it can always be added later when we all understand the use-cases
> better (boost::variant never had it and we've survived, but with occasional
> special-casing). I think the way to figure out what we should have it do is
> to examine a bunch of real-world use-cases in generic code that deal with
> variant<T...>, and that need to invoke which(), get(), visit(), and
> corrupted_by_exception(), etc.. Then, see what would happen in the world
> today if sizeof...(T) happened to be 0 for those functions, and determine
> what would *actually* be expected of variant<> in order to naturally
> produce consistent results with the function's specified behavior for
> sizeof...(T) > 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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/.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Thu, Oct 29, 2015 at 2:38 PM, &#39;Matt Calabrese&#39; via ISO C++ S=
tandard - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-prop=
osals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gm=
ail_extra"><div class=3D"gmail_quote"><span class=3D"">On Thu, Oct 29, 2015=
 at 11:27 AM, Tony V E <span dir=3D"ltr">&lt;<a href=3D"mailto:tvaneerd@gma=
il.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</span> wrote:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-=
width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddin=
g-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote"><span>On Thu, Oct 29, 2015 at 2:13 PM, &#39;Matt Calabrese=
&#39; via ISO C++ Standard - Future Proposals <span dir=3D"ltr">&lt;<a href=
=3D"mailto:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp=
..org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border=
-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><span>On Thu, Oct 29, 2015 at 7=
:55 AM, Tony V E <span dir=3D"ltr">&lt;<a href=3D"mailto:tvaneerd@gmail.com=
" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</span> wrote:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;=
border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex=
"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><d=
iv>This has been discussed inside and outside the committee.<br></div><div>=
The consensus is, I think, that variant&lt;&gt; should be a valid type, but=
 you can&#39;t instantiate it, because it has 0 values.<br></div></div></di=
v></div></blockquote><div><br></div></span><div>I&#39;m always skeptical of=
 &quot;0 value non-instantiable types&quot;, as I&#39;m sure you know. </di=
v></div></div></div></blockquote><div><br></div></span><div>Next you&#39;ll=
 be asking for something crazy like making void Regular.=C2=A0 :-)<br></div=
></div></div></div></blockquote><div><br></div></span><div>Hehe, exactly ;)=
</div><span class=3D""><div>=C2=A0</div><div>On Thu, Oct 29, 2015 at 11:27 =
AM, Tony V E=C2=A0<span dir=3D"ltr">&lt;<a href=3D"mailto:tvaneerd@gmail.co=
m" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</span>=C2=A0wrote:</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gma=
il_quote"><div>If you could create one, it would obviously be always invali=
d (or corrupted_by_exception or whatever).=C2=A0 And things like get&lt;flo=
at&gt; wouldn&#39;t compile, same way it doesn&#39;t compile for variant&lt=
;int&gt;.<br>I don&#39;t think it would be hard to specify.<br></div><div>I=
&#39;m just not sure it is the correct thing to do.</div></div></div></div>=
</blockquote><div><br></div></span><div>Yeah, it&#39;s definitely not obvio=
us precisely what the semantics should be and why,</div></div></div></div><=
/blockquote><div><br></div><div>But I think it is obvious.=C2=A0 It would b=
e the same as variant&lt;int&gt; in the corrupted_by_exception state.=C2=A0=
 And get&lt;float&gt; would fail the same as it fails on variant&lt;int&gt;=
..=C2=A0 which() returns same as it does for a corrupted_by_exception varian=
t.=C2=A0 etc.=C2=A0 It probably is quite obvious.<br></div><div>=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"=
><div class=3D"gmail_quote"><div> so it needs a paper. </div></div></div></=
div></blockquote><div><br></div><div>Everything needs a paper, even if obvi=
ous.<br><br></div><div>The only obvious part is whether variant&lt;&gt; sho=
uld be constructible.=C2=A0 We already decided it shouldn&#39;t be.=C2=A0 S=
o you would need strong motivating use cases.<br><br></div><div>=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"=
><div class=3D"gmail_quote"><div>It&#39;s also not that important that it&#=
39;s handled in the immediate future, since it can always be added later wh=
en we all understand the use-cases better (boost::variant never had it and =
we&#39;ve survived, but with occasional special-casing). I think the way to=
 figure out what we should have it do is to examine a bunch of real-world u=
se-cases in generic code that deal with variant&lt;T...&gt;, and that need =
to invoke which(), get(), visit(), and corrupted_by_exception(), etc.. Then=
, see what would happen in the world today if sizeof...(T) happened to be 0=
 for those functions, and determine what would <i>actually</i> be expected =
of variant&lt;&gt; in order to naturally produce consistent results with th=
e function&#39;s specified behavior for sizeof...(T) &gt; 0.</div></div></d=
iv></div><div class=3D"HOEnZb"><div class=3D"h5">

<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" 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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></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 />

--001a11c377a259471e052342c701--

.

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

On Thu, Oct 29, 2015 at 11:45 AM, Nevin Liber <nevin@eviloverlord.com>
wrote:

> On 29 October 2015 at 13:38, 'Matt Calabrese' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
>
>> Yeah, it's definitely not obvious precisely what the semantics should be
>> and why, so it needs a paper.
>>
>
> It needs a paper because it would be breaking consensus.  variant<> was
> already discussed and agreed to in Lenexa, and I hadn't heard that it
> changed in Kona.
>
> Are you going to ask for a full plenary/evening session in Jacksonville to
> discuss variant yet again?
>

No, I'm just defending Larry and others' thoughts as valid things to
consider. I'm not pushing for variant<> in the immediate future, as I've
stated. There is no rush, since it is a change that can be made years down
the line without breaking code, and when we have more people encountering
use-cases.

--

---
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/.

--001a113685e2bbd2e5052342d55b
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 T=
hu, Oct 29, 2015 at 11:45 AM, Nevin Liber <span dir=3D"ltr">&lt;<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.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"><div dir=3D"ltr"><span=
 class=3D"">On 29 October 2015 at 13:38, &#39;Matt Calabrese&#39; via ISO C=
++ Standard - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-=
proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</s=
pan> wrote:<br></span><div class=3D"gmail_extra"><div class=3D"gmail_quote"=
><span class=3D""><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 clas=
s=3D"gmail_extra"><div class=3D"gmail_quote"><div>Yeah, it&#39;s definitely=
 not obvious precisely what the semantics should be and why, so it needs a =
paper.</div></div></div></div></blockquote><div><br></div></span><div>It ne=
eds a paper because it would be breaking consensus. =C2=A0variant&lt;&gt; w=
as already discussed and agreed to in Lenexa, and I hadn&#39;t heard that i=
t changed in Kona.</div><div><br></div><div>Are you going to ask for a full=
 plenary/evening session in Jacksonville to discuss variant yet again?</div=
></div></div></div></blockquote><div><br></div><div>No, I&#39;m just defend=
ing Larry and others&#39; thoughts as valid things to consider. I&#39;m not=
 pushing for variant&lt;&gt; in the immediate future, as I&#39;ve stated. T=
here is no rush, since it is a change that can be made years down the line =
without breaking code, and when we have more people encountering use-cases.=
</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 />

--001a113685e2bbd2e5052342d55b--

.

--089e0115f0527eab0205234321ce
Content-Type: text/plain; charset=UTF-8

On Thu, Oct 29, 2015 at 11:50 AM, Tony V E <tvaneerd@gmail.com> wrote:
>
> But I think it is obvious.
>

+1 I think *most* aspects of it are obvious, but given that there is
disagreement, it's definitely not entirely the case for all people and for
all aspects of the type.

On Thu, Oct 29, 2015 at 11:50 AM, Tony V E <tvaneerd@gmail.com> wrote:

> It would be the same as variant<int> in the corrupted_by_exception state.
> And get<float> would fail the same as it fails on variant<int>.  which()
> returns same as it does for a corrupted_by_exception variant.  etc.  It
> probably is quite obvious.
>

Yeah, that's probably true, but what's obvious to some is not obvious to
others. Not everyone writes generic code. I've already personally changed
my view on this in the past 10 minutes regarding some details.

On Thu, Oct 29, 2015 at 11:50 AM, Tony V E <tvaneerd@gmail.com> wrote:

> The only obvious part is whether variant<> should be constructible.  We
> already decided it shouldn't be.  So you would need strong motivating use
> cases.
>

That's unfortunate and I also wasn't around for those earlier discussions.
To me, Regularity is the most obvious aspect ;) All use-cases I've
encountered in practice require at least this, including those that were
shown here. If there are use-cases that require it and yet no use-cases
that require it *not* being valid (such negative requirements are pretty
strange to begin with), then it's surprising to me that people would be so
against it. It's fine if variant<> isn't constructible for now, but I
suspect more people will encounter this situation over the years after it's
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--089e0115f0527eab0205234321ce
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 T=
hu, Oct 29, 2015 at 11:50 AM, Tony V E <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</span>=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:=
solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div cl=
ass=3D"gmail_quote"><div>But I think it is obvious.=C2=A0</div></div></div>=
</div></blockquote><div><br></div><div>+1 I think <i>most</i> aspects of it=
 are obvious, but given that there is disagreement, it&#39;s definitely not=
 entirely the case for all people and for all aspects of the type.</div><di=
v><br></div><div>On Thu, Oct 29, 2015 at 11:50 AM, Tony V E=C2=A0<span dir=
=3D"ltr">&lt;<a href=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tvanee=
rd@gmail.com</a>&gt;</span>=C2=A0wrote:=C2=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-le=
ft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div di=
r=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div> It wo=
uld be the same as variant&lt;int&gt; in the corrupted_by_exception state.=
=C2=A0 And get&lt;float&gt; would fail the same as it fails on variant&lt;i=
nt&gt;.=C2=A0 which() returns same as it does for a corrupted_by_exception =
variant.=C2=A0 etc.=C2=A0 It probably is quite obvious.<br></div></div></di=
v></div></blockquote><div><br></div><div>Yeah, that&#39;s probably true, bu=
t what&#39;s obvious to some is not obvious to others. Not everyone writes =
generic code. I&#39;ve already personally changed my view on this in the pa=
st 10 minutes regarding some details.</div><div><br></div><div>On Thu, Oct =
29, 2015 at 11:50 AM, Tony V E=C2=A0<span dir=3D"ltr">&lt;<a href=3D"mailto=
:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</span>=C2=
=A0wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"=
><div class=3D"gmail_quote"><div>The only obvious part is whether variant&l=
t;&gt; should be constructible.=C2=A0 We already decided it shouldn&#39;t b=
e.=C2=A0 So you would need strong motivating use cases.</div></div></div></=
div></blockquote><div><br></div><div>That&#39;s unfortunate and I also wasn=
&#39;t around for those earlier discussions. To me, Regularity=C2=A0is=C2=
=A0the most obvious aspect ;) All use-cases I&#39;ve encountered in practic=
e require at least this, including those that were shown here. If there are=
 use-cases that require it and yet no use-cases that require it <i>not</i>=
=C2=A0being valid (such negative requirements are pretty strange to begin w=
ith), then it&#39;s surprising to me that people would be so against it. It=
&#39;s fine if variant&lt;&gt; isn&#39;t constructible for now, but I suspe=
ct more people will encounter this situation over the years after it&#39;s =
in the standard.</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 />

--089e0115f0527eab0205234321ce--

.

--047d7b3a84c602634a052343b514
Content-Type: text/plain; charset=UTF-8

On Thu, Oct 29, 2015 at 11:50 AM, Tony V E <tvaneerd@gmail.com> wrote:

> The only obvious part is whether variant<> should be constructible.  We
> already decided it shouldn't be.  So you would need strong motivating use
> cases.
>

That's unfortunate and I also wasn't around for those earlier discussions.
To me, Regularity is the most obvious aspect ;) All use-cases I've
encountered in practice require at least this, including those that were
shown here.


The example code I've seen in this thread all work with the current
variant<> that can be "spoken" but not created.
You can even create an optional<variant<>>.

Tony

--

---
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/.

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

<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"=
gmail_quote"><span class=3D""><div>On Thu, Oct 29, 2015 at 11:50 AM, Tony V=
 E=C2=A0<span dir=3D"ltr">&lt;<a href=3D"mailto:tvaneerd@gmail.com" target=
=3D"_blank">tvaneerd@gmail.com</a>&gt;</span>=C2=A0wrote:</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1=
px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:=
1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"=
><div>The only obvious part is whether variant&lt;&gt; should be constructi=
ble.=C2=A0 We already decided it shouldn&#39;t be.=C2=A0 So you would need =
strong motivating use cases.</div></div></div></div></blockquote><div><br><=
/div></span><div>That&#39;s unfortunate and I also wasn&#39;t around for th=
ose earlier discussions. To me, Regularity=C2=A0is=C2=A0the most obvious as=
pect ;) All use-cases I&#39;ve encountered in practice require at least thi=
s, including those that were shown here. </div></div></div></div><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><div><br></div><div><br>The exa=
mple code I&#39;ve seen in this thread all work with the current variant&lt=
;&gt; that can be &quot;spoken&quot; but not created.<br></div><div>You can=
 even create an optional&lt;variant&lt;&gt;&gt;.=C2=A0 <br><br></div><div>T=
ony<br></div><br></div><br></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 />

--047d7b3a84c602634a052343b514--

.

------=_Part_9821_997554679.1446148819350
Content-Type: multipart/alternative;
 boundary="----=_Part_9822_1000422475.1446148819350"

------=_Part_9822_1000422475.1446148819350
Content-Type: text/plain; charset=UTF-8

On Thursday, October 29, 2015 at 3:15:16 PM UTC-4, Matt Calabrese wrote:
>
> On Thu, Oct 29, 2015 at 11:50 AM, Tony V E <tvan...@gmail.com
> <javascript:>> wrote:
>>
>> But I think it is obvious.
>>
>
> +1 I think *most* aspects of it are obvious, but given that there is
> disagreement, it's definitely not entirely the case for all people and for
> all aspects of the type.
>
> On Thu, Oct 29, 2015 at 11:50 AM, Tony V E <tvan...@gmail.com
> <javascript:>> wrote:
>
>> It would be the same as variant<int> in the corrupted_by_exception
>> state.  And get<float> would fail the same as it fails on variant<int>.
>> which() returns same as it does for a corrupted_by_exception variant.
>> etc.  It probably is quite obvious.
>>
>
> Yeah, that's probably true, but what's obvious to some is not obvious to
> others. Not everyone writes generic code. I've already personally changed
> my view on this in the past 10 minutes regarding some details.
>
> On Thu, Oct 29, 2015 at 11:50 AM, Tony V E <tvan...@gmail.com
> <javascript:>> wrote:
>
>> The only obvious part is whether variant<> should be constructible.  We
>> already decided it shouldn't be.  So you would need strong motivating use
>> cases.
>>
>
> That's unfortunate and I also wasn't around for those earlier discussions.
> To me, Regularity is the most obvious aspect ;) All use-cases I've
> encountered in practice require at least this, including those that were
> shown here. If there are use-cases that require it and yet no use-cases
> that require it *not* being valid (such negative requirements are pretty
> strange to begin with), then it's surprising to me that people would be so
> against it. It's fine if variant<> isn't constructible for now, but I
> suspect more people will encounter this situation over the years after it's
> in the standard.
>

If it's not constructible, you don't have to answer the question of what
the various operations on it return.

We don't want any `variant` to default construct into the invalid state
(because then it's not the invalid state anymore; it's just an empty
state). So `variant<>` either is not default constructible (at which point,
it's basically not constructible period) or we have to decide how it
behaves. What does `index` return, for example?

--

---
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/.

------=_Part_9822_1000422475.1446148819350
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thursday, October 29, 2015 at 3:15:16 PM UTC-4, Matt Calabrese wrote:<bl=
ockquote 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><div class=
=3D"gmail_quote">On Thu, Oct 29, 2015 at 11:50 AM, Tony V E <span dir=3D"lt=
r">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"h=
Q3fNBBDEwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#=
39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;=
">tvan...@gmail.com</a>&gt;</span> wrote:<blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:r=
gb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr">=
<div><div class=3D"gmail_quote"><div>But I think it is obvious.=C2=A0</div>=
</div></div></div></blockquote><div><br></div><div>+1 I think <i>most</i> a=
spects of it are obvious, but given that there is disagreement, it&#39;s de=
finitely not entirely the case for all people and for all aspects of the ty=
pe.</div><div><br></div><div>On Thu, Oct 29, 2015 at 11:50 AM, Tony V E=C2=
=A0<span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfu=
scated-mailto=3D"hQ3fNBBDEwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D=
&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:=
&#39;;return true;">tvan...@gmail.com</a>&gt;</span>=C2=A0wrote:=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;=
padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div> It=
 would be the same as variant&lt;int&gt; in the corrupted_by_exception stat=
e.=C2=A0 And get&lt;float&gt; would fail the same as it fails on variant&lt=
;int&gt;.=C2=A0 which() returns same as it does for a corrupted_by_exceptio=
n variant.=C2=A0 etc.=C2=A0 It probably is quite obvious.<br></div></div></=
div></div></blockquote><div><br></div><div>Yeah, that&#39;s probably true, =
but what&#39;s obvious to some is not obvious to others. Not everyone write=
s generic code. I&#39;ve already personally changed my view on this in the =
past 10 minutes regarding some details.</div><div><br></div><div>On Thu, Oc=
t 29, 2015 at 11:50 AM, Tony V E=C2=A0<span dir=3D"ltr">&lt;<a href=3D"java=
script:" target=3D"_blank" gdf-obfuscated-mailto=3D"hQ3fNBBDEwAJ" rel=3D"no=
follow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" oncl=
ick=3D"this.href=3D&#39;javascript:&#39;;return true;">tvan...@gmail.com</a=
>&gt;</span>=C2=A0wrote:</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,=
204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div><div c=
lass=3D"gmail_quote"><div>The only obvious part is whether variant&lt;&gt; =
should be constructible.=C2=A0 We already decided it shouldn&#39;t be.=C2=
=A0 So you would need strong motivating use cases.</div></div></div></div><=
/blockquote><div><br></div><div>That&#39;s unfortunate and I also wasn&#39;=
t around for those earlier discussions. To me, Regularity=C2=A0is=C2=A0the =
most obvious aspect ;) All use-cases I&#39;ve encountered in practice requi=
re at least this, including those that were shown here. If there are use-ca=
ses that require it and yet no use-cases that require it <i>not</i>=C2=A0be=
ing valid (such negative requirements are pretty strange to begin with), th=
en it&#39;s surprising to me that people would be so against it. It&#39;s f=
ine if variant&lt;&gt; isn&#39;t constructible for now, but I suspect more =
people will encounter this situation over the years after it&#39;s in the s=
tandard.</div></div></div></div></blockquote><div><br>If it&#39;s not const=
ructible, you don&#39;t have to answer the question of what the various ope=
rations on it return.<br><br>We don&#39;t want any `variant` to default con=
struct into the invalid state (because then it&#39;s not the invalid state =
anymore; it&#39;s just an empty state). So `variant&lt;&gt;` either is not =
default constructible (at which point, it&#39;s basically not constructible=
 period) or we have to decide how it behaves. What does `index` return, for=
 example? <br></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 />

------=_Part_9822_1000422475.1446148819350--
------=_Part_9821_997554679.1446148819350--

.

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

On Thu, Oct 29, 2015 at 12:56 PM, Tony V E <tvaneerd@gmail.com> wrote:

> On Thu, Oct 29, 2015 at 11:50 AM, Tony V E <tvaneerd@gmail.com> wrote:
>
>> The only obvious part is whether variant<> should be constructible.  We
>> already decided it shouldn't be.  So you would need strong motivating use
>> cases.
>>
>
> That's unfortunate and I also wasn't around for those earlier discussions.
> To me, Regularity is the most obvious aspect ;) All use-cases I've
> encountered in practice require at least this, including those that were
> shown here.
>
>
> The example code I've seen in this thread all work with the current
> variant<> that can be "spoken" but not created.
> You can even create an optional<variant<>>.
>

Unless I'm misunderstanding something, you can't copy/move it, meaning you
can't, for instance, return the result (at least not without the *required*
RVO and your function implementation needs to meet the requirements of
that). Am I missing something? I understand that you can instantiate the
*declaration* and default construct it, but without being able to use the
return value and forward it along (even if ultimately you don't do anything
other than no-ops with it), then you can't use it in sensible generic code.
It's the same reason why you want other types to be Regular, with all of
the same use-cases. The example using optional hides things a little bit
because of the encapsulation, so other examples are probably better.

--

---
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/.

--001a113b056a8f16020523440739
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 T=
hu, Oct 29, 2015 at 12:56 PM, Tony V E <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D""=
><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><sp=
an><div>On Thu, Oct 29, 2015 at 11:50 AM, Tony V E=C2=A0<span dir=3D"ltr">&=
lt;<a href=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.c=
om</a>&gt;</span>=C2=A0wrote:</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><div>The only obvious part=
 is whether variant&lt;&gt; should be constructible.=C2=A0 We already decid=
ed it shouldn&#39;t be.=C2=A0 So you would need strong motivating use cases=
..</div></div></div></div></blockquote><div><br></div></span><div>That&#39;s=
 unfortunate and I also wasn&#39;t around for those earlier discussions. To=
 me, Regularity=C2=A0is=C2=A0the most obvious aspect ;) All use-cases I&#39=
;ve encountered in practice require at least this, including those that wer=
e shown here. </div></div></div></div></span><div class=3D"gmail_extra"><di=
v class=3D"gmail_quote"><div><br></div><div><br>The example code I&#39;ve s=
een in this thread all work with the current variant&lt;&gt; that can be &q=
uot;spoken&quot; but not created.<br></div><div>You can even create an opti=
onal&lt;variant&lt;&gt;&gt;.</div></div></div></div></blockquote><div><br><=
/div><div>Unless I&#39;m misunderstanding something, you can&#39;t copy/mov=
e it, meaning you can&#39;t, for instance, return the result (at least not =
without the <i>required</i> RVO and your function implementation needs to m=
eet the requirements of that). Am I missing something? I understand that yo=
u can instantiate the <i>declaration</i>=C2=A0and default construct it, but=
 without being able to use the return value and forward it along (even if u=
ltimately you don&#39;t do anything other than no-ops with it), then you ca=
n&#39;t use it in sensible generic code. It&#39;s the same reason why you w=
ant other types to be Regular, with all of the same use-cases. The example =
using optional hides things a little bit because of the encapsulation, so o=
ther examples are probably better.</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 />

--001a113b056a8f16020523440739--

.

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

On Thu, Oct 29, 2015 at 1:19 PM, Matt Calabrese <calabrese@google.com>
wrote:
>
> I understand that you can instantiate the *declaration* and default
> construct it
>

To be clear, "it" here is optional<variant<>>

--

---
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/.

--001a113de97603262c05234412e0
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 T=
hu, Oct 29, 2015 at 1:19 PM, Matt Calabrese <span dir=3D"ltr">&lt;<a href=
=3D"mailto:calabrese@google.com" target=3D"_blank">calabrese@google.com</a>=
&gt;</span> wrote:<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 clas=
s=3D"gmail_extra"><div class=3D"gmail_quote"><div>I understand that you can=
 instantiate the <i>declaration</i>=C2=A0and default construct it</div></di=
v></div></div></blockquote><div><br></div><div>To be clear, &quot;it&quot; =
here is optional&lt;variant&lt;&gt;&gt;=C2=A0</div></div><br></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 />

--001a113de97603262c05234412e0--

.

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

On Thu, Oct 29, 2015 at 9:19 PM, 'Matt Calabrese' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

> On Thu, Oct 29, 2015 at 12:56 PM, Tony V E <tvaneerd@gmail.com> wrote:
>
>> On Thu, Oct 29, 2015 at 11:50 AM, Tony V E <tvaneerd@gmail.com> wrote:
>>
>>> The only obvious part is whether variant<> should be constructible.  We
>>> already decided it shouldn't be.  So you would need strong motivating use
>>> cases.
>>>
>>
>> That's unfortunate and I also wasn't around for those earlier
>> discussions. To me, Regularity is the most obvious aspect ;) All use-cases
>> I've encountered in practice require at least this, including those that
>> were shown here.
>>
>>
>> The example code I've seen in this thread all work with the current
>> variant<> that can be "spoken" but not created.
>> You can even create an optional<variant<>>.
>>
>
> Unless I'm misunderstanding something, you can't copy/move it, meaning you
> can't, for instance, return the result (at least not without the
> *required* RVO and your function implementation needs to meet the
> requirements of that). Am I missing something? I understand that you can
> instantiate the *declaration* and default construct it, but without being
> able to use the return value and forward it along (even if ultimately you
> don't do anything other than no-ops with it), then you can't use it in
> sensible generic code. It's the same reason why you want other types to be
> Regular, with all of the same use-cases. The example using optional hides
> things a little bit because of the encapsulation, so other examples are
> probably better.
>

Matt, optional<variant<>> should work fine. variant<> is missing the
default constructor, but it should have a valid copy constructor and all
other special member functions. optional<T> is usable with
non-default-constructible T.

Roman Perepelitsa.

--

---
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/.

--001a113db35c60d5c50523441600
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 T=
hu, Oct 29, 2015 at 9:19 PM, &#39;Matt Calabrese&#39; via ISO C++ Standard =
- Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@is=
ocpp.org" target=3D"_blank">std-proposals@isocpp.org</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"><div dir=3D"ltr"><div class=3D"gmail_extr=
a"><div class=3D"gmail_quote"><span class=3D"">On Thu, Oct 29, 2015 at 12:5=
6 PM, Tony V E <span dir=3D"ltr">&lt;<a href=3D"mailto:tvaneerd@gmail.com" =
target=3D"_blank">tvaneerd@gmail.com</a>&gt;</span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><span><div dir=3D"ltr"><div class=3D"gma=
il_extra"><div class=3D"gmail_quote"><span><div>On Thu, Oct 29, 2015 at 11:=
50 AM, Tony V E=C2=A0<span dir=3D"ltr">&lt;<a href=3D"mailto:tvaneerd@gmail=
..com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</span>=C2=A0wrote:</div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"=
gmail_quote"><div>The only obvious part is whether variant&lt;&gt; should b=
e constructible.=C2=A0 We already decided it shouldn&#39;t be.=C2=A0 So you=
 would need strong motivating use cases.</div></div></div></div></blockquot=
e><div><br></div></span><div>That&#39;s unfortunate and I also wasn&#39;t a=
round for those earlier discussions. To me, Regularity=C2=A0is=C2=A0the mos=
t obvious aspect ;) All use-cases I&#39;ve encountered in practice require =
at least this, including those that were shown here. </div></div></div></di=
v></span><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div><br></d=
iv><div><br>The example code I&#39;ve seen in this thread all work with the=
 current variant&lt;&gt; that can be &quot;spoken&quot; but not created.<br=
></div><div>You can even create an optional&lt;variant&lt;&gt;&gt;.</div></=
div></div></div></blockquote><div><br></div></span><div>Unless I&#39;m misu=
nderstanding something, you can&#39;t copy/move it, meaning you can&#39;t, =
for instance, return the result (at least not without the <i>required</i> R=
VO and your function implementation needs to meet the requirements of that)=
.. Am I missing something? I understand that you can instantiate the <i>decl=
aration</i>=C2=A0and default construct it, but without being able to use th=
e return value and forward it along (even if ultimately you don&#39;t do an=
ything other than no-ops with it), then you can&#39;t use it in sensible ge=
neric code. It&#39;s the same reason why you want other types to be Regular=
, with all of the same use-cases. The example using optional hides things a=
 little bit because of the encapsulation, so other examples are probably be=
tter.</div></div></div></div></blockquote><div><br></div><div>Matt, optiona=
l&lt;variant&lt;&gt;&gt; should work fine. variant&lt;&gt; is missing the d=
efault constructor, but it should have a valid copy constructor and all oth=
er special member functions. optional&lt;T&gt; is usable with non-default-c=
onstructible T.</div><div><br></div><div>Roman Perepelitsa.</div></div></di=
v></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 />

--001a113db35c60d5c50523441600--

.

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

On Thu, Oct 29, 2015 at 1:23 PM, Roman Perepelitsa <
roman.perepelitsa@gmail.com> wrote:
>
> Matt, optional<variant<>> should work fine. variant<> is missing the
> default constructor, but it should have a valid copy constructor and all
> other special member functions. optional<T> is usable with
> non-default-constructible T.
>

Ah, that's what I'm missing -- so the idea is that it really is
instantiable, but just not default constructible? That's more 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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a11c2cdaca629420523441dd7
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 T=
hu, Oct 29, 2015 at 1:23 PM, Roman Perepelitsa <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:roman.perepelitsa@gmail.com" target=3D"_blank">roman.perepelits=
a@gmail.com</a>&gt;</span> wrote:<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_extra"><div class=3D"gmail_quote"><div>Matt, opti=
onal&lt;variant&lt;&gt;&gt; should work fine. variant&lt;&gt; is missing th=
e default constructor, but it should have a valid copy constructor and all =
other special member functions. optional&lt;T&gt; is usable with non-defaul=
t-constructible T.</div></div></div></div></blockquote><div><br></div><div>=
Ah, that&#39;s what I&#39;m missing -- so the idea is that it really is ins=
tantiable, but just not default constructible? That&#39;s more reasonable.<=
/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 />

--001a11c2cdaca629420523441dd7--

.

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

On Thu, Oct 29, 2015 at 9:25 PM, 'Matt Calabrese' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

> On Thu, Oct 29, 2015 at 1:23 PM, Roman Perepelitsa <
> roman.perepelitsa@gmail.com> wrote:
>>
>> Matt, optional<variant<>> should work fine. variant<> is missing the
>> default constructor, but it should have a valid copy constructor and all
>> other special member functions. optional<T> is usable with
>> non-default-constructible T.
>>
>
> Ah, that's what I'm missing -- so the idea is that it really is
> instantiable, but just not default constructible? That's more reasonable.
>

That's my understanding at least, also based on the fact that it's
reasonable.

Roman Perepelitsa.

--

---
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/.

--001a11c23e2e3e4d6f0523445da0
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 T=
hu, Oct 29, 2015 at 9:25 PM, &#39;Matt Calabrese&#39; via ISO C++ Standard =
- Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@is=
ocpp.org" target=3D"_blank">std-proposals@isocpp.org</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"><div dir=3D"ltr"><div class=3D"gmail_extr=
a"><div class=3D"gmail_quote"><span class=3D"">On Thu, Oct 29, 2015 at 1:23=
 PM, Roman Perepelitsa <span dir=3D"ltr">&lt;<a href=3D"mailto:roman.perepe=
litsa@gmail.com" target=3D"_blank">roman.perepelitsa@gmail.com</a>&gt;</spa=
n> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmai=
l_extra"><div class=3D"gmail_quote"><div>Matt, optional&lt;variant&lt;&gt;&=
gt; should work fine. variant&lt;&gt; is missing the default constructor, b=
ut it should have a valid copy constructor and all other special member fun=
ctions. optional&lt;T&gt; is usable with non-default-constructible T.</div>=
</div></div></div></blockquote><div><br></div></span><div>Ah, that&#39;s wh=
at I&#39;m missing -- so the idea is that it really is instantiable, but ju=
st not default constructible? That&#39;s more reasonable.</div></div></div>=
</div></blockquote><div><br></div><div>That&#39;s my understanding at least=
, also based on the fact that it&#39;s reasonable.</div><div><br></div><div=
>Roman Perepelitsa.</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 />

--001a11c23e2e3e4d6f0523445da0--

.

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

On Thu, Oct 29, 2015 at 1:43 PM, Roman Perepelitsa <
roman.perepelitsa@gmail.com> wrote:

> On Thu, Oct 29, 2015 at 9:25 PM, 'Matt Calabrese' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
>
>> On Thu, Oct 29, 2015 at 1:23 PM, Roman Perepelitsa <
>> roman.perepelitsa@gmail.com> wrote:
>>>
>>> Matt, optional<variant<>> should work fine. variant<> is missing the
>>> default constructor, but it should have a valid copy constructor and all
>>> other special member functions. optional<T> is usable with
>>> non-default-constructible T.
>>>
>>
>> Ah, that's what I'm missing -- so the idea is that it really is
>> instantiable, but just not default constructible? That's more reasonable.
>>
>
> That's my understanding at least, also based on the fact that it's
> reasonable.
>

Agreed. When people were saying that it's not constructible, I thought they
really meant it has *no* constructors (not just lacking a default
constructor). As long as you can copy/move instances around, have functions
that take it and return it by value, and it provides certain associated
functions, etc., that is what you need for generic code at a minimum --
function templates that deal with copying/moving of variant<> should be
able to be instantiated. Lack of default construction is okay with me,
though it does make it not Regular for common descriptions of Regular
types. I think of such a requirement as a mistake, anyway.

--

---
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/.

--001a113b056a0379fa052344ab07
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 T=
hu, Oct 29, 2015 at 1:43 PM, Roman Perepelitsa <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:roman.perepelitsa@gmail.com" target=3D"_blank">roman.perepelits=
a@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div><div c=
lass=3D"h5">On Thu, Oct 29, 2015 at 9:25 PM, &#39;Matt Calabrese&#39; via I=
SO C++ Standard - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:=
std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</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"><div dir=3D"ltr"><div cla=
ss=3D"gmail_extra"><div class=3D"gmail_quote"><span>On Thu, Oct 29, 2015 at=
 1:23 PM, Roman Perepelitsa <span dir=3D"ltr">&lt;<a href=3D"mailto:roman.p=
erepelitsa@gmail.com" target=3D"_blank">roman.perepelitsa@gmail.com</a>&gt;=
</span> wrote:<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_extra"><div class=3D"gmail_quote"><div>Matt, optional&lt;variant&lt;=
&gt;&gt; should work fine. variant&lt;&gt; is missing the default construct=
or, but it should have a valid copy constructor and all other special membe=
r functions. optional&lt;T&gt; is usable with non-default-constructible T.<=
/div></div></div></div></blockquote><div><br></div></span><div>Ah, that&#39=
;s what I&#39;m missing -- so the idea is that it really is instantiable, b=
ut just not default constructible? That&#39;s more reasonable.</div></div><=
/div></div></blockquote><div><br></div></div></div><div>That&#39;s my under=
standing at least, also based on the fact that it&#39;s reasonable.</div></=
div></div></div></blockquote><div><br></div><div>Agreed. When people were s=
aying that it&#39;s not constructible, I thought they really meant it has <=
i>no</i> constructors (not just lacking a default constructor). As long as =
you can copy/move instances around, have functions that take it and return =
it by value, and it provides certain associated functions, etc., that is wh=
at you need for generic code at a minimum -- function templates that deal w=
ith copying/moving of variant&lt;&gt; should be able to be instantiated. La=
ck of default construction is okay with me, though it does make it not Regu=
lar for common descriptions of Regular types. I think of such a requirement=
 as a mistake, anyway.</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 />

--001a113b056a0379fa052344ab07--

.

--089e011605f43b169a05234539bb
Content-Type: text/plain; charset=UTF-8

On Thu, Oct 29, 2015 at 5:05 PM, 'Matt Calabrese' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

> On Thu, Oct 29, 2015 at 1:43 PM, Roman Perepelitsa <
> roman.perepelitsa@gmail.com> wrote:
>
>> On Thu, Oct 29, 2015 at 9:25 PM, 'Matt Calabrese' via ISO C++ Standard -
>> Future Proposals <std-proposals@isocpp.org> wrote:
>>
>>> On Thu, Oct 29, 2015 at 1:23 PM, Roman Perepelitsa <
>>> roman.perepelitsa@gmail.com> wrote:
>>>>
>>>> Matt, optional<variant<>> should work fine. variant<> is missing the
>>>> default constructor, but it should have a valid copy constructor and all
>>>> other special member functions. optional<T> is usable with
>>>> non-default-constructible T.
>>>>
>>>
>>> Ah, that's what I'm missing -- so the idea is that it really is
>>> instantiable, but just not default constructible? That's more reasonable.
>>>
>>
>> That's my understanding at least, also based on the fact that it's
>> reasonable.
>>
>
> Agreed. When people were saying that it's not constructible, I thought
> they really meant it has *no* constructors (not just lacking a default
> constructor). As long as you can copy/move instances around,
>

Sure, you just can't create that first instance from which to make copies.


> have functions that take it and return it by value,
>

Yep, you just can't call functions that take them by value (you can compile
the calls if you are careful, but can't call them at runtime), and you
can't allow the functions that return them to actually return.

variant<> really is a lot like:

struct Zero {
    Zero() = delete;
    bool somefunc() { return true;}
};

Play around with what you can and can't do with that class

Zero always_throw() {
    throw 42;
}

Zero never_return() {
    for (;;) ;
    return never_return();
}

int take_zero(Zero zero) {
    zero.somefunc();
    return 17;
}

int main()
{
    int x = take_zero(always_throw());
    Zero zero = never_return();
    zero.somefunc();
   ... etc...
}

You can compile it all, but you can't actually call much of it at runtime.




> and it provides certain associated functions, etc., that is what you need
> for generic code at a minimum -- function templates that deal with
> copying/moving of variant<> should be able to be instantiated. Lack of
> default construction is okay with me, though it does make it not Regular
> for common descriptions of Regular types. I think of such a requirement as
> a mistake, anyway.
>


If you look at "theory", ie which started this thread, the 0 type in most
functional languages can't be created either.

Tony


> --
>
> ---
> 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/.
>

--

---
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/.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Thu, Oct 29, 2015 at 5:05 PM, &#39;Matt Calabrese&#39; via ISO C++ S=
tandard - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-prop=
osals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"lt=
r"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D"">O=
n Thu, Oct 29, 2015 at 1:43 PM, Roman Perepelitsa <span dir=3D"ltr">&lt;<a =
href=3D"mailto:roman.perepelitsa@gmail.com" target=3D"_blank">roman.perepel=
itsa@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gm=
ail_quote"><div><div>On Thu, Oct 29, 2015 at 9:25 PM, &#39;Matt Calabrese&#=
39; via ISO C++ Standard - Future Proposals <span dir=3D"ltr">&lt;<a href=
=3D"mailto:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp=
..org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"=
><span>On Thu, Oct 29, 2015 at 1:23 PM, Roman Perepelitsa <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:roman.perepelitsa@gmail.com" target=3D"_blank">roman=
..perepelitsa@gmail.com</a>&gt;</span> wrote:<blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><div>Matt, optional&lt;variant&lt;&gt;&gt; should work fin=
e. variant&lt;&gt; is missing the default constructor, but it should have a=
 valid copy constructor and all other special member functions. optional&lt=
;T&gt; is usable with non-default-constructible T.</div></div></div></div><=
/blockquote><div><br></div></span><div>Ah, that&#39;s what I&#39;m missing =
-- so the idea is that it really is instantiable, but just not default cons=
tructible? That&#39;s more reasonable.</div></div></div></div></blockquote>=
<div><br></div></div></div><div>That&#39;s my understanding at least, also =
based on the fact that it&#39;s reasonable.</div></div></div></div></blockq=
uote><div><br></div></span><div>Agreed. When people were saying that it&#39=
;s not constructible, I thought they really meant it has <i>no</i> construc=
tors (not just lacking a default constructor). As long as you can copy/move=
 instances around,</div></div></div></div></blockquote><div><br></div><div>=
Sure, you just can&#39;t create that first instance from which to make copi=
es.<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><d=
iv dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div> =
have functions that take it and return it by value,</div></div></div></div>=
</blockquote><div><br></div><div>Yep, you just can&#39;t call functions tha=
t take them by value (you can compile the calls if you are careful, but can=
&#39;t call them at runtime), and you can&#39;t allow the functions that re=
turn them to actually return.<br><br></div><div>variant&lt;&gt; really is a=
 lot like:<br><br></div><div>struct Zero {<br>=C2=A0=C2=A0=C2=A0 Zero() =3D=
 delete;<br>=C2=A0=C2=A0=C2=A0 bool somefunc() { return true;}<br>};<br><br=
></div><div>Play around with what you can and can&#39;t do with that class<=
br><br></div><div>Zero always_throw() {<br>=C2=A0=C2=A0=C2=A0 throw 42;<br>=
}<br></div><div><br>Zero never_return() {<br>=C2=A0=C2=A0=C2=A0 for (;;) ;<=
br>=C2=A0=C2=A0=C2=A0 return never_return();<br>}<br></div><div><br>int tak=
e_zero(Zero zero) {<br></div><div>=C2=A0=C2=A0=C2=A0 zero.somefunc();<br></=
div><div>=C2=A0=C2=A0=C2=A0 return 17;<br>}<br><br></div><div>int main()<br=
>{<br></div><div>=C2=A0=C2=A0=C2=A0 int x =3D take_zero(always_throw());<br=
></div><div>=C2=A0=C2=A0=C2=A0 Zero zero =3D never_return();<br></div><div>=
=C2=A0=C2=A0=C2=A0 zero.somefunc();<br></div><div>=C2=A0=C2=A0 ... etc...<b=
r></div>}<br><div><br></div><div>You can compile it all, but you can&#39;t =
actually call much of it at runtime.<br></div><div><br></div><div><br></div=
><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div di=
r=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div> and i=
t provides certain associated functions, etc., that is what you need for ge=
neric code at a minimum -- function templates that deal with copying/moving=
 of variant&lt;&gt; should be able to be instantiated. Lack of default cons=
truction is okay with me, though it does make it not Regular for common des=
criptions of Regular types. I think of such a requirement as a mistake, any=
way.</div></div></div></div></blockquote><div><br></div><div><br>If you loo=
k at &quot;theory&quot;, ie which started this thread, the 0 type in most f=
unctional languages can&#39;t be created either.<br><br></div><div>Tony<br>=
=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div clas=
s=3D""><div class=3D"h5">

<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" 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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></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 />

--089e011605f43b169a05234539bb--

.

--089e01175e4d1e12b805234571a6
Content-Type: text/plain; charset=UTF-8

On Thu, Oct 29, 2015 at 2:45 PM, Tony V E <tvaneerd@gmail.com> wrote:
>
> Yep, you just can't call functions that take them by value (you can
> compile the calls if you are careful, but can't call them at runtime), and
> you can't allow the functions that return them to actually return.
>

Okay, we're on the same page, then, and I don't think I even disagree with
consensus if that was the resolution.

--

---
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/.

--089e01175e4d1e12b805234571a6
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 T=
hu, Oct 29, 2015 at 2:45 PM, Tony V E <span dir=3D"ltr">&lt;<a href=3D"mail=
to:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</span> =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:s=
olid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_quote"><div>Yep, you just can&#39;t call functions that take th=
em by value (you can compile the calls if you are careful, but can&#39;t ca=
ll them at runtime), and you can&#39;t allow the functions that return them=
 to actually return.<br></div></div></div></div></blockquote><div><br></div=
><div>Okay, we&#39;re on the same page, then, and I don&#39;t think I even =
disagree with consensus if that was the resolution.</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 />

--089e01175e4d1e12b805234571a6--

.

------=_Part_603_1946848017.1446205325381
Content-Type: multipart/alternative;
 boundary="----=_Part_604_1643517849.1446205325381"

------=_Part_604_1643517849.1446205325381
Content-Type: text/plain; charset=UTF-8

On Thursday, October 29, 2015 at 5:14:55 PM UTC, Nicol Bolas wrote:
>
> On Thursday, October 29, 2015 at 12:50:30 PM UTC-4, Giovanni Piero Deretta
> wrote:
>>
>> On Thursday, October 29, 2015 at 4:21:52 PM UTC, Nicol Bolas wrote:
>>>
>>>
>>>
>>> On Thursday, October 29, 2015 at 12:15:44 PM UTC-4, Nicol Bolas wrote:
>>>>
>>>>
>>>> template<class... T>
>>>>> variant<T...> runtime_get(std::tuple<T...>, int index);
>>>>>
>>>>
>>>> It will give a compilation error if you pass nothing in `T`. *Which it
>>>> should*, since there is nothing that `runtime_get` could possibly
>>>> return.
>>>>
>>>
>>> I want to make that a bit more clear. The implementation of
>>> `runtime_get` must, at some point, call `std::get<>` with some compile-time
>>> index. If the tuple has no types, then there is no way to call `std::get<>`
>>> on it with *any index*.
>>>
>>
>> template<class... T>
>> variant<T...> get_impl(int i, std::integral_constant<int, -1>,
>> tuple<T...>&) { throw std::out_of_range(); }
>>
>> template<class... T, int j>
>> variant<T...> get_impl(int i, std::integral_constant<int, j>,
>> tuple<T...>&x )  {
>>      return i == j? get<j>(x) : get_impl(i, integral_constant<int,
>> j-1>{}, x);
>> }
>>
>> template<class... T>
>> variant<T...> runtime_get(int i, tuple<T...>& x) { return get_impl(i,
>> std::integral_constant<int, sizeof...(T)-1>{}, x);
>>
>
>>
> The above works for any variant, including variant<>, without any special
>> handling. If variant<> is not valid, suddenly any user of runtime_get need
>> handle the corner case.
>>
>
> Here's the thing: N4542 doesn't make `variant<>` invalid. What it does is
> make it *not constructible* (at least, not its default constructor). So
> your code would work fine, because it statically never attempts to
> construct such a thing.
>
> So where's the problem? You can't make one. You can't use one. But you can
> stick it in a function's return type, so long as the function that tries to
> return it never actually returns it.
>
> Isn't that good enough?
>

I might want to do something like this:

std::vector<variant<> > foo() { return {}; };

as long as I'm allowed to call foo and copy the resulting vector around
think I would be ok with variant as specified.  I thought a bit about it
and I couldn't come up with a case I might actually want to create an
object of variant<>.


--

---
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/.

------=_Part_604_1643517849.1446205325381
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thursday, October 29, 2015 at 5:14:55 PM UTC, Nicol Bolas wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;">On Thursday, October 29, 2015 at 12:50=
:30 PM UTC-4, Giovanni Piero Deretta wrote:<blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">On Thursday, October 29, 2015 at 4:21:52 PM UTC, Nicol Bolas wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br>On Thursda=
y, October 29, 2015 at 12:15:44 PM UTC-4, Nicol Bolas wrote:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>t=
emplate&lt;class... T&gt;<br>variant&lt;T...&gt; runtime_get(std::tuple&lt;=
T...&gt;, int index);</div></blockquote><div><br>It will give a compilation=
 error if you pass nothing in `T`. <i>Which it should</i>, since there is n=
othing that `runtime_get` could possibly return. <br></div></blockquote><di=
v><br>I want to make that a bit more clear. The implementation of `runtime_=
get` must, at some point, call `std::get&lt;&gt;` with some compile-time in=
dex. If the tuple has no types, then there is no way to call `std::get&lt;&=
gt;` on it with <i>any index</i>. </div></div></blockquote><div><br><div st=
yle=3D"text-align:left"><div dir=3D"ltr"><div>template&lt;class... T&gt;<br=
>variant&lt;T...&gt;
 get_impl(int i, std::integral_constant&lt;int, -1&gt;,=20
tuple&lt;T...&gt;&amp;) { throw std::out_of_range(); }<br><br>template&lt;c=
lass... T, int j&gt;<br>variant&lt;T...&gt; get_impl(int i, std::integral_c=
onstant&lt;int, j&gt;, tuple&lt;T...&gt;&amp;x )=C2=A0 { <br>=C2=A0=C2=A0=
=C2=A0=C2=A0 return i =3D=3D j? get&lt;j&gt;(x) : get_impl(i, integral_cons=
tant&lt;int, j-1&gt;{}, x);<br>}<br><br>template&lt;class... T&gt;<br>varia=
nt&lt;T...&gt;
 runtime_get(int i, tuple&lt;T...&gt;&amp; x) { return get_impl(i,=20
std::integral_constant&lt;int, sizeof...(T)-1&gt;{}, x);<br></div></div></d=
iv></div></blockquote><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote"><di=
v>=C2=A0</div></blockquote><blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div><di=
v style=3D"text-align:left"><div dir=3D"ltr"><div>The=20
above works for any variant, including variant&lt;&gt;, without any=20
special handling. If variant&lt;&gt; is not valid, suddenly any user of=20
runtime_get need handle the corner case.</div></div></div></div></blockquot=
e><div><br>Here&#39;s the thing: N4542 doesn&#39;t make `variant&lt;&gt;` i=
nvalid. What it does is make it <i>not constructible</i> (at least, not its=
 default constructor). So your code would work fine, because it statically =
never attempts to construct such a thing.<br><br>So where&#39;s the problem=
? You can&#39;t make one. You can&#39;t use one. But you can stick it in a =
function&#39;s return type, so long as the function that tries to return it=
 never actually returns it.<br><br>Isn&#39;t that good enough?<br></div></b=
lockquote><div><br>I might want to do something like this:<br><br>std::vect=
or&lt;variant&lt;&gt; &gt; foo() { return {}; };<br><br>as long as I&#39;m =
allowed to call foo and copy the resulting vector around think I would be o=
k with variant as specified.=C2=A0 I thought a bit about it and I couldn&#3=
9;t come up with a case I might actually want to create an object of varian=
t&lt;&gt;.<br>=C2=A0</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 />

------=_Part_604_1643517849.1446205325381--
------=_Part_603_1946848017.1446205325381--

.

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

On 30 October 2015 at 11:42, Giovanni Piero Deretta <gpderetta@gmail.com>
wrote:

> I might want to do something like this:
>
> std::vector<variant<> > foo() { return {}; };
>
> as long as I'm allowed to call foo and copy the resulting vector around
> think I would be ok with variant as specified.  I thought a bit about it
> and I couldn't come up with a case I might actually want to create an
> object of variant<>.
>

what would sizeof(variant<>) be?

i don't think a vector would work for that reason.. a std::list<variant<>>
however should be fine so long as you don't insert into it.

--

---
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/.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On 30 October 2015 at 11:42, Giovanni Piero Deretta <span dir=3D"ltr">&=
lt;<a href=3D"mailto:gpderetta@gmail.com" target=3D"_blank">gpderetta@gmail=
..com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>I might w=
ant to do something like this:<br><br>std::vector&lt;variant&lt;&gt; &gt; f=
oo() { return {}; };<br><br>as long as I&#39;m allowed to call foo and copy=
 the resulting vector around think I would be ok with variant as specified.=
=C2=A0 I thought a bit about it and I couldn&#39;t come up with a case I mi=
ght actually want to create an object of variant&lt;&gt;.<br></div></blockq=
uote><div><br></div><div>what would sizeof(variant&lt;&gt;) be?<br><br></di=
v><div>i don&#39;t think a vector would work for that reason.. a std::list&=
lt;variant&lt;&gt;&gt; however should be fine so long as you don&#39;t inse=
rt into it. <br></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 />

--001a11c3bfeebec91a052351051e--

.

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

On Fri, Oct 30, 2015 at 12:49 PM, Sam Kellett <samkellett@gmail.com> wrote:

>
>
> On 30 October 2015 at 11:42, Giovanni Piero Deretta <gpderetta@gmail.com>
> wrote:
>
>> I might want to do something like this:
>>
>> std::vector<variant<> > foo() { return {}; };
>>
>> as long as I'm allowed to call foo and copy the resulting vector around
>> think I would be ok with variant as specified.  I thought a bit about it
>> and I couldn't come up with a case I might actually want to create an
>> object of variant<>.
>>
>
> what would sizeof(variant<>) be?
>

It would be 1.

i don't think a vector would work for that reason.. a std::list<variant<>>
> however should be fine so long as you don't insert into it.
>

std::vector can be used with non-default-constructible types, so
std::vector<variant<>> should work.

Roman Perepelitsa.

--

---
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/.

--001a11410834524fef0523511fe5
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 F=
ri, Oct 30, 2015 at 12:49 PM, Sam Kellett <span dir=3D"ltr">&lt;<a href=3D"=
mailto:samkellett@gmail.com" target=3D"_blank">samkellett@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"><div dir=3D"ltr"><br><div =
class=3D"gmail_extra"><br><div class=3D"gmail_quote"><span class=3D"">On 30=
 October 2015 at 11:42, Giovanni Piero Deretta <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:gpderetta@gmail.com" target=3D"_blank">gpderetta@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"><div>I might want to do=
 something like this:<br><br>std::vector&lt;variant&lt;&gt; &gt; foo() { re=
turn {}; };<br><br>as long as I&#39;m allowed to call foo and copy the resu=
lting vector around think I would be ok with variant as specified.=C2=A0 I =
thought a bit about it and I couldn&#39;t come up with a case I might actua=
lly want to create an object of variant&lt;&gt;.<br></div></blockquote><div=
><br></div></span><div>what would sizeof(variant&lt;&gt;) be?<br></div></di=
v></div></div></blockquote><div><br></div><div>It would be 1.</div><div><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_=
extra"><div class=3D"gmail_quote"><div>i don&#39;t think a vector would wor=
k for that reason.. a std::list&lt;variant&lt;&gt;&gt; however should be fi=
ne so long as you don&#39;t insert into it. <br></div></div></div></div></b=
lockquote><div><br></div><div>std::vector can be used with non-default-cons=
tructible types, so std::vector&lt;variant&lt;&gt;&gt; should work.</div><d=
iv><br></div><div>Roman Perepelitsa.</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 />

--001a11410834524fef0523511fe5--

.

------=_Part_707_362677812.1446212228117
Content-Type: multipart/alternative;
 boundary="----=_Part_708_1663583928.1446212228117"

------=_Part_708_1663583928.1446212228117
Content-Type: text/plain; charset=UTF-8



On Friday, October 30, 2015 at 7:42:05 AM UTC-4, Giovanni Piero Deretta
wrote:
>
> On Thursday, October 29, 2015 at 5:14:55 PM UTC, Nicol Bolas wrote:
>>
>> On Thursday, October 29, 2015 at 12:50:30 PM UTC-4, Giovanni Piero
>> Deretta wrote:
>>>
>>> On Thursday, October 29, 2015 at 4:21:52 PM UTC, Nicol Bolas wrote:
>>>>
>>>>
>>>>
>>>> On Thursday, October 29, 2015 at 12:15:44 PM UTC-4, Nicol Bolas wrote:
>>>>>
>>>>>
>>>>> template<class... T>
>>>>>> variant<T...> runtime_get(std::tuple<T...>, int index);
>>>>>>
>>>>>
>>>>> It will give a compilation error if you pass nothing in `T`. *Which
>>>>> it should*, since there is nothing that `runtime_get` could possibly
>>>>> return.
>>>>>
>>>>
>>>> I want to make that a bit more clear. The implementation of
>>>> `runtime_get` must, at some point, call `std::get<>` with some compile-time
>>>> index. If the tuple has no types, then there is no way to call `std::get<>`
>>>> on it with *any index*.
>>>>
>>>
>>> template<class... T>
>>> variant<T...> get_impl(int i, std::integral_constant<int, -1>,
>>> tuple<T...>&) { throw std::out_of_range(); }
>>>
>>> template<class... T, int j>
>>> variant<T...> get_impl(int i, std::integral_constant<int, j>,
>>> tuple<T...>&x )  {
>>>      return i == j? get<j>(x) : get_impl(i, integral_constant<int,
>>> j-1>{}, x);
>>> }
>>>
>>> template<class... T>
>>> variant<T...> runtime_get(int i, tuple<T...>& x) { return get_impl(i,
>>> std::integral_constant<int, sizeof...(T)-1>{}, x);
>>>
>>
>>>
>> The above works for any variant, including variant<>, without any special
>>> handling. If variant<> is not valid, suddenly any user of runtime_get need
>>> handle the corner case.
>>>
>>
>> Here's the thing: N4542 doesn't make `variant<>` invalid. What it does is
>> make it *not constructible* (at least, not its default constructor). So
>> your code would work fine, because it statically never attempts to
>> construct such a thing.
>>
>> So where's the problem? You can't make one. You can't use one. But you
>> can stick it in a function's return type, so long as the function that
>> tries to return it never actually returns it.
>>
>> Isn't that good enough?
>>
>
> I might want to do something like this:
>
> std::vector<variant<> > foo() { return {}; };
>
> as long as I'm allowed to call foo and copy the resulting vector around
> think I would be ok with variant as specified.  I thought a bit about it
> and I couldn't come up with a case I might actually want to create an
> object of variant<>.
>

`vector` seems to be able to handle a non-constructible object just fine.
So long as you don't actually insert elements into it, you can create them,
copy/move them around, etc.

As for the size, it's more or less irrelevant. As long as it has *some*
size (and is therefore a valid object), it should be fine.


--

---
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/.

------=_Part_708_1663583928.1446212228117
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br>On Friday, October 30, 2015 at 7:42:05 AM UTC-4, Giovanni Piero Der=
etta wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Thursday, Octobe=
r 29, 2015 at 5:14:55 PM UTC, Nicol Bolas wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex">On Thursday, October 29, 2015 at 12:50:30 PM UTC-4, Giovanni P=
iero Deretta wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;marg=
in-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On Thursday, Oct=
ober 29, 2015 at 4:21:52 PM UTC, Nicol Bolas wrote:<blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr"><br><br>On Thursday, October 29, 2015 at 1=
2:15:44 PM UTC-4, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><br><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div>template&lt;class... T&gt=
;<br>variant&lt;T...&gt; runtime_get(std::tuple&lt;T...&gt;, int index);</d=
iv></blockquote><div><br>It will give a compilation error if you pass nothi=
ng in `T`. <i>Which it should</i>, since there is nothing that `runtime_get=
` could possibly return. <br></div></blockquote><div><br>I want to make tha=
t a bit more clear. The implementation of `runtime_get` must, at some point=
, call `std::get&lt;&gt;` with some compile-time index. If the tuple has no=
 types, then there is no way to call `std::get&lt;&gt;` on it with <i>any i=
ndex</i>. </div></div></blockquote><div><br><div style=3D"text-align:left">=
<div dir=3D"ltr"><div>template&lt;class... T&gt;<br>variant&lt;T...&gt;
 get_impl(int i, std::integral_constant&lt;int, -1&gt;,=20
tuple&lt;T...&gt;&amp;) { throw std::out_of_range(); }<br><br>template&lt;c=
lass... T, int j&gt;<br>variant&lt;T...&gt; get_impl(int i, std::integral_c=
onstant&lt;int, j&gt;, tuple&lt;T...&gt;&amp;x )=C2=A0 { <br>=C2=A0=C2=A0=
=C2=A0=C2=A0 return i =3D=3D j? get&lt;j&gt;(x) : get_impl(i, integral_cons=
tant&lt;int, j-1&gt;{}, x);<br>}<br><br>template&lt;class... T&gt;<br>varia=
nt&lt;T...&gt;
 runtime_get(int i, tuple&lt;T...&gt;&amp; x) { return get_impl(i,=20
std::integral_constant&lt;int, sizeof...(T)-1&gt;{}, x);<br></div></div></d=
iv></div></blockquote><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote"><di=
v>=C2=A0</div></blockquote><blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div><di=
v style=3D"text-align:left"><div dir=3D"ltr"><div>The=20
above works for any variant, including variant&lt;&gt;, without any=20
special handling. If variant&lt;&gt; is not valid, suddenly any user of=20
runtime_get need handle the corner case.</div></div></div></div></blockquot=
e><div><br>Here&#39;s the thing: N4542 doesn&#39;t make `variant&lt;&gt;` i=
nvalid. What it does is make it <i>not constructible</i> (at least, not its=
 default constructor). So your code would work fine, because it statically =
never attempts to construct such a thing.<br><br>So where&#39;s the problem=
? You can&#39;t make one. You can&#39;t use one. But you can stick it in a =
function&#39;s return type, so long as the function that tries to return it=
 never actually returns it.<br><br>Isn&#39;t that good enough?<br></div></b=
lockquote><div><br>I might want to do something like this:<br><br>std::vect=
or&lt;variant&lt;&gt; &gt; foo() { return {}; };<br><br>as long as I&#39;m =
allowed to call foo and copy the resulting vector around think I would be o=
k with variant as specified.=C2=A0 I thought a bit about it and I couldn&#3=
9;t come up with a case I might actually want to create an object of varian=
t&lt;&gt;.</div></blockquote><div><br>`vector` seems to be able to handle a=
 non-constructible object just fine. So long as you don&#39;t actually inse=
rt elements into it, you can create them, copy/move them around, etc.<br><b=
r>As for the size, it&#39;s more or less irrelevant. As long as it has <i>s=
ome</i> size (and is therefore a valid object), it should be fine.<br>=C2=
=A0</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 />

------=_Part_708_1663583928.1446212228117--
------=_Part_707_362677812.1446212228117--

.