Topic: On variant<Ts...>, any and optional<T> Coherency
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 9 Sep 2015 19:09:31 +0200
Raw View
This is a multi-part message in MIME format.
--------------090903030301020400030004
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi,
This proposal [1] identifies some minor inconveniences in the design of
|variant<Ts...>|, |any| and |optional<T>|, diagnoses them as owing to
unnecessary asymmetry between those classes, and proposes wording to
eliminate the asymmetry.
Any help to improve the proposal is welcome.
Vicente
[1]
https://github.com/viboes/std-make/blob/master/doc/proposal/any_optional/D0032.pdf
--
---
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/.
--------------090903030301020400030004
Content-Type: text/html; charset=UTF-8
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font size="+1">Hi,<br>
</font><br>
This proposal [1] identifies some minor inconveniences in the design
of
<code>variant<Ts...></code>, <code>any</code> and <code>optional<T></code>,
diagnoses them as owing to unnecessary asymmetry between those
classes, and proposes wording to eliminate the asymmetry.
<br>
<br>
Any help to improve the proposal is welcome.<br>
<br>
Vicente<br>
<br>
<title></title>
<meta name="GENERATOR" content="OpenOffice.org 3.3 (Unix)">
<style type="text/css">
<!--
@page { margin: 2cm }
P { margin-bottom: 0.21cm }
-->
</style>[1] <a class="moz-txt-link-freetext"
href="https://github.com/viboes/std-make/blob/master/doc/proposal/any_optional/D0032.pdf">https://github.com/viboes/std-make/blob/master/doc/proposal/any_optional/D0032.pdf</a>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" 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 />
--------------090903030301020400030004--
.
Author: =?UTF-8?Q?Agust=c3=adn_K-ballo_Berg=c3=a9?= <kaballo86@hotmail.com>
Date: Wed, 9 Sep 2015 15:42:14 -0300
Raw View
On 9/9/2015 2:09 PM, Vicente J. Botet Escriba wrote:
> Hi,
>
> This proposal [1] identifies some minor inconveniences in the design of
> |variant<Ts...>|, |any| and |optional<T>|, diagnoses them as owing to
> unnecessary asymmetry between those classes, and proposes wording to
> eliminate the asymmetry.
>
> Any help to improve the proposal is welcome.
On `any` and `none`:
> Instead of an additional type none_t to declare the constant none as
>
> constexpr none_t none{}
>
> we can just declare it as
>
> constexpr any none{}
>
> which plays well its role.
I don't think one can have a constexpr `any` object, as I don't think=20
one can have a trivially-destructible `any` implementation. But for that=20
same reason, it should not be necessary for `none` to be `constexpr`.
The constexpr `any` default constructor is still needed though, to=20
guarantee that
any const none{};
is statically initialized and can safely be used before `main`.
Regards,
--=20
Agust=C3=ADn K-ballo Berg=C3=A9.-
http://talesofcpp.fusionfenix.com
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 9 Sep 2015 12:20:35 -0700 (PDT)
Raw View
------=_Part_4927_1812060178.1441826435240
Content-Type: multipart/alternative;
boundary="----=_Part_4928_2103618376.1441826435241"
------=_Part_4928_2103618376.1441826435241
Content-Type: text/plain; charset=UTF-8
>
> variant<Ts...> and optional provides in place construction with different
> syntax while any requires a specific instance.
I agree that this should be added to `any`.
However, my reason for agreeing is not for orthogonality. It is because
this gives `any` genuinely useful functionality.
variant<Ts...> and optional provides emplace assignment while any requires
> a specific instance to be assigned.
>
Ditto.
The in place tags for variant<Ts...> and optional are different. However
> the name should be the same.
.... why? They work in very different ways. If you're emplacing an
`optional`, the compiler knows what type you're trying to construct. But
with `variant`, that is unknown and thus must be provided. So it makes
sense that they use two different mechanisms, since the interfaces have two
different needs.
The user of `optional` should never have to do this:
std::optional<T> val = {emplace_construct<T>, ...};
The extra `T` is pointless redundancy, and makes the code needlessly more
brittle if you need to change `T`.
I could understand sharing the emplace tag with `variant` and `any`. But
there's no point in forcing that syntactic noise into `optional`.
optional provides a explicit bool conversion while any provides an
> any::empty member function. If variant<Ts...> proposal ends been possibly
> empty, we expect that it will have a explicit bool conversion.
It is important to note that, under N4542, the "empty" state for a
`variant` is not a genuine state. It is instead an error condition. You
must always construct the variant with a particular type; it only becomes
empty if an exception is thrown during a copy/move. And thus, the use case
for the empty state is very different from the others.
That doesn't justify having a different interface though; it's just an
observation.
optional<T>, variant<Ts...> and any provides different interfaces to get
> the stored value. optional uses a value member function, variant uses a
> tuple like interface, while any uses a cast like interface. As all these
> classes are in someway sum types, the first two limited and know at compile
> time, the last unlimited, it seems natural that both provide the same kind
> of interface. In addition it seems natural that the exception thrown when
> the access/cast fails inherits from a common exception bad_cast.
You consider these three types to all be "sum types". But that's not the
only way to view these types. What if we see them as three different types
with distinct usage patterns?
As N4542 plainly stated, `variant` is not an `any`. To the user, they are
very different things with very different use cases. Complete type erausre
is a key feature of `any`, which `variant` does not provide. And generally
speaking, if you are testing an `any` for more than one or two types,
you're using it wrong.
Unions are to `variant`s as structs are to `tuple`s. Therefore, it makes
perfect sense for `variant` to use a `tuple`-like interface.
However, `any` is nothing like a union. Conceptually, `any` is a type-safe,
value-oriented `void*`. And that is how users are more likely to use it: as
a replacement for a `void*`. Since an `any` is more similar to a `void*`
than a union, accessing one should conceptually be a cast operation. And
casting makes no sense for union-like `variant`s.
Similarly, the usage pattern for `optional` has nothing to do with either
`variant` or `any`. The user thinks of it as a value which could be present
or absent. And while you could do the same thing with an `any` or a
`variant` with `monostate`... why go through the pointless syntactic burden
of that? Just use the type that it is: `optional`.
Because `optional` only has one type, it is perfectly legitimate to provide
direct access to the value via `->`. That makes no sense for `variant` or
`any`. Same goes for having a member-wise accessor; since the type that is
retrieved cannot be anything other than `T`, there's no point in having a
larger interface.
Generally speaking, people will not have long, philosophical debates with
themselves about whether to use `variant`, `optional`, or `any`. Nor are
they likely to suddenly change from using one to the other. They'll pick
the one that is most obvious for their use case.
Why is it important to unify these very different objects under the concept
of "sum types"? What do we gain from giving them all the same interface,
even if that interface is rather unnatural for that specific object type?
Is there some use case for generic code that could use both `variant` and
`any` effectively?
--
---
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_4928_2103618376.1441826435241
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-lef=
t: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">=
<code>variant<Ts...></code> and <code>optional</code>
provides in place construction with different syntax while <code>any</code=
>
requires a specific instance.</blockquote><div><br>I agree that this shoul=
d be added to `any`.<br><br>However, my reason for agreeing is not for orth=
ogonality. It is because this gives `any` genuinely useful functionality.<b=
r><br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px soli=
d rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote"><code>varia=
nt<Ts...></code> and <code>optional</code>
provides emplace assignment while <code>any</code> requires a
specific instance to be assigned.<br></blockquote><div><br>Ditto.<br><br><=
blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(2=
04, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">The in place tags =
for <code>variant<Ts...></code> and
<code>optional</code> are different. However the name should be the
same.</blockquote><div><br>... why? They work in very different ways. If y=
ou're emplacing an `optional`, the compiler knows what type you're =
trying to construct. But with `variant`, that is unknown and thus must be p=
rovided. So it makes sense that they use two different mechanisms, since th=
e interfaces have two different needs.<br><br>The user of `optional` should=
never have to do this:<br><br><div class=3D"prettyprint" style=3D"backgrou=
nd-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-styl=
e: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyp=
rint"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">std</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">optional</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
"><</span><span style=3D"color: #000;" class=3D"styled-by-prettify">T</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">></span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> val </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">emplace_construct</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify"><</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">>,</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">...};</span></div></code></div><br>The extra `T` is pointless redundanc=
y, and makes the code needlessly more brittle if you need to change `T`.<br=
><br>I could understand sharing the emplace tag with `variant` and `any`. B=
ut there's no point in forcing that syntactic noise into `optional`.<br=
><br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid=
rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote"><code>option=
al</code> provides a <code>explicit bool</code>
conversion while <code>any</code> provides an <code>any::empty</code>
member function. If <code>variant<Ts...></code> proposal ends
been possibly empty, we expect that it will have a <code>explicit
bool</code> conversion.
</blockquote><div><br>It is important to note that, under N4542, the "=
empty" state for a `variant` is not a genuine state. It is instead an =
error condition. You must always construct the variant with a particular ty=
pe; it only becomes empty if an exception is thrown during a copy/move. And=
thus, the use case for the empty state is very different from the others.<=
br><br>That doesn't justify having a different interface though; it'=
;s just an observation.<br><br><blockquote style=3D"margin: 0px 0px 0px 0.8=
ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D=
"gmail_quote"><code>optional<T></code>, <code>variant<Ts...></c=
ode>
and <code>any</code> provides different interfaces to get the stored
value. <code>optional</code> uses a <code>value</code> member
function, <code>variant</code> uses a tuple like interface, while
<code>any</code> uses a cast like interface. As all these classes
are in someway sum types, the first two limited and know at compile
time, the last unlimited, it seems natural that both provide the
same kind of interface. In addition it seems natural that the
exception thrown when the access/cast fails inherits from a common
exception <font face=3D"Courier New, monospace">bad_cast</font>.</blockquo=
te><div><br>You consider these three types to all be "sum types".=
But that's not the only way to view these types. What if we see them a=
s three different types with distinct usage patterns?<br><br>As N4542 plain=
ly stated, `variant` is not an `any`. To the user, they are very different =
things with very different use cases. Complete type erausre is a key featur=
e of `any`, which `variant` does not provide. And generally speaking, if yo=
u are testing an `any` for more than one or two types, you're using it =
wrong.<br><br>Unions are to `variant`s as structs are to `tuple`s. Therefor=
e, it makes=20
perfect sense for `variant` to use a `tuple`-like interface.<br><br>However=
, `any` is=20
nothing like a union. Conceptually, `any` is a type-safe, value-oriented `v=
oid*`. And that is how users are more likely to use it: as a replacement fo=
r a `void*`. Since an `any` is more similar to a `void*` than a union, acce=
ssing one should conceptually be a cast operation. And casting makes no sen=
se for union-like `variant`s.<br><br>Similarly, the usage pattern for `opti=
onal` has nothing to do with either `variant` or `any`. The user thinks of =
it as a value which could be present or absent. And while you could do the =
same thing with an `any` or a `variant` with `monostate`... why go through =
the pointless syntactic burden of that? Just use the type that it is: `opti=
onal`.<br><br>Because `optional` only has one type, it is perfectly legitim=
ate to provide direct access to the value via `->`. That makes no sense =
for `variant` or `any`. Same goes for having a member-wise accessor; since =
the type that is retrieved cannot be anything other than `T`, there's n=
o point in having a larger interface.<br><br>Generally speaking, people wil=
l not have long, philosophical debates with themselves about whether to use=
`variant`, `optional`, or `any`. Nor are they likely to suddenly change fr=
om using one to the other. They'll pick the one that is most obvious fo=
r their use case.<br><br>Why is it important to unify these very different =
objects under the concept of "sum types"? What do we gain from gi=
ving them all the same interface, even if that interface is rather unnatura=
l for that specific object type? Is there some use case for generic code th=
at could use both `variant` and `any` effectively?<br></div></div></div></d=
iv></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" 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_4928_2103618376.1441826435241--
------=_Part_4927_1812060178.1441826435240--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 9 Sep 2015 23:41:28 +0200
Raw View
Le 09/09/15 20:42, Agust=C3=ADn K-ballo Berg=C3=A9 a =C3=A9crit :
> On 9/9/2015 2:09 PM, Vicente J. Botet Escriba wrote:
>> Hi,
>>
>> This proposal [1] identifies some minor inconveniences in the design of
>> |variant<Ts...>|, |any| and |optional<T>|, diagnoses them as owing to
>> unnecessary asymmetry between those classes, and proposes wording to
>> eliminate the asymmetry.
>>
>> Any help to improve the proposal is welcome.
>
> On `any` and `none`:
>
> > Instead of an additional type none_t to declare the constant none as
> >
> > constexpr none_t none{}
> >
> > we can just declare it as
> >
> > constexpr any none{}
> >
> > which plays well its role.
>
> I don't think one can have a constexpr `any` object, as I don't think=20
> one can have a trivially-destructible `any` implementation. But for=20
> that same reason, it should not be necessary for `none` to be=20
> `constexpr`.
>
Right.
> The constexpr `any` default constructor is still needed though, to=20
> guarantee that
>
> any const none{};
>
> is statically initialized and can safely be used before `main`.
>
Right.
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 9 Sep 2015 23:48:12 +0200
Raw View
Le 09/09/15 21:20, Nicol Bolas a =C3=A9crit :
>> variant<Ts...> and optional provides in place construction with differen=
t
>> syntax while any requires a specific instance.
>
> I agree that this should be added to `any`.
>
> However, my reason for agreeing is not for orthogonality. It is because
> this gives `any` genuinely useful functionality.
I agree with the useful functionality.
>
> variant<Ts...> and optional provides emplace assignment while any require=
s
>> a specific instance to be assigned.
>>
> Ditto.
>
> The in place tags for variant<Ts...> and optional are different. However
>> the name should be the same.
>
> ... why?
Because the tags plays the same role. We want to emplace the stored=20
type. With optional this type is implicit.
The user don't needs to change the verb, just add a subject when needed.
> They work in very different ways. If you're emplacing an
> `optional`, the compiler knows what type you're trying to construct. But
> with `variant`, that is unknown and thus must be provided. So it makes
> sense that they use two different mechanisms, since the interfaces have t=
wo
> different needs.
>
> The user of `optional` should never have to do this:
>
> std::optional<T> val =3D {emplace_construct<T>, ...};
>
> The extra `T` is pointless redundancy, and makes the code needlessly more
> brittle if you need to change `T`.
>
> I could understand sharing the emplace tag with `variant` and `any`. But
> there's no point in forcing that syntactic noise into `optional`.
I'm not proposing to change the optional interface from the user point=20
of view.
>
> optional provides a explicit bool conversion while any provides an
>> any::empty member function. If variant<Ts...> proposal ends been possibl=
y
>> empty, we expect that it will have a explicit bool conversion.
>
> It is important to note that, under N4542, the "empty" state for a
> `variant` is not a genuine state. It is instead an error condition. You
> must always construct the variant with a particular type; it only becomes
> empty if an exception is thrown during a copy/move. And thus, the use cas=
e
> for the empty state is very different from the others.
>
> That doesn't justify having a different interface though; it's just an
> observation.
Sorry, I misread the proposal. I believed that the author have changed=20
to an possible empty variant. In my proposal I say
"If variant<Ts...> proposal ends been possibly empty, ...."
>
> optional<T>, variant<Ts...> and any provides different interfaces to get
>> the stored value. optional uses a value member function, variant uses a
>> tuple like interface, while any uses a cast like interface. As all these
>> classes are in someway sum types, the first two limited and know at comp=
ile
>> time, the last unlimited, it seems natural that both provide the same ki=
nd
>> of interface. In addition it seems natural that the exception thrown whe=
n
>> the access/cast fails inherits from a common exception bad_cast.
>
> You consider these three types to all be "sum types". But that's not the
> only way to view these types. What if we see them as three different type=
s
> with distinct usage patterns?
>
> As N4542 plainly stated, `variant` is not an `any`.
Completely agreed. This is why we have two classes ;-)
> To the user, they are
> very different things with very different use cases. Complete type erausr=
e
> is a key feature of `any`, which `variant` does not provide. And generall=
y
> speaking, if you are testing an `any` for more than one or two types,
> you're using it wrong.
I believe the same applies for variant. When there are several=20
possibilities we should use a visitor (match).
>
> Unions are to `variant`s as structs are to `tuple`s. Therefore, it makes
> perfect sense for `variant` to use a `tuple`-like interface.
I don't see why this follows. The access to a variant can throw, while=20
the access to a tuple can not. This is why I prefer the _cast suffix.=20
Anyway, independently of the name, the signatures of the accessors to=20
any and variant must be isomorphic. Having variant_cats/get/get_if don't=20
help.
>
> However, `any` is nothing like a union. Conceptually, `any` is a type-saf=
e,
> value-oriented `void*`. And that is how users are more likely to use it: =
as
> a replacement for a `void*`. Since an `any` is more similar to a `void*`
> than a union, accessing one should conceptually be a cast operation. And
> casting makes no sense for union-like `variant`s.
Why? See above.
>
> Similarly, the usage pattern for `optional` has nothing to do with either
> `variant` or `any`. The user thinks of it as a value which could be prese=
nt
> or absent. And while you could do the same thing with an `any` or a
> `variant` with `monostate`... why go through the pointless syntactic burd=
en
> of that? Just use the type that it is: `optional`.
Do you have a valid reason to have different names for functions that do=20
the same thing?
>
> Because `optional` only has one type, it is perfectly legitimate to provi=
de
> direct access to the value via `->`. That makes no sense for `variant` or
> `any`. Same goes for having a member-wise accessor; since the type that i=
s
> retrieved cannot be anything other than `T`, there's no point in having a
> larger interface.
I'm not saying that optional and variant are the same. Just that any sum=20
type algorithm can be applied to either variant or to optional.
IMO, this relation is similar to the relation between pair and tuple.
> Generally speaking, people will not have long, philosophical debates with
> themselves about whether to use `variant`, `optional`, or `any`. Nor are
> they likely to suddenly change from using one to the other. They'll pick
> the one that is most obvious for their use case.
I'm not saying that people will or should do this. Just the vocabulary=20
should be the same when the meaning is the same. Having a common=20
interface for the same meaning makes these interfaces simpler.
>
> Why is it important to unify these very different objects under the conce=
pt
> of "sum types"? What do we gain from giving them all the same interface,
> even if that interface is rather unnatural for that specific object type?
> Is there some use case for generic code that could use both `variant` and
> `any` effectively?
>
I believe however that it is easier to teach and learn. This ensure also=20
that we avoid divergences when not needed.
Thanks for your comments,
Vicente
P.S. Originally the paper was only about optional and any.variant came=20
very recently.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Thu, 10 Sep 2015 13:56:44 -0400
Raw View
--001a11c3c8ba7fef2f051f68529f
Content-Type: text/plain; charset=UTF-8
On Wed, Sep 9, 2015 at 1:09 PM, Vicente J. Botet Escriba <
vicente.botet@wanadoo.fr> wrote:
> Hi,
>
> This proposal [1] identifies some minor inconveniences in the design of
> variant<Ts...>, any and optional<T>, diagnoses them as owing to
> unnecessary asymmetry between those classes, and proposes wording to
> eliminate the asymmetry.
>
> Any help to improve the proposal is welcome.
>
> Vicente
>
> [1]
> https://github.com/viboes/std-make/blob/master/doc/proposal/any_optional/D0032.pdf
>
> --
>
I would appreciate very clear before/after examples for each change. ie
for in_place, I'd like to see (and I have no idea if I have the examples
correct, but just to get the idea)
Given
struct Foo { Foo(int, double, char); };
Before:
optional<Foo> of(emplace_type, 0, 1.5, 'c');
variant<int, Foo> vf(emplace_index<1>, 0, 1.5, 'c');
any af(in_place<Foo>, 0, 1.5, 'c');
After:
optional<Foo> of(in_place, 0, 1.5, 'c');
variant<int, Foo> vf(in_place<1>, 0, 1.5, 'c');
any af(in_place<Foo>, 0, 1.5, 'c');
Changes required:
.....
--
---
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/.
--001a11c3c8ba7fef2f051f68529f
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 Wed, Sep 9, 2015 at 1:09 PM, Vicente J. Botet Escriba <span dir=3D"l=
tr"><<a href=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_blank">vicen=
te.botet@wanadoo.fr</a>></span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<font size=3D"+1">Hi,<br>
</font><br>
This proposal [1] identifies some minor inconveniences in the design
of
<code>variant<Ts...></code>, <code>any</code> and <code>optional&=
lt;T></code>,
diagnoses them as owing to unnecessary asymmetry between those
classes, and proposes wording to eliminate the asymmetry.
<br>
<br>
Any help to improve the proposal is welcome.<br>
<br>
Vicente<br>
<br>
=20
=20
[1] <a href=3D"https://github.com/viboes/std-make/blob/master/doc/propo=
sal/any_optional/D0032.pdf" target=3D"_blank">https://github.com/viboes/std=
-make/blob/master/doc/proposal/any_optional/D0032.pdf</a><span class=3D""><=
font color=3D"#888888">
</font></span></div><span class=3D""><font color=3D"#888888">
<p></p>
-- </font></span><br></blockquote></div><br></div><div class=3D"gmail_extra=
">I would appreciate very clear before/after examples for each change.=C2=
=A0 ie for in_place, I'd like to see (and I have no idea if I have the =
examples correct, but just to get the idea)<br><br></div><div class=3D"gmai=
l_extra"><div class=3D"gmail_extra">Given<br>struct Foo { Foo(int, double, =
char); };<br></div><div class=3D"gmail_extra"><br></div>Before:<br><br></di=
v>optional<Foo> of(emplace_type, 0, 1.5, 'c');<br><div class=
=3D"gmail_extra">variant<int, Foo> vf(emplace_index<1>, 0, 1.5,=
'c');<br></div><div class=3D"gmail_extra">any af(in_place<Foo&g=
t;, 0, 1.5, 'c');<br><br></div><div class=3D"gmail_extra">After:<br=
><br><div class=3D"gmail_extra">optional<Foo> of(in_place, 0, 1.5, &#=
39;c');<br></div><div class=3D"gmail_extra">variant<int, Foo> vf(=
in_place<1>, 0, 1.5, 'c');<br></div>any af(in_place<Foo>=
;, 0, 1.5, 'c');<br><br></div><div class=3D"gmail_extra">Changes re=
quired:<br>....<br><br><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" 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 />
--001a11c3c8ba7fef2f051f68529f--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Thu, 10 Sep 2015 14:07:54 -0400
Raw View
--001a11c3b9aa73ef10051f687a07
Content-Type: text/plain; charset=UTF-8
On Wed, Sep 9, 2015 at 1:09 PM, Vicente J. Botet Escriba <
vicente.botet@wanadoo.fr> wrote:
> Hi,
>
> This proposal [1] identifies some minor inconveniences in the design of
> variant<Ts...>, any and optional<T>, diagnoses them as owing to
> unnecessary asymmetry between those classes, and proposes wording to
> eliminate the asymmetry.
>
> Any help to improve the proposal is welcome.
>
> Vicente
>
> [1]
> https://github.com/viboes/std-make/blob/master/doc/proposal/any_optional/D0032.pdf
>
> --
>
For _cast functions, are conversions ever performed?
(the following syntax is probably incorrect, sorry:)
struct Base {};
struct Derived : Base {};
any a = Derived();
Base base = any_cast<Base>(a);
does the stored value get casted to a Base?
I don't think variant will cast (ie convert) between similar types:
variant<int, double> v = 1.5;
int one = variant_cast<int>(v);
should I expect that to work? Or throw bad_cast?
If/When there is no conversion, I don't like calling it "cast".
--
---
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/.
--001a11c3b9aa73ef10051f687a07
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 Wed, Sep 9, 2015 at 1:09 PM, Vicente J. Botet Escriba <span dir=3D"l=
tr"><<a href=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_blank">vicen=
te.botet@wanadoo.fr</a>></span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<font size=3D"+1">Hi,<br>
</font><br>
This proposal [1] identifies some minor inconveniences in the design
of
<code>variant<Ts...></code>, <code>any</code> and <code>optional&=
lt;T></code>,
diagnoses them as owing to unnecessary asymmetry between those
classes, and proposes wording to eliminate the asymmetry.
<br>
<br>
Any help to improve the proposal is welcome.<br>
<br>
Vicente<br>
<br>
=20
=20
[1] <a href=3D"https://github.com/viboes/std-make/blob/master/doc/propo=
sal/any_optional/D0032.pdf" target=3D"_blank">https://github.com/viboes/std=
-make/blob/master/doc/proposal/any_optional/D0032.pdf</a><span class=3D"HOE=
nZb"><font color=3D"#888888">
</font></span></div><span class=3D"HOEnZb"><font color=3D"#888888">
<p></p>
-- </font></span><br></blockquote></div><br></div><div class=3D"gmail_extra=
">For _cast functions, are conversions ever performed?<br><br></div><div cl=
ass=3D"gmail_extra">(the following syntax is probably incorrect, sorry:)<br=
><br></div><div class=3D"gmail_extra">=C2=A0=C2=A0=C2=A0 struct Base {};<br=
></div><div class=3D"gmail_extra">=C2=A0=C2=A0=C2=A0 struct Derived : Base =
{};<br><br></div><div class=3D"gmail_extra">=C2=A0=C2=A0=C2=A0 any a =3D De=
rived();<br></div><div class=3D"gmail_extra">=C2=A0=C2=A0=C2=A0 Base base =
=3D any_cast<Base>(a);<br><br></div><div class=3D"gmail_extra">does t=
he stored value get casted to a Base?<br><br></div><div class=3D"gmail_extr=
a">I don't think variant will cast (ie convert) between similar types:<=
br><br></div><div class=3D"gmail_extra">=C2=A0=C2=A0=C2=A0 variant<int, =
double> v =3D 1.5;<br></div><div class=3D"gmail_extra">=C2=A0=C2=A0=C2=
=A0 int one =3D variant_cast<int>(v);<br><br></div><div class=3D"gmai=
l_extra">should I expect that to work? Or throw bad_cast?<br><br></div><div=
class=3D"gmail_extra">If/When there is no conversion, I don't like cal=
ling it "cast".<br><br><br></div><div class=3D"gmail_extra"><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" 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 />
--001a11c3b9aa73ef10051f687a07--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 10 Sep 2015 20:09:51 +0200
Raw View
Le 10/09/15 19:56, Tony V E a =C3=A9crit :
> On Wed, Sep 9, 2015 at 1:09 PM, Vicente J. Botet Escriba <
> vicente.botet@wanadoo.fr> wrote:
>
>> Hi,
>>
>> This proposal [1] identifies some minor inconveniences in the design of
>> variant<Ts...>, any and optional<T>, diagnoses them as owing to
>> unnecessary asymmetry between those classes, and proposes wording to
>> eliminate the asymmetry.
>>
>> Any help to improve the proposal is welcome.
>>
>> Vicente
>>
>> [1]
>> https://github.com/viboes/std-make/blob/master/doc/proposal/any_optional=
/D0032.pdf
>>
>> --
>>
> I would appreciate very clear before/after examples for each change.
I believed it was clear enough. I will do if it improves the proposal.
> ie
> for in_place, I'd like to see (and I have no idea if I have the examples
> correct, but just to get the idea)
>
> Given
> struct Foo { Foo(int, double, char); };
>
> Before:
>
> optional<Foo> of(emplace_type, 0, 1.5, 'c');
Currently std::experimental::optional doesn't use emplace_type by in_place
optional<Foo> of(in_place, 0, 1.5, 'c');
For the rest everything is correct.
> variant<int, Foo> vf(emplace_index<1>, 0, 1.5, 'c');
>
variant<int, Foo> vf(emplace_type<Foo>, 0, 1.5, 'c');
> any af(in_place<Foo>, 0, 1.5, 'c');
>
> After:
>
> optional<Foo> of(in_place, 0, 1.5, 'c');
> variant<int, Foo> vf(in_place<1>, 0, 1.5, 'c');
variant<int, Foo> vf(in_place<Foo>, 0, 1.5, 'c');
> any af(in_place<Foo>, 0, 1.5, 'c');
>
> Changes required:
> ....
>
No changes from the user point of view if you consider that the variant=20
proposal has not been adopted yet.
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Thu, 10 Sep 2015 14:26:58 -0400
Raw View
--001a11c3f5bea3fe32051f68bee2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thu, Sep 10, 2015 at 2:09 PM, Vicente J. Botet Escriba <
vicente.botet@wanadoo.fr> wrote:
> Le 10/09/15 19:56, Tony V E a =C3=A9crit :
>
>> On Wed, Sep 9, 2015 at 1:09 PM, Vicente J. Botet Escriba <
>>
>> https://github.com/viboes/std-make/blob/master/doc/proposal/any_optional=
/D0032.pdf
>>
>>>
>>> --
>>>
>>> I would appreciate very clear before/after examples for each change.
>>
> I believed it was clear enough. I will do if it improves the proposal.
>
It would help me :-)
And I think it makes your point glaringly obvious, instead of me needing to
imagine code.
I think it makes the asymmetries look ugly, and the new symmetry as the
obvious winner.
ie I think it would help the committee agree with you. :-)
> ie
>> for in_place, I'd like to see (and I have no idea if I have the examples
>> correct, but just to get the idea)
>>
>> Given
>> struct Foo { Foo(int, double, char); };
>>
>> Before:
>>
>> optional<Foo> of(emplace_type, 0, 1.5, 'c');
>>
>
> Currently std::experimental::optional doesn't use emplace_type by in_plac=
e
>
> optional<Foo> of(in_place, 0, 1.5, 'c');
>
> For the rest everything is correct.
>
> variant<int, Foo> vf(emplace_index<1>, 0, 1.5, 'c');
>>
>>
> variant<int, Foo> vf(emplace_type<Foo>, 0, 1.5, 'c');
>
> any af(in_place<Foo>, 0, 1.5, 'c');
>>
>> After:
>>
>> optional<Foo> of(in_place, 0, 1.5, 'c');
>> variant<int, Foo> vf(in_place<1>, 0, 1.5, 'c');
>>
>
> variant<int, Foo> vf(in_place<Foo>, 0, 1.5, 'c');
>
> any af(in_place<Foo>, 0, 1.5, 'c');
>>
>> Changes required:
>> ....
>>
>> No changes from the user point of view if you consider that the variant
> proposal has not been adopted yet.
>
By Changes, I mean that is where you would list the technical changes that
you are suggesting for each TS.
Basically, it means putting a motivating example as the first thing for
each change. Once I see the motivation, you've already sold me on the
idea. I can then mostly gloss over what needs to change to make it
possible (as long as it isn't toooo scary).
Put the best selling point - examples of better looking code - first.
IMO.
Tony
> Vicente
>
>
> --
>
> --- You received this message because you are subscribed to the Google
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a11c3f5bea3fe32051f68bee2
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, Sep 10, 2015 at 2:09 PM, Vicente J. Botet Escriba <span dir=3D"=
ltr"><<a href=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_blank">vice=
nte.botet@wanadoo.fr</a>></span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex">Le 10/09/15 19:56, Tony V E a =C3=A9crit :<span class=
=3D""><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">
On Wed, Sep 9, 2015 at 1:09 PM, Vicente J. Botet Escriba <<br><a href=3D=
"https://github.com/viboes/std-make/blob/master/doc/proposal/any_optional/D=
0032.pdf" rel=3D"noreferrer" target=3D"_blank">https://github.com/viboes/st=
d-make/blob/master/doc/proposal/any_optional/D0032.pdf</a><br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex">
<br>
--<br>
<br>
</blockquote>
I would appreciate very clear before/after examples for each change.<br>
</blockquote></span>
I believed it was clear enough. I will do if it improves the proposal.<span=
class=3D""><br></span></blockquote><div><br></div><div>It would help me :-=
)<br></div><div>And I think it makes your point glaringly obvious, instead =
of me needing to imagine code.<br><br></div><div>I think it makes the asymm=
etries look ugly, and the new symmetry as the obvious winner.<br></div><div=
>ie I think it would help the committee agree with you. :-)<br></div><div>=
=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"><span cla=
ss=3D"">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">
=C2=A0 ie<br>
for in_place, I'd like to see (and I have no idea if I have the example=
s<br>
correct, but just to get the idea)<br>
<br>
Given<br>
struct Foo { Foo(int, double, char); };<br>
<br>
Before:<br>
<br>
optional<Foo> of(emplace_type, 0, 1.5, 'c');<br>
</blockquote>
<br></span>
Currently std::experimental::optional doesn't use emplace_type by in_pl=
ace<span class=3D""><br>
<br>
optional<Foo> of(in_place, 0, 1.5, 'c');<br>
<br></span>
For the rest everything is correct.<span class=3D""><br>
<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">
variant<int, Foo> vf(emplace_index<1>, 0, 1.5, 'c');<br=
>
<br>
</blockquote>
<br></span>
variant<int, Foo> vf(emplace_type<Foo>, 0, 1.5, 'c');<s=
pan class=3D""><br>
<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">
any af(in_place<Foo>, 0, 1.5, 'c');<br>
<br>
After:<br>
<br>
optional<Foo> of(in_place, 0, 1.5, 'c');<br>
variant<int, Foo> vf(in_place<1>, 0, 1.5, 'c');<br>
</blockquote>
<br></span>
variant<int, Foo> vf(in_place<Foo>, 0, 1.5, 'c');<span =
class=3D""><br>
<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">
any af(in_place<Foo>, 0, 1.5, 'c');<br>
<br>
Changes required:<br>
.....<br>
<br>
</blockquote></span>
No changes from the user point of view if you consider that the variant pro=
posal has not been adopted yet.<span class=3D""><font color=3D"#888888"><br=
></font></span></blockquote><div><br></div><div>By Changes, I mean that is =
where you would list the technical changes that you are suggesting for each=
TS.<br></div><div>Basically, it means putting a motivating example as the =
first thing for each change.=C2=A0 Once I see the motivation, you've al=
ready sold me on the idea.=C2=A0 I can then mostly gloss over what needs to=
change to make it possible (as long as it isn't toooo scary).<br></div=
><div>Put the best selling point - examples of better looking code - first.=
<br></div><div><br></div><div>IMO.<br></div><div>Tony<br><br></div><blockqu=
ote 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""><font color=3D"#=
888888">
<br>
Vicente</font></span><div class=3D""><div class=3D"h5"><br>
<br>
-- <br>
<br>
--- You received this message because you are subscribed to the Google Grou=
ps "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@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/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/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" 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 />
--001a11c3f5bea3fe32051f68bee2--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Thu, 10 Sep 2015 14:43:38 -0400
Raw View
--089e0158c3b2334144051f68faa3
Content-Type: text/plain; charset=UTF-8
On Wed, Sep 9, 2015 at 1:09 PM, Vicente J. Botet Escriba <
vicente.botet@wanadoo.fr> wrote:
>
>
> [1]
> https://github.com/viboes/std-make/blob/master/doc/proposal/any_optional/D0032.pdf
>
> --
>
>
Also:
- in general, thanks for doing this. I've been wanting to do a complete
table of "categories" and APIs in the STL (ie containers, pointers, etc)
and point out what should be consistent, what should be purposely
different, etc. ie as you mention, variant/any/optional are not
containers, so should not act like containers - they are their own category
(closer to pointers).
- reset vs clear - I agree, reset should be used.
- whether variant uses empty() should depend on whether it is a "fully
exposed" state or just an error state. As an error state, I think
valid/is_valid is better. Because in that case it is different than empty.
- operator bool. See
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3765.pdf I still
wonder if we should remove it completely, and use a named function. But I
agree they (at least optional and any) should be the same.
- should sum_cast go a step further and just be called try_cast? Use it
anywhere we try to convert from A to B that can result in bad_cast. (ie
dynamic_cast could be a try_cast). Or does that just lead to never ending
talks on conversion libraries?
--
---
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/.
--089e0158c3b2334144051f68faa3
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 Wed, Sep 9, 2015 at 1:09 PM, Vicente J. Botet Escriba <span dir=3D"l=
tr"><<a href=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_blank">vicen=
te.botet@wanadoo.fr</a>></span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<br>
<br>
=20
=20
[1] <a href=3D"https://github.com/viboes/std-make/blob/master/doc/propo=
sal/any_optional/D0032.pdf" target=3D"_blank">https://github.com/viboes/std=
-make/blob/master/doc/proposal/any_optional/D0032.pdf</a><span class=3D""><=
font color=3D"#888888">
</font></span></div><span class=3D""><font color=3D"#888888">
<p></p>
-- <br>
</font></span><br></blockquote></div><br></div><div class=3D"gmail_extra">A=
lso:<br><br></div><div class=3D"gmail_extra">- in general, thanks for doing=
this.=C2=A0 I've been wanting to do a complete table of "categori=
es" and APIs in the STL (ie containers, pointers, etc) and point out w=
hat should be consistent, what should be purposely different, etc.=C2=A0 ie=
as you mention, variant/any/optional are not containers, so should not act=
like containers - they are their own category (closer to pointers).<br><br=
></div><div class=3D"gmail_extra">- reset vs clear - I agree, reset should =
be used.<br></div><div class=3D"gmail_extra"><br>- whether variant uses emp=
ty() should depend on whether it is a "fully exposed" state or ju=
st an error state.=C2=A0 As an error state, I think valid/is_valid is bette=
r.=C2=A0 Because in that case it is different than empty.<br><br></div><div=
class=3D"gmail_extra">- operator bool.=C2=A0 See <a href=3D"http://www.ope=
n-std.org/jtc1/sc22/wg21/docs/papers/2013/n3765.pdf">http://www.open-std.or=
g/jtc1/sc22/wg21/docs/papers/2013/n3765.pdf</a> I still wonder if we should=
remove it completely, and use a named function.=C2=A0 But I agree they (at=
least optional and any) should be the same.<br><br></div><div class=3D"gma=
il_extra">- should sum_cast go a step further and just be called try_cast?=
=C2=A0 Use it anywhere we try to convert from A to B that can result in bad=
_cast. (ie dynamic_cast could be a try_cast).=C2=A0 Or does that just lead =
to never ending talks on conversion libraries?<br><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" 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 />
--089e0158c3b2334144051f68faa3--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Fri, 11 Sep 2015 01:55:57 +0200
Raw View
This is a multi-part message in MIME format.
--------------060404080405000005080005
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 10/09/15 20:07, Tony V E a =C3=A9crit :
> On Wed, Sep 9, 2015 at 1:09 PM, Vicente J. Botet Escriba <
> vicente.botet@wanadoo.fr> wrote:
>
>> Hi,
>>
>> This proposal [1] identifies some minor inconveniences in the design of
>> variant<Ts...>, any and optional<T>, diagnoses them as owing to
>> unnecessary asymmetry between those classes, and proposes wording to
>> eliminate the asymmetry.
>>
>> Any help to improve the proposal is welcome.
>>
>> Vicente
>>
>> [1]
>> https://github.com/viboes/std-make/blob/master/doc/proposal/any_optional=
/D0032.pdf
>>
>> --
>>
> For _cast functions, are conversions ever performed?
>
> (the following syntax is probably incorrect, sorry:)
>
> struct Base {};
> struct Derived : Base {};
>
> any a =3D Derived();
> Base base =3D any_cast<Base>(a);
>
> does the stored value get casted to a Base?
Throws:
|bad_any_cast| if |operand.type() !=3D
typeid(remove_reference_t<ValueType>)|.
>
> I don't think variant will cast (ie convert) between similar types:
>
> variant<int, double> v =3D 1.5;
> int one =3D variant_cast<int>(v);
>
> should I expect that to work? Or throw bad_cast?
Good point. I didn't take into account this case. The current variant=20
get<int> throws bad_variant_access.
I believe that a sum type needs to throw in this case, but I recognize=20
that your example is troubling
>
> If/When there is no conversion, I don't like calling it "cast".
>
I understand that seen _cast you could think that a conversion can take=20
place, as _cast is also used when there is a conversion. But _cast is=20
not only used when there is a conversion (dynamic_cast, ...). In the=20
case of any_cast there are no conversions.
I like the _cast suffix, but can live with another name. My concern is=20
more in using the same naming convention when what we do is the same (at=20
least for the new classes).
I've not identified any substantial differences between any_cast and=20
get(variant).
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--------------060404080405000005080005
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 10/09/15 20:07, Tony V E a =C3=A9crit=
=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:CAOHCbiuVmKwqg8635iYW1mPn7M59o1r=3DfKu10BD59JYbjaMOgQ@mail.gmai=
l.com"
type=3D"cite">
<pre wrap=3D"">On Wed, Sep 9, 2015 at 1:09 PM, Vicente J. Botet Escri=
ba <
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:vicente.botet@wanadoo.=
fr">vicente.botet@wanadoo.fr</a>> wrote:
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">Hi,
This proposal [1] identifies some minor inconveniences in the design of
variant<Ts...>, any and optional<T>, diagnoses them as owing to
unnecessary asymmetry between those classes, and proposes wording to
eliminate the asymmetry.
Any help to improve the proposal is welcome.
Vicente
[1]
<a class=3D"moz-txt-link-freetext" href=3D"https://github.com/viboes/std-ma=
ke/blob/master/doc/proposal/any_optional/D0032.pdf">https://github.com/vibo=
es/std-make/blob/master/doc/proposal/any_optional/D0032.pdf</a>
--
</pre>
</blockquote>
<pre wrap=3D"">
For _cast functions, are conversions ever performed?
(the following syntax is probably incorrect, sorry:)
struct Base {};
struct Derived : Base {};
any a =3D Derived();
Base base =3D any_cast<Base>(a);
does the stored value get casted to a Base?</pre>
</blockquote>
<meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8=
">
<cxx-throws para_num=3D"6" id=3D"any.nonmembers.6"> <dt>Throws:</dt>
<dd><code>bad_any_cast</code> if <code>operand.type() !=3D
typeid(remove_reference_t<ValueType>)</code>.</dd>
</cxx-throws>
<blockquote
cite=3D"mid:CAOHCbiuVmKwqg8635iYW1mPn7M59o1r=3DfKu10BD59JYbjaMOgQ@mail.gmai=
l.com"
type=3D"cite">
<pre wrap=3D"">
I don't think variant will cast (ie convert) between similar types:
variant<int, double> v =3D 1.5;
int one =3D variant_cast<int>(v);
should I expect that to work? Or throw bad_cast?</pre>
</blockquote>
Good point. I didn't take into account this case. The current
variant get<int> throws bad_variant_access.<br>
I believe that a sum type needs to throw in this case, but I
recognize that your example is troubling<br>
<br>
<blockquote
cite=3D"mid:CAOHCbiuVmKwqg8635iYW1mPn7M59o1r=3DfKu10BD59JYbjaMOgQ@mail.gmai=
l.com"
type=3D"cite">
<pre wrap=3D"">
If/When there is no conversion, I don't like calling it "cast".
</pre>
</blockquote>
I understand that seen _cast you could think that a conversion can
take place, as _cast is also used when there is a conversion. But
_cast is not only used when there is a conversion (dynamic_cast,
...). In the case of any_cast there are no conversions.<br>
<br>
I like the _cast suffix, but can live with another name. My concern
is more in using the same naming convention when what we do is the
same (at least for the new classes). <br>
I've not identified any substantial differences between any_cast and
get(variant).<br>
<br>
Vicente<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" 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 />
--------------060404080405000005080005--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Fri, 11 Sep 2015 01:58:02 +0200
Raw View
Le 10/09/15 20:26, Tony V E a =C3=A9crit :
> On Thu, Sep 10, 2015 at 2:09 PM, Vicente J. Botet Escriba <
> vicente.botet@wanadoo.fr> wrote:
>
>> Le 10/09/15 19:56, Tony V E a =C3=A9crit :
>>
>>> On Wed, Sep 9, 2015 at 1:09 PM, Vicente J. Botet Escriba <
>>>
>>> https://github.com/viboes/std-make/blob/master/doc/proposal/any_optiona=
l/D0032.pdf
>>>
>>>> --
>>>>
>>>> I would appreciate very clear before/after examples for each change.
>> I believed it was clear enough. I will do if it improves the proposal.
>>
> It would help me :-)
> And I think it makes your point glaringly obvious, instead of me needing =
to
> imagine code.
>
> I think it makes the asymmetries look ugly, and the new symmetry as the
> obvious winner.
> ie I think it would help the committee agree with you. :-)
Granted. I will add it.
>
>
>>> Changes required:
>>> ....
>>>
>>> No changes from the user point of view if you consider that the variant
>> proposal has not been adopted yet.
>>
> By Changes, I mean that is where you would list the technical changes tha=
t
> you are suggesting for each TS.
> Basically, it means putting a motivating example as the first thing for
> each change. Once I see the motivation, you've already sold me on the
> idea. I can then mostly gloss over what needs to change to make it
> possible (as long as it isn't toooo scary).
> Put the best selling point - examples of better looking code - first.
>
I agree I'm not a good seller. I will do my best.
Please contact me personally if you have sometime to help me in this=20
task and coauthor the paper.
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Fri, 11 Sep 2015 09:18:23 +0200
Raw View
This is a multi-part message in MIME format.
--------------000002000308080403040209
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 10/09/15 20:43, Tony V E a =C3=A9crit :
> On Wed, Sep 9, 2015 at 1:09 PM, Vicente J. Botet Escriba <
> vicente.botet@wanadoo.fr> wrote:
>
>>
>> [1]
>> https://github.com/viboes/std-make/blob/master/doc/proposal/any_optional=
/D0032.pdf
>>
>> --
>>
>>
> Also:
>
> - in general, thanks for doing this. I've been wanting to do a complete
> table of "categories" and APIs in the STL (ie containers, pointers, etc)
> and point out what should be consistent, what should be purposely
> different, etc. ie as you mention, variant/any/optional are not
> containers, so should not act like containers - they are their own catego=
ry
> (closer to pointers).
Hmm, I wouldn't say that.
I'm working on proposal for sum types, possibly-valued types=20
(pointer-like or sum types having a not-a-value type), ...
>
> - reset vs clear - I agree, reset should be used.
>
> - whether variant uses empty() should depend on whether it is a "fully
> exposed" state or just an error state. As an error state, I think
> valid/is_valid is better. Because in that case it is different than empt=
y.
Variant is not yet closed. While the last variant proposal uses an empty=20
state as error state, others as eggs::variant or the last post of Matt=20
Calabresse talks of a type that is close to variant but that could be=20
nullable in certain cases. Let me call this variant that can be nullable=20
optionals<Ts...> for the time been.
I need to be more clear in the paper and replace variant<Ts..> by=20
optionals<Ts..> where the nullable variant is used or I should remove=20
variant as a nullable as the last proposal don't see variant as a nullable.
>
> - operator bool. See
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3765.pdf I still
> wonder if we should remove it completely, and use a named function. But =
I
> agree they (at least optional and any) should be the same.
We have the check using different syntax. My current proposal is to use=20
the same name. I have taken explicit operator bool as optional has it=20
and I don't like empty for them. I can live with a named function.=20
Maybe has_value, the negation of empty, is more appropriated. I=20
proposed it as a member for std::future without success.
I will add it to the paper as alternative to explicit operator bool.=20
Wondering if this has_value would also be a customizable non-member=20
function.
>
> - should sum_cast go a step further and just be called try_cast? Use it
> anywhere we try to convert from A to B that can result in bad_cast. (ie
> dynamic_cast could be a try_cast). Or does that just lead to never endin=
g
> talks on conversion libraries?
>
One of the goals of the paper is to know if the committee wants a follow=20
up on Sum types, stating by how to access, how to visit, ...
I would like to have ready for Konaanother proposal "A C++ generic match=20
function for Sum types" [1]
You are going even further. I proposed TBoost.Conversion to Boost long=20
time ago.
U convert<U>(T);
Iit was rejected. The lesson I learned then was that there are no single=20
conversions between two arbitrary types. One user could want a different=20
conversion than another user. As the generic conversion were defined=20
outside the type A and B, this mechanism would promote ODR violations.
We could think in a first instance that a generic sum_cast could have=20
the same problem, but it shouldn't as the definition of the cast would=20
be done once for all in the definition of the sum type. The user would=20
not be able to redefine the sum_cast for a type defined by the standard=20
as we do for begin/end.
Vicente
[1]=20
https://github.com/viboes/tags/blob/master/doc/proposals/match/DXXXX_Match.=
md
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--------------000002000308080403040209
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 10/09/15 20:43, Tony V E a =C3=A9crit=
=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:CAOHCbisci=3D_K3Kez3rkASaO1JMc=3D5bert9Qv0WNp-4fEndd9yg@mail.gm=
ail.com"
type=3D"cite">
<pre wrap=3D"">On Wed, Sep 9, 2015 at 1:09 PM, Vicente J. Botet Escri=
ba <
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:vicente.botet@wanadoo.=
fr">vicente.botet@wanadoo.fr</a>> wrote:
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">
[1]
<a class=3D"moz-txt-link-freetext" href=3D"https://github.com/viboes/std-ma=
ke/blob/master/doc/proposal/any_optional/D0032.pdf">https://github.com/vibo=
es/std-make/blob/master/doc/proposal/any_optional/D0032.pdf</a>
--
</pre>
</blockquote>
<pre wrap=3D"">Also:
- in general, thanks for doing this. I've been wanting to do a complete
table of "categories" and APIs in the STL (ie containers, pointers, etc)
and point out what should be consistent, what should be purposely
different, etc. ie as you mention, variant/any/optional are not
containers, so should not act like containers - they are their own category
(closer to pointers).</pre>
</blockquote>
Hmm, I wouldn't say that.<br>
<br>
I'm working on proposal for sum types, possibly-valued types
(pointer-like or sum types having a not-a-value type),=C2=A0 ...=C2=A0 =
<br>
<br>
<blockquote
cite=3D"mid:CAOHCbisci=3D_K3Kez3rkASaO1JMc=3D5bert9Qv0WNp-4fEndd9yg@mail.gm=
ail.com"
type=3D"cite">
<pre wrap=3D"">
- reset vs clear - I agree, reset should be used.
- whether variant uses empty() should depend on whether it is a "fully
exposed" state or just an error state. As an error state, I think
valid/is_valid is better. Because in that case it is different than empty.=
</pre>
</blockquote>
Variant is not yet closed. While the last variant proposal uses an
empty state as error state, others as eggs::variant or the last post
of Matt Calabresse talks of a type that is close to variant but that
could be nullable in certain cases. Let me call this variant that
can be nullable optionals<Ts...> for the time been.<br>
I need to be more clear in the paper and replace variant<Ts..>
by optionals<Ts..> where the nullable variant is used or I
should remove variant as a nullable as the last proposal don't see
variant as a nullable. <br>
<blockquote
cite=3D"mid:CAOHCbisci=3D_K3Kez3rkASaO1JMc=3D5bert9Qv0WNp-4fEndd9yg@mail.gm=
ail.com"
type=3D"cite">
<pre wrap=3D"">
- operator bool. See
<a class=3D"moz-txt-link-freetext" href=3D"http://www.open-std.org/jtc1/sc2=
2/wg21/docs/papers/2013/n3765.pdf">http://www.open-std.org/jtc1/sc22/wg21/d=
ocs/papers/2013/n3765.pdf</a> I still
wonder if we should remove it completely, and use a named function. But I
agree they (at least optional and any) should be the same.</pre>
</blockquote>
=C2=A0<br>
We have the check using different syntax. My current proposal is to
use the same name. I have taken explicit operator bool as optional
has it and I don't like empty for them.=C2=A0 I can live with a named
function. Maybe has_value, the negation of=C2=A0 empty,=C2=A0 is more
appropriated. I proposed it as a member for std::future without
success.<br>
I will add it to the paper as alternative to explicit operator bool.
Wondering if this has_value would also be a customizable non-member
function.<br>
<blockquote
cite=3D"mid:CAOHCbisci=3D_K3Kez3rkASaO1JMc=3D5bert9Qv0WNp-4fEndd9yg@mail.gm=
ail.com"
type=3D"cite">
<pre wrap=3D"">
- should sum_cast go a step further and just be called try_cast? Use it
anywhere we try to convert from A to B that can result in bad_cast. (ie
dynamic_cast could be a try_cast). Or does that just lead to never ending
talks on conversion libraries?
</pre>
</blockquote>
One of the goals of the paper is to know if the committee wants a
follow up on Sum types, stating by how to access, how to visit, ...<br>
I would like to have ready for Kona<font face=3D"Arial, sans-serif"><fo=
nt
size=3D"4"> another proposal "A C++ generic match function</font></=
font>
for Sum types" [1]<br>
<br>
You are going even further. I proposed TBoost.Conversion to Boost
long time ago. <br>
<br>
<br>
=C2=A0=C2=A0=C2=A0 U convert<U>(T);<br>
<br>
Iit was rejected. The lesson I learned then was that there are no
single conversions between two arbitrary types. One user could want
a different conversion than another user. As the generic conversion
were defined outside the type A and B, this mechanism would promote
ODR violations.<br>
<br>
We could think in a first instance that a generic sum_cast could
have the same problem, but it shouldn't as the definition of the
cast would be done once for all in the definition of the sum type.
The user would not be able to redefine the sum_cast for a type
defined by the standard as we do for begin/end.<br>
<br>
<br>
Vicente<br>
<br>
[1]
<a class=3D"moz-txt-link-freetext" href=3D"https://github.com/viboes/tags/b=
lob/master/doc/proposals/match/DXXXX_Match.md">https://github.com/viboes/ta=
gs/blob/master/doc/proposals/match/DXXXX_Match.md</a><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" 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 />
--------------000002000308080403040209--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Fri, 11 Sep 2015 15:27:22 -0400
Raw View
--089e0158c3b27295ba051f7db482
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thu, Sep 10, 2015 at 7:55 PM, Vicente J. Botet Escriba <
vicente.botet@wanadoo.fr> wrote:
> Le 10/09/15 20:07, Tony V E a =C3=A9crit :
>
> If/When there is no conversion, I don't like calling it "cast".
>
>
> I understand that seen _cast you could think that a conversion can take
> place, as _cast is also used when there is a conversion. But _cast is not
> only used when there is a conversion (dynamic_cast, ...). In the case of
> any_cast there are no conversions.
>
> I like the _cast suffix, but can live with another name. My concern is
> more in using the same naming convention when what we do is the same (at
> least for the new classes).
> I've not identified any substantial differences between any_cast and
> get(variant).
>
Yeah, it leads me to wonder whether "cast" is the right name for any_cast,
even though it now has fairly common use (via boost, etc).
In some sense, they (any_cast, get(variant), etc, along with
reinterpret_cast, dynamic_cast, etc) are all casts - they take some value
or memory and try (in various ways) to make it the type you want, or fail
in some way (throw, null, UB,...).
But it is the 'try' part in variant, any, optional, that feels like not a
cast to me. For them it is Do or do not. There is no try.
Whatever the name, I agree they should all match.
> Vicente
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--089e0158c3b27295ba051f7db482
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, Sep 10, 2015 at 7:55 PM, Vicente J. Botet Escriba <span dir=3D"=
ltr"><<a href=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_blank">vice=
nte.botet@wanadoo.fr</a>></span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>Le 10/09/15 20:07, Tony V E a =C3=A9crit=C2=A0:<br>
</div><span class=3D""></span><span class=3D""><br>
<blockquote type=3D"cite">
<pre>If/When there is no conversion, I don't like calling it &quo=
t;cast".
</pre>
</blockquote></span>
I understand that seen _cast you could think that a conversion can
take place, as _cast is also used when there is a conversion. But
_cast is not only used when there is a conversion (dynamic_cast,
...). In the case of any_cast there are no conversions.<br>
<br>
I like the _cast suffix, but can live with another name. My concern
is more in using the same naming convention when what we do is the
same (at least for the new classes). <br>
I've not identified any substantial differences between any_cast an=
d
get(variant).<span class=3D"HOEnZb"><font color=3D"#888888"><br></font>=
</span></div></blockquote><div><br><br></div><div>Yeah, it leads me to wond=
er whether "cast" is the right name for any_cast, even though it =
now has fairly common use (via boost, etc).<br></div><div>In some sense, th=
ey (any_cast, get(variant), etc, along with reinterpret_cast, dynamic_cast,=
etc) are all casts - they take some value or memory and try (in various wa=
ys) to make it the type you want, or fail in some way (throw, null, UB,...)=
..<br><br></div><div>But it is the 'try' part in variant, any, optio=
nal, that feels like not a cast to me.=C2=A0 For them it is Do or do not. T=
here is no try.<br><br></div><div>Whatever the name, I agree they should al=
l match.<br></div><div><br>=C2=A0</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
bgcolor=3D"#FFFFFF" text=3D"#000000"><span class=3D"HOEnZb"><font color=3D"=
#888888">
Vicente<br>
<br>
</font></span></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" 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" 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 />
--089e0158c3b27295ba051f7db482--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Fri, 11 Sep 2015 15:29:31 -0400
Raw View
--001a11341a3427c016051f7dbc02
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Fri, Sep 11, 2015 at 3:18 AM, Vicente J. Botet Escriba <
vicente.botet@wanadoo.fr> wrote:
> Le 10/09/15 20:43, Tony V E a =C3=A9crit :
>
> On Wed, Sep 9, 2015 at 1:09 PM, Vicente J. Botet Escriba <vicente.botet@w=
anadoo.fr> wrote:
>
>
> [1]https://github.com/viboes/std-make/blob/master/doc/proposal/any_option=
al/D0032.pdf
>
> --
>
>
>
> Also:
>
> - in general, thanks for doing this. I've been wanting to do a complete
> table of "categories" and APIs in the STL (ie containers, pointers, etc)
> and point out what should be consistent, what should be purposely
> different, etc. ie as you mention, variant/any/optional are not
> containers, so should not act like containers - they are their own catego=
ry
> (closer to pointers).
>
> Hmm, I wouldn't say that.
>
> I'm working on proposal for sum types, possibly-valued types (pointer-lik=
e
> or sum types having a not-a-value type), ...
>
> - reset vs clear - I agree, reset should be used.
>
> - whether variant uses empty() should depend on whether it is a "fully
> exposed" state or just an error state. As an error state, I think
> valid/is_valid is better. Because in that case it is different than empt=
y.
>
> Variant is not yet closed. While the last variant proposal uses an empty
> state as error state, others as eggs::variant or the last post of Matt
> Calabresse talks of a type that is close to variant but that could be
> nullable in certain cases. Let me call this variant that can be nullable
> optionals<Ts...> for the time been.
> I need to be more clear in the paper and replace variant<Ts..> by
> optionals<Ts..> where the nullable variant is used or I should remove
> variant as a nullable as the last proposal don't see variant as a nullabl=
e.
>
I would just mention that _if_ variant gets a first class empty state, it
should match optional and any. I wouldn't start talking about optionals<>.
To make it clear, you might want to mention whether you think the current
(Lenexa) variant should match or not (I don't think it should, since it is
currently more error than empty).
> - operator bool. Seehttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2=
013/n3765.pdf I still
> wonder if we should remove it completely, and use a named function. But =
I
> agree they (at least optional and any) should be the same.
>
>
> We have the check using different syntax. My current proposal is to use
> the same name. I have taken explicit operator bool as optional has it and=
I
> don't like empty for them. I can live with a named function. Maybe
> has_value, the negation of empty, is more appropriated. I proposed it a=
s
> a member for std::future without success.
> I will add it to the paper as alternative to explicit operator bool.
> Wondering if this has_value would also be a customizable non-member
> function.
>
I like has_value. I try to avoid "negative" bools, like empty or
"invalid", because you run into double negatives, like if (!invalid).
But the important thing is that they all match.
> - should sum_cast go a step further and just be called try_cast? Use it
> anywhere we try to convert from A to B that can result in bad_cast. (ie
> dynamic_cast could be a try_cast). Or does that just lead to never endin=
g
> talks on conversion libraries?
>
>
> One of the goals of the paper is to know if the committee wants a follow
> up on Sum types, stating by how to access, how to visit, ...
> I would like to have ready for Kona another proposal "A C++ generic match
> function for Sum types" [1]
>
> You are going even further. I proposed TBoost.Conversion to Boost long
> time ago.
>
>
> U convert<U>(T);
>
> Iit was rejected. The lesson I learned then was that there are no single
> conversions between two arbitrary types. One user could want a different
> conversion than another user. As the generic conversion were defined
> outside the type A and B, this mechanism would promote ODR violations.
>
> We could think in a first instance that a generic sum_cast could have the
> same problem, but it shouldn't as the definition of the cast would be don=
e
> once for all in the definition of the sum type. The user would not be abl=
e
> to redefine the sum_cast for a type defined by the standard as we do for
> begin/end.
>
>
> Vicente
>
> [1]
> https://github.com/viboes/tags/blob/master/doc/proposals/match/DXXXX_Matc=
h.md
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a11341a3427c016051f7dbc02
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 Fri, Sep 11, 2015 at 3:18 AM, Vicente J. Botet Escriba <span dir=3D"=
ltr"><<a href=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_blank">vice=
nte.botet@wanadoo.fr</a>></span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>Le 10/09/15 20:43, Tony V E a =C3=A9crit=C2=A0:<br>
</div><span class=3D"">
<blockquote type=3D"cite">
<pre>On Wed, Sep 9, 2015 at 1:09 PM, Vicente J. Botet Escriba <
<a href=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_blank">vicente.botet=
@wanadoo.fr</a>> wrote:
</pre>
<blockquote type=3D"cite">
<pre>[1]
<a href=3D"https://github.com/viboes/std-make/blob/master/doc/proposal/any_=
optional/D0032.pdf" target=3D"_blank">https://github.com/viboes/std-make/bl=
ob/master/doc/proposal/any_optional/D0032.pdf</a>
--
</pre>
</blockquote>
<pre>Also:
- in general, thanks for doing this. I've been wanting to do a complet=
e
table of "categories" and APIs in the STL (ie containers, pointer=
s, etc)
and point out what should be consistent, what should be purposely
different, etc. ie as you mention, variant/any/optional are not
containers, so should not act like containers - they are their own category
(closer to pointers).</pre>
</blockquote></span>
Hmm, I wouldn't say that.<br>
<br>
I'm working on proposal for sum types, possibly-valued types
(pointer-like or sum types having a not-a-value type),=C2=A0 ...=C2=A0 =
<br><span class=3D"">
<br>
<blockquote type=3D"cite">
<pre>- reset vs clear - I agree, reset should be used.
- whether variant uses empty() should depend on whether it is a "fully
exposed" state or just an error state. As an error state, I think
valid/is_valid is better. Because in that case it is different than empty.=
</pre>
</blockquote></span>
Variant is not yet closed. While the last variant proposal uses an
empty state as error state, others as eggs::variant or the last post
of Matt Calabresse talks of a type that is close to variant but that
could be nullable in certain cases. Let me call this variant that
can be nullable optionals<Ts...> for the time been.<br>
I need to be more clear in the paper and replace variant<Ts..>
by optionals<Ts..> where the nullable variant is used or I
should remove variant as a nullable as the last proposal don't see
variant as a nullable. <br></div></blockquote><div><br></div><div>I wou=
ld just mention that _if_ variant gets a first class empty state, it should=
match optional and any.=C2=A0 I wouldn't start talking about optionals=
<>.<br></div><div>To make it clear, you might want to mention whether=
you think the current (Lenexa) variant should match or not (I don't th=
ink it should, since it is currently more error than empty).<br>=C2=A0<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#00000=
0"><span class=3D"">
<blockquote type=3D"cite">
<pre>- operator bool. See
<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3765.pd=
f" target=3D"_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/201=
3/n3765.pdf</a> I still
wonder if we should remove it completely, and use a named function. But I
agree they (at least optional and any) should be the same.</pre>
</blockquote>
=C2=A0<br></span>
We have the check using different syntax. My current proposal is to
use the same name. I have taken explicit operator bool as optional
has it and I don't like empty for them.=C2=A0 I can live with a nam=
ed
function. Maybe has_value, the negation of=C2=A0 empty,=C2=A0 is more
appropriated. I proposed it as a member for std::future without
success.<br>
I will add it to the paper as alternative to explicit operator bool.
Wondering if this has_value would also be a customizable non-member
function.<span class=3D""><br></span></div></blockquote><div><br></div>=
<div>I like has_value.=C2=A0 I try to avoid "negative" bools, lik=
e empty or "invalid", because you run into double negatives, like=
if (!invalid).<br></div><div>But the important thing is that they all matc=
h.<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor=3D"#FFFFF=
F" text=3D"#000000"><span class=3D"">
<blockquote type=3D"cite">
<pre>- should sum_cast go a step further and just be called try_cast?=
Use it
anywhere we try to convert from A to B that can result in bad_cast. (ie
dynamic_cast could be a try_cast). Or does that just lead to never ending
talks on conversion libraries?
</pre>
</blockquote></span>
One of the goals of the paper is to know if the committee wants a
follow up on Sum types, stating by how to access, how to visit, ...<br>
I would like to have ready for Kona<font face=3D"Arial, sans-serif"><fo=
nt size=3D"4"> another proposal "A C++ generic match function</font></=
font>
for Sum types" [1]<br>
<br>
You are going even further. I proposed TBoost.Conversion to Boost
long time ago. <br>
<br>
<br>
=C2=A0=C2=A0=C2=A0 U convert<U>(T);<br>
<br>
Iit was rejected. The lesson I learned then was that there are no
single conversions between two arbitrary types. One user could want
a different conversion than another user. As the generic conversion
were defined outside the type A and B, this mechanism would promote
ODR violations.<br>
<br>
We could think in a first instance that a generic sum_cast could
have the same problem, but it shouldn't as the definition of the
cast would be done once for all in the definition of the sum type.
The user would not be able to redefine the sum_cast for a type
defined by the standard as we do for begin/end.<br>
<br>
<br>
Vicente<br>
<br>
[1]
<a href=3D"https://github.com/viboes/tags/blob/master/doc/proposals/match/D=
XXXX_Match.md" target=3D"_blank">https://github.com/viboes/tags/blob/master=
/doc/proposals/match/DXXXX_Match.md</a><br>
<br>
</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" 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" 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 />
--001a11341a3427c016051f7dbc02--
.