Topic: N4529 [any.nonmembers] Should any_cast<ValueType>(any&)
Author: Kazutoshi Satoda <k_satoda@f2.dion.ne.jp>
Date: Thu, 04 Jun 2015 03:37:59 +0900
Raw View
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4529.html#any.nonmembers
> template<class ValueType>
> ValueType any_cast(const any& operand);
> template<class ValueType>
> ValueType any_cast(any& operand);
> template<class ValueType>
> ValueType any_cast(any&& operand);
>
> Requires:
> is_reference_v<ValueType> is true or is_copy_constructible_v<ValueType>
> is true. Otherwise the program is ill-formed.
> Returns:
> For the first form, *any_cast<add_const_t<remove_reference_t<ValueType>>>(&operand).
> For the second and third forms, *any_cast<remove_reference_t<ValueType>>(&operand).
As shown above, any_cast<ValueType>(any&) is specified to return
ValueType instead of ValueType&, meaning any_cast<string> requires a
copy. To avoid such a copy, users must write any_cast<string&> or
any_cast<const string&>.
But I wonder if it's better to return ValueType& because,
- it avoids unnecessary copy caused by naive codes. (e.g. any_cast<string>)
- is is more consistent with pointer version.
- it is possibly more intuitive. (e.g. https://stackoverflow.com/questions/20380079/)
- it requires a bit less typing (for "const" and "&").
I understand that the third form (any&& version) should return
ValueType. But I wonder if it is OK without move() in the specification.
The only counterarguments I can thought of so far is that it becomes
inconsistent with build-in cast operators that all have result type as
written type. But then, it sounds inconsistent that the pointer version
doesn't require to be written as any_cast<ValueType*>, and
any_cast<const ValueType*> for const any.
Here is the modified version of the example code. It looks acceptable
and possibly better (in simplicity) for me.
any x(5); // x holds int
assert(any_cast<int>(x) == 5); // cast to int&
// and read its value
any_cast<int>(x) = 10; // cast to int&
// and store a value
assert(any_cast<int>(x) == 10);
x = "Meow"; // x holds const char*
assert(strcmp(any_cast<const char*>(x), "Meow") == 0);
any_cast<const char*>(x) = "Harry";
assert(strcmp(any_cast<const char*>(x), "Harry") == 0);
x = string("Meow"); // x holds string
string s, s2("Jane");
s = move(any_cast<string>(x)); // move from any
assert(s == "Meow");
any_cast<string>(x) = move(s2); // move to any
assert(any_cast<string>(x) == "Jane");
string cat("Meow");
const any y(cat); // const y holds string
assert(any_cast<string>(y) == cat);
any_cast<string>(y) = ""; // error; cannot store
// to const string&
What do you think?
--
k_satoda
--
---
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/.
.
Author: David Krauss <potswa@mac.com>
Date: Thu, 04 Jun 2015 08:20:39 +0800
Raw View
--Apple-Mail=_4C2024B3-7E15-4B45-93FE-346A1DF12B0C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9306=E2=80=9304, at 2:37 AM, Kazutoshi Satoda <k_satoda@f2.=
dion.ne.jp> wrote:
>=20
> But I wonder if it's better to return ValueType& because,
> - it avoids unnecessary copy caused by naive codes. (e.g. any_cast<strin=
g>)
> - is is more consistent with pointer version.
> - it is possibly more intuitive. (e.g. https://stackoverflow.com/questio=
ns/20380079/)
> - it requires a bit less typing (for "const" and "&=E2=80=9D).
any_cast works just like static_cast, pointers included. If someone is naiv=
ely leaving all the ampersands out of their static_casts, they=E2=80=99re g=
oing to have bigger issues.
> I understand that the third form (any&& version) should return
> ValueType. But I wonder if it is OK without move() in the specification.
The =E2=80=9CReturns=E2=80=9D part of the spec looks totally broken for rva=
lues. The example never uses the any_cast<t&&>(foo), and it=E2=80=99s poorl=
y written because it moves after casting, whereas best the practice with mo=
ve is to use it in the innermost subexpression possible.
The problem is that move and any_cast are both attempting to encapsulate th=
e same aspects of static_cast. static_cast<t&&>(foo) is already a move, so =
if any_cast works analogously it should convert an lvalue argument to an xv=
alue return. Whereas this is clean in terms of the core language, it=E2=80=
=99s not idiomatic because we don=E2=80=99t want users to actually write mo=
ve like that. The move idiom takes precedence.
Now I think your point may be valid, but for the reason of separation of co=
ncerns. We want people to write move and static_cast to convert value categ=
ory, not any_cast. This applies to conversions to prvalue and xvalue alike.=
Likewise there are other behaviors such as derived-to-base conversions (an=
d vice versa) which any_cast cannot support. But these would also *appear* =
to work with the current syntax.
Without explicit references, it becomes awkward to do an lvalue-to-rvalue c=
onversion. However, we mostly get by without doing that operation at all. I=
t=E2=80=99s only awkward because it=E2=80=99s unfamiliar. It would be writt=
en static_cast< value_t >( any_cast< value_t >( foo ) ). Fact is, glvalue c=
ategory just isn=E2=80=99t that often dangerous, and the more common, canon=
ical solution is to avoid declaring a reference type on whatever would bind=
to.
> x =3D string("Meow"); // x holds string
> string s, s2("Jane");
> s =3D move(any_cast<string>(x)); // move from any
The interface is broken if it doesn=E2=80=99t support s =3D any_cast<=E2=80=
=A6>( move( x ) );.
> What do you think?
Thanks for pointing it out. I=E2=80=99m implementing any_cast over my std::=
function extension implementation soon and this is a major gotcha. Stay tun=
ed!
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_4C2024B3-7E15-4B45-93FE-346A1DF12B0C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9306=
=E2=80=9304, at 2:37 AM, Kazutoshi Satoda <<a href=3D"mailto:k_satoda@f2=
..dion.ne.jp" class=3D"">k_satoda@f2.dion.ne.jp</a>> wrote:</div><br clas=
s=3D"Apple-interchange-newline"><div class=3D"">But I wonder if it's better=
to return ValueType& because,<br class=3D""> - it avoids unneces=
sary copy caused by naive codes. (e.g. any_cast<string>)<br class=3D"=
"> - is is more consistent with pointer version.<br class=3D"">  =
;- it is possibly more intuitive. (e.g. <a href=3D"https://stackoverflow.co=
m/questions/20380079/" class=3D"">https://stackoverflow.com/questions/20380=
079/</a>)<br class=3D""> - it requires a bit less typing (for "const"=
and "&=E2=80=9D).<br class=3D""></div></blockquote><div><br class=3D""=
></div><div><font face=3D"Courier" class=3D"">any_cast</font> works just li=
ke <font face=3D"Courier" class=3D"">static_cast</font>, pointers included.=
If someone is naively leaving all the ampersands out of their <font face=
=3D"Courier" class=3D"">static_cast</font>s, they=E2=80=99re going to have =
bigger issues.</div><div><br class=3D""></div><blockquote type=3D"cite" cla=
ss=3D""><div class=3D"">I understand that the third form (any&& ver=
sion) should return<br class=3D"">ValueType. But I wonder if it is OK witho=
ut move() in the specification.<br class=3D""></div></blockquote><div><br c=
lass=3D""></div><div>The =E2=80=9CReturns=E2=80=9D part of the spec looks t=
otally broken for rvalues. The example never uses the <font face=3D"Courier=
" class=3D"">any_cast<t&&>(foo)</font>, and it=E2=80=99s poor=
ly written because it moves after casting, whereas best the practice with <=
font face=3D"Courier" class=3D"">move</font> is to use it in the innermost =
subexpression possible.</div><div><br class=3D""></div><div>The problem is =
that <font face=3D"Courier" class=3D"">move</font> and <font face=3D"C=
ourier" class=3D"">any_cast</font> are both attempting to encapsulate =
the same aspects of <font face=3D"Courier" class=3D"">static_cast</font>. <=
font face=3D"Courier" class=3D"">static_cast<t&&>(foo)</font>=
is already a <font face=3D"Courier" class=3D"">move</font>, so if <fo=
nt face=3D"Courier" class=3D"">any_cast</font> works analogously it should =
convert an lvalue argument to an xvalue return. Whereas this is clean in te=
rms of the core language, it=E2=80=99s not idiomatic because we don=E2=80=
=99t want users to actually write <font face=3D"Courier" class=3D"">move</f=
ont> like that. The <font face=3D"Courier" class=3D"">move</font> idiom tak=
es precedence.</div><div><br class=3D""></div><div>Now I think your point m=
ay be valid, but for the reason of separation of concerns. We want people t=
o write <font face=3D"Courier" class=3D"">move</font> and <font face=3D"Cou=
rier" class=3D"">static_cast</font> to convert value category, not <font fa=
ce=3D"Courier" class=3D"">any_cast</font>. This applies to conversions to p=
rvalue and xvalue alike. Likewise there are other behaviors such as derived=
-to-base conversions (and vice versa) which <font face=3D"Courier" class=3D=
"">any_cast</font> cannot support. But these would also *<i class=3D"">appe=
ar</i>* to work with the current syntax.</div><div><br class=3D""></div><di=
v>Without explicit references, it becomes awkward to do an lvalue-to-rvalue=
conversion. However, we mostly get by without doing that operation at all.=
It=E2=80=99s only awkward because it=E2=80=99s unfamiliar. It would be wri=
tten <font face=3D"Courier" class=3D"">static_cast< value_t >( any_ca=
st< value_t >( foo ) )</font>. Fact is, glvalue category just isn=E2=
=80=99t that often dangerous, and the more common, canonical solution is to=
avoid declaring a reference type on whatever would bind to.</div><br class=
=3D""><blockquote type=3D"cite" class=3D""><div class=3D""> x =3D stri=
ng("Meow"); &nb=
sp; =
// x holds string<br class=3D""> string s, s2("Jane");<br class=
=3D""> s =3D move(any_cast<string>(x));  =
; // move from any<br =
class=3D""></div></blockquote><div><br class=3D""></div><div>The interface =
is broken if it doesn=E2=80=99t support <font face=3D"Courier" class=3D"">s=
=3D any_cast<=E2=80=A6>( move( x ) );</font>.</div><br class=3D""><b=
lockquote type=3D"cite" class=3D""><div class=3D"">What do you think?<br cl=
ass=3D""></div></blockquote></div><br class=3D""><div class=3D"">Thanks for=
pointing it out. I=E2=80=99m implementing <font face=3D"Courier" class=3D"=
">any_cast</font> over my <font face=3D"Courier" class=3D"">std::function</=
font> extension implementation soon and this is a major gotcha. Stay t=
uned!</div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_4C2024B3-7E15-4B45-93FE-346A1DF12B0C--
.
Author: Kazutoshi Satoda <k_satoda@f2.dion.ne.jp>
Date: Thu, 04 Jun 2015 12:09:30 +0900
Raw View
On 2015/06/04 9:20, David Krauss wrote:
>> On 2015=E2=80=9306=E2=80=9304, at 2:37 AM, Kazutoshi Satoda <k_satoda@f2=
..dion.ne.jp> wrote:
>>=20
>> But I wonder if it's better to return ValueType& because,
>> - it avoids unnecessary copy caused by naive codes. (e.g. any_cast<stri=
ng>)
>> - is is more consistent with pointer version.
>> - it is possibly more intuitive. (e.g. https://stackoverflow.com/questi=
ons/20380079/)
>> - it requires a bit less typing (for "const" and "&=E2=80=9D).
>=20
> any_cast works just like static_cast, pointers included. If someone is na=
ively leaving all the ampersands out of their static_casts, they=E2=80=99re=
going to have bigger issues.
Hmm, "naive" might be a wrong word. I though it "naive" probably because
I personally have seen far more occurrences of pointer version
boost::any_cast<T>(&x) in practice. Reference version is rarely used and
on such rare occurrences, it is very possible that I overlooked an extra
copy involved due to lack of "&".
Let me clarify about current inconsistency with pointer version. Here is
the spec of pointer version from N4529.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4529.html#any.nonm=
embers
> template<class ValueType>
> const ValueType* any_cast(const any* operand) noexcept;
> template<class ValueType>
> ValueType* any_cast(any* operand) noexcept;
>=20
> Returns:
> If operand !=3D nullptr && operand->type() =3D=3D typeid(ValueType), =
a
> pointer to the object contained by operand, otherwise nullptr.
>=20
> [ Example:
> bool is_string(const any& operand) {
> return any_cast<string>(&operand) !=3D nullptr;
> }
> =E2=80=94 end example ]
In contrast to the reference version, pointer version returns pointer
without specifying pointer type, and it also propagate constness of
the pointed-to type from the operand to the result.
Then you can't say "any_cast works just like static_cast, pointers
included." In fact, it works like static_cast only for references.
If your assertion was true (it required to write pointer type and its
constness explicitly), one should write any_cast<const char* const*>(&x)
to get a pointer to possibly contained const char* value. It would be
seen a bit unfriendly to writers and confusing to readers.
I think the consistency of these two versions (overloads) is more
important than the consistency with build-in cast operators. In fact,
it is not necessarily look like a cast operator. For example, a new
overload get<T>(any&), get<T>(any*) seems a possible candidate as we
already have some overloads in std:: for tuple and pair.
--=20
k_satoda
--=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: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 4 Jun 2015 07:56:11 +0300
Raw View
On 4 June 2015 at 06:09, Kazutoshi Satoda <k_satoda@f2.dion.ne.jp> wrote:
> I think the consistency of these two versions (overloads) is more
> important than the consistency with build-in cast operators. In fact,
Such consistency would be incompatible with boost::any.
I find that a bad idea.
--
---
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/.
.
Author: David Krauss <potswa@gmail.com>
Date: Thu, 4 Jun 2015 13:05:21 +0800
Raw View
--Apple-Mail=_4B5FAFB9-35BB-4A93-8746-20864C4E1646
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9306=E2=80=9304, at 12:56 PM, Ville Voutilainen <ville.vout=
ilainen@gmail.com <mailto:ville.voutilainen@gmail.com>> wrote:
>=20
> On 4 June 2015 at 06:09, Kazutoshi Satoda <k_satoda@f2.dion.ne.jp <mailto=
:k_satoda@f2.dion.ne.jp>> wrote:
>> I think the consistency of these two versions (overloads) is more
>> important than the consistency with build-in cast operators. In fact,
>=20
> Such consistency would be incompatible with boost::any.
> I find that a bad idea.
Which is more important: backward compatibility with Boost, or ability to w=
rite good generic code?
However, it=E2=80=99s a false dichotomy. =E2=80=9Cany_cast=E2=80=9D isn=E2=
=80=99t a particularly good name anyway. It doesn=E2=80=99t =E2=80=9Cpick a=
ny cast and do it,=E2=80=9D it=E2=80=99s =E2=80=9Cthe cast associated with =
class any.=E2=80=9D The standard library prefers to overload cast operation=
names like static_pointer_cast and dynamic_pointer_cast.
I think the proposed semantics should be created under the name recover_cas=
t, since it retrieves an object from a type erasure given its exact dynamic=
type. This should be applicable to std::function as well as any.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_4B5FAFB9-35BB-4A93-8746-20864C4E1646
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"><meta http-equiv=3D"Content-Type" content=3D"text/html charset=3D=
utf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: spac=
e; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><div c=
lass=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=
=80=9306=E2=80=9304, at 12:56 PM, Ville Voutilainen <<a href=3D"mailto:v=
ille.voutilainen@gmail.com" class=3D"">ville.voutilainen@gmail.com</a>> =
wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D"">On 4 Ju=
ne 2015 at 06:09, Kazutoshi Satoda <<a href=3D"mailto:k_satoda@f2.dion.n=
e.jp" class=3D"">k_satoda@f2.dion.ne.jp</a>> wrote:<br class=3D""><block=
quote type=3D"cite" class=3D"">I think the consistency of these two version=
s (overloads) is more<br class=3D"">important than the consistency with bui=
ld-in cast operators. In fact,<br class=3D""></blockquote><br class=3D"">Su=
ch consistency would be incompatible with boost::any.<br class=3D"">I find =
that a bad idea.<br class=3D""></div></blockquote><div class=3D""><br class=
=3D""></div><div class=3D"">Which is more important: backward compatibility=
with Boost, or ability to write good generic code?</div><div class=3D""><b=
r class=3D""></div><div class=3D"">However, it=E2=80=99s a false dichotomy.=
=E2=80=9C<font face=3D"Courier" class=3D"">any_cast</font>=E2=80=9D isn=E2=
=80=99t a particularly good name anyway. It doesn=E2=80=99t =E2=80=9Cpick a=
ny cast and do it,=E2=80=9D it=E2=80=99s =E2=80=9Cthe cast associated with =
<font face=3D"Courier" class=3D"">class any</font>.=E2=80=9D The standard l=
ibrary prefers to overload cast operation names like <font face=3D"Courier"=
class=3D"">static_pointer_cast</font> and <font face=3D"Courier" class=3D"=
">dynamic_pointer_cast</font>.</div><div class=3D""><br class=3D""></div><d=
iv class=3D"">I think the proposed semantics should be created under the na=
me <font face=3D"Courier" class=3D"">recover_cast</font>, since it retrieve=
s an object from a type erasure given its exact dynamic type. This should b=
e applicable to <font face=3D"Courier" class=3D"">std::function</font> as w=
ell as <font face=3D"Courier" class=3D"">any</font>.</div></div></body></ht=
ml>
<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 />
--Apple-Mail=_4B5FAFB9-35BB-4A93-8746-20864C4E1646--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 4 Jun 2015 08:10:10 +0300
Raw View
On 4 June 2015 at 08:05, David Krauss <potswa@gmail.com> wrote:
> I think the consistency of these two versions (overloads) is more
> important than the consistency with build-in cast operators. In fact,
>
>
> Such consistency would be incompatible with boost::any.
> I find that a bad idea.
>
> Which is more important: backward compatibility with Boost, or ability to
> write good generic code?
What is an example of this "good generic code" and what change are you
suggesting?
> I think the proposed semantics should be created under the name
> recover_cast, since it retrieves an object from a type erasure given its
> exact dynamic type. This should be applicable to std::function as well as
> any.
So you're suggesting a new cast in addition to any_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/.
.
Author: David Krauss <potswa@mac.com>
Date: Thu, 04 Jun 2015 13:38:10 +0800
Raw View
--Apple-Mail=_878A4432-987E-4261-9389-56FC3F773A7D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9306=E2=80=9304, at 1:10 PM, Ville Voutilainen <ville.vouti=
lainen@gmail.com> wrote:
>=20
> What is an example of this "good generic code" and what change are you
> suggesting?
For instance, given a forwarding reference to an any and its contained type=
, how do you forward the contents? You would need to transplant the deduced=
qualifiers of the reference onto the template argument of any_cast.
On the other hand, recover_cast< std::string >( std::forward< any_type >( a=
ny_value ) ) should do the trick nicely.
any_cast is really an accessor function and it should behave like one. Fund=
amentally, it doesn=E2=80=99t need to ask for the reference qualifiers, so =
it shouldn=E2=80=99t. It already knows from the type of its own parameter.
> So you're suggesting a new cast in addition to any_cast?
Since any_cast becomes redundant (it=E2=80=99s just a recover_cast followed=
by a static_cast), perhaps it should be deprecated. But, there is a lot of=
boost::any code out there that needs to be migrated.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_878A4432-987E-4261-9389-56FC3F773A7D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9306=
=E2=80=9304, at 1:10 PM, Ville Voutilainen <<a href=3D"mailto:ville.vout=
ilainen@gmail.com" class=3D"">ville.voutilainen@gmail.com</a>> wrote:</d=
iv><br class=3D"Apple-interchange-newline"><div class=3D"">What is an examp=
le of this "good generic code" and what change are you<br class=3D"">sugges=
ting?<br class=3D""></div></blockquote><div><br class=3D""></div><div>For i=
nstance, given a forwarding reference to an any and its contained type, how=
do you forward the contents? You would need to transplant the deduced qual=
ifiers of the reference onto the template argument of <font face=3D"Co=
urier" class=3D"">any_cast</font>.</div><div><br class=3D""></div><div>On t=
he other hand, <font face=3D"Courier" class=3D"">recover_cast< std::stri=
ng >( std::forward< any_type >( any_value ) )</font> should do the=
trick nicely.</div><div><br class=3D""></div><div><font face=3D"Courier" c=
lass=3D"">any_cast</font> is really an accessor function and it should beha=
ve like one. Fundamentally, it doesn=E2=80=99t need to ask for the referenc=
e qualifiers, so it shouldn=E2=80=99t. It already knows from the type of it=
s own parameter.</div><br class=3D""><blockquote type=3D"cite" class=3D""><=
div class=3D"">So you're suggesting a new cast in addition to any_cast?<br =
class=3D""></div></blockquote><div><br class=3D""></div>Since <font fa=
ce=3D"Courier" class=3D"">any_cast</font> becomes redundant (it=E2=80=99s j=
ust a <font face=3D"Courier" class=3D"">recover_cast</font> followed by a <=
font face=3D"Courier" class=3D"">static_cast</font>), perhaps it should be =
deprecated. But, there is a lot of <font face=3D"Courier" class=3D"">boost:=
:any</font> code out there that needs to be migrated.</div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_878A4432-987E-4261-9389-56FC3F773A7D--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 3 Jun 2015 22:52:28 -0700 (PDT)
Raw View
------=_Part_2177_2025520179.1433397148334
Content-Type: multipart/alternative;
boundary="----=_Part_2178_397306303.1433397148340"
------=_Part_2178_397306303.1433397148340
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, June 4, 2015 at 1:38:21 AM UTC-4, David Krauss wrote:
>
>
> On 2015=E2=80=9306=E2=80=9304, at 1:10 PM, Ville Voutilainen <ville.vo...=
@gmail.com=20
> <javascript:>> wrote:
>
> What is an example of this "good generic code" and what change are you
> suggesting?
>
>
> For instance, given a forwarding reference to an any and its contained=20
> type, how do you forward the contents?
>
If by "forwarding reference", you mean a `T&&` parameter, where `T` is a=20
deduced template parameter, and the user passes `any` as a `T`... how would=
=20
you know that you got an `any` in the first place?
Ignoring that, as I understand it, the current `any` proposal will do the=
=20
right thing. If the `any` variable is deduced as an lvalue reference to=20
`any`, then calling `any_cast` on it will return a copy of the value. If it=
=20
is deduced as an rvalue reference to `any`, then calling `any_cast` on it=
=20
will return a moved value, leaving the `any` holding a moved-from object.
--=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/.
------=_Part_2178_397306303.1433397148340
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, June 4, 2015 at 1:38:21 AM UTC-4, Dav=
id Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"=
word-wrap:break-word"><br><div><blockquote type=3D"cite"><div>On 2015=E2=80=
=9306=E2=80=9304, at 1:10 PM, Ville Voutilainen <<a href=3D"javascript:"=
target=3D"_blank" gdf-obfuscated-mailto=3D"AfZ1AutjSvAJ" rel=3D"nofollow" =
onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=
=3D'javascript:';return true;">ville.vo...@gmail.com</a>> wrote:</div><b=
r><div>What is an example of this "good generic code" and what change are y=
ou<br>suggesting?<br></div></blockquote><div><br></div><div>For instance, g=
iven a forwarding reference to an any and its contained type, how do you fo=
rward the contents?</div></div></div></blockquote><div><br>If by "forwardin=
g reference", you mean a `T&&` parameter, where `T` is a deduced te=
mplate parameter, and the user passes `any` as a `T`... how would you know =
that you got an `any` in the first place?<br><br>Ignoring that, as I unders=
tand it, the current `any` proposal will do the right thing. If the `any` v=
ariable is deduced as an lvalue reference to `any`, then calling `any_cast`=
on it will return a copy of the value. If it is deduced as an rvalue refer=
ence to `any`, then calling `any_cast` on it will return a moved value, lea=
ving the `any` holding a moved-from object.</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_2178_397306303.1433397148340--
------=_Part_2177_2025520179.1433397148334--
.
Author: David Krauss <potswa@mac.com>
Date: Thu, 04 Jun 2015 14:02:43 +0800
Raw View
--Apple-Mail=_F1888968-B9D9-4CA7-95FC-F61E88C565CC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9306=E2=80=9304, at 1:52 PM, Nicol Bolas <jmckesson@gmail.c=
om> wrote:
>=20
> If by "forwarding reference", you mean a `T&&` parameter, where `T` is a =
deduced template parameter, and the user passes `any` as a `T`... how would=
you know that you got an `any` in the first place?
It might not even be an any. It might be another type erasure class such as=
std::function.
Anyway, you might obtain an expression of unknown value category, but known=
(or at least constrained) type, indirectly from a forwarding iterator by p=
erforming a member access on it: std::forward< type >( value ).erasure_memb=
er. Likewise any other kind of well-behaved accessor preserves value catego=
ry as well as constness.
> Ignoring that, as I understand it, the current `any` proposal will do the=
right thing. If the `any` variable is deduced as an lvalue reference to `a=
ny`, then calling `any_cast` on it will return a copy of the value. If it i=
s deduced as an rvalue reference to `any`, then calling `any_cast` on it wi=
ll return a moved value, leaving the `any` holding a moved-from object.
The proposal (from the recent mailing) quoted in the original post does not=
implement this. It specifies a function signature with rvalue reference re=
turn type, then specifies that it is initialized with an lvalue. It=E2=80=
=99s broken for rvalue reference =E2=80=9CValueType.=E2=80=9D Moreover it i=
gnores the value category of the argument.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_F1888968-B9D9-4CA7-95FC-F61E88C565CC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9306=
=E2=80=9304, at 1:52 PM, Nicol Bolas <<a href=3D"mailto:jmckesson@gmail.=
com" class=3D"">jmckesson@gmail.com</a>> wrote:</div><br class=3D"Apple-=
interchange-newline"><div class=3D""><div dir=3D"ltr" class=3D"">If by "for=
warding reference", you mean a `T&&` parameter, where `T` is a dedu=
ced template parameter, and the user passes `any` as a `T`... how would you=
know that you got an `any` in the first place?</div></div></blockquote><di=
v><br class=3D""></div><div>It might not even be an <font face=3D"Courier" =
class=3D"">any</font>. It might be another type erasure class such as <font=
face=3D"Courier" class=3D"">std::function</font>.</div><div><br class=3D""=
></div><div>Anyway, you might obtain an expression of unknown value categor=
y, but known (or at least constrained) type, indirectly from a forwarding i=
terator by performing a member access on it: <font face=3D"Courier" class=
=3D"">std::forward< type >( value ).erasure_member</font>. Likewise a=
ny other kind of well-behaved accessor preserves value category as well as =
constness.</div><br class=3D""><blockquote type=3D"cite" class=3D""><div cl=
ass=3D""><div dir=3D"ltr" class=3D""><div class=3D"">Ignoring that, as I un=
derstand it, the current `any` proposal will do the right thing. If the `an=
y` variable is deduced as an lvalue reference to `any`, then calling `any_c=
ast` on it will return a copy of the value. If it is deduced as an rvalue r=
eference to `any`, then calling `any_cast` on it will return a moved value,=
leaving the `any` holding a moved-from object.</div></div></div></blockquo=
te><br class=3D""></div><div>The proposal (from the recent mailing) quoted =
in the original post does not implement this. It specifies a function signa=
ture with rvalue reference return type, then specifies that it is initializ=
ed with an lvalue. It=E2=80=99s broken for rvalue reference =E2=80=9C<font =
face=3D"Courier" class=3D"">ValueType</font>.=E2=80=9D Moreover it ignores =
the value category of the argument.</div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_F1888968-B9D9-4CA7-95FC-F61E88C565CC--
.
Author: David Krauss <potswa@mac.com>
Date: Thu, 04 Jun 2015 14:04:53 +0800
Raw View
> On 2015=E2=80=9306=E2=80=9304, at 2:02 PM, David Krauss <potswa@mac.com> =
wrote:
>=20
> Anyway, you might obtain an expression of unknown value category, but kno=
wn (or at least constrained) type, indirectly from a forwarding iterator
Forwarding reference. (Mental short circuit.)
--=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: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 4 Jun 2015 09:09:00 +0300
Raw View
On 4 June 2015 at 09:02, David Krauss <potswa@mac.com> wrote:
> Ignoring that, as I understand it, the current `any` proposal will do the
> right thing. If the `any` variable is deduced as an lvalue reference to
> `any`, then calling `any_cast` on it will return a copy of the value. If =
it
> is deduced as an rvalue reference to `any`, then calling `any_cast` on it
> will return a moved value, leaving the `any` holding a moved-from object.
>
>
> The proposal (from the recent mailing) quoted in the original post does n=
ot
> implement this. It specifies a function signature with rvalue reference
> return type, then specifies that it is initialized with an lvalue. It=E2=
=80=99s
> broken for rvalue reference =E2=80=9CValueType.=E2=80=9D Moreover it igno=
res the value
> category of the argument.
I don't quite follow how
template<class ValueType>
ValueType any_cast(any&& operand);
does any of those things.
--=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: David Krauss <potswa@gmail.com>
Date: Thu, 4 Jun 2015 14:21:28 +0800
Raw View
--Apple-Mail=_A3701FEA-CCE0-4AC5-9BF6-40ED4CDDABC0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9306=E2=80=9304, at 2:09 PM, Ville Voutilainen <ville.vouti=
lainen@gmail.com> wrote:
>=20
> I don't quite follow how
>=20
> template<class ValueType>
> ValueType any_cast(any&& operand);
>=20
> does any of those things.
1. ValueType isn=E2=80=99t really a ValueType, it=E2=80=99s a ValueOrRefere=
nceType.
- If ValueType is not a reference, you get a copy.
- If ValueType is an lvalue reference, you get a reference.
- If ValueType is an rvalue reference, it=E2=80=99s initialized by an lvalu=
e (an indirection operator expression) which is ill-formed.
2. Although there are overloads for different qualifications of the operand=
parameter, it=E2=80=99s only used for a unary & expression. The rvalue ove=
rload is essentially going out of its way to return non-const lvalue access=
to an xvalue operand, which is completely unsafe.
Maybe the Boost implementation does something different and better, but wha=
t=E2=80=99s written in N4480 is clearly wrong.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_A3701FEA-CCE0-4AC5-9BF6-40ED4CDDABC0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9306=
=E2=80=9304, at 2:09 PM, Ville Voutilainen <<a href=3D"mailto:ville.vout=
ilainen@gmail.com" class=3D"">ville.voutilainen@gmail.com</a>> wrote:</d=
iv><br class=3D"Apple-interchange-newline"><div class=3D"">I don't quite fo=
llow how<br class=3D""><br class=3D"">template<class ValueType><br cl=
ass=3D"">ValueType any_cast(any&& operand);<br class=3D""><br class=
=3D"">does any of those things.<br class=3D""></div></blockquote></div><br =
class=3D""><div class=3D"">1. ValueType isn=E2=80=99t really a ValueType, i=
t=E2=80=99s a ValueOrReferenceType.</div><div class=3D""><br class=3D""></d=
iv><div class=3D"">- If ValueType is not a reference, you get a copy.</div>=
<div class=3D"">- If ValueType is an lvalue reference, you get a reference.=
</div><div class=3D"">- If ValueType is an rvalue reference, it=E2=80=99s i=
nitialized by an lvalue (an indirection operator expression) which is ill-f=
ormed.</div><div class=3D""><br class=3D""></div><div class=3D"">2. Althoug=
h there are overloads for different qualifications of the <font face=
=3D"Courier" class=3D"">operand</font> parameter, it=E2=80=99s only used fo=
r a unary & expression. The rvalue overload is essentially going out of=
its way to return non-const lvalue access to an xvalue operand, which is c=
ompletely unsafe.</div><div class=3D""><br class=3D""></div><div class=3D""=
>Maybe the Boost implementation does something different and better, but wh=
at=E2=80=99s written in N4480 is clearly wrong.</div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_A3701FEA-CCE0-4AC5-9BF6-40ED4CDDABC0--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 3 Jun 2015 23:24:46 -0700 (PDT)
Raw View
------=_Part_2202_251398011.1433399086386
Content-Type: multipart/alternative;
boundary="----=_Part_2203_1146037228.1433399086387"
------=_Part_2203_1146037228.1433399086387
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, June 4, 2015 at 2:09:02 AM UTC-4, Ville Voutilainen wrote:
>
> On 4 June 2015 at 09:02, David Krauss <pot...@mac.com <javascript:>>=20
> wrote:=20
> > Ignoring that, as I understand it, the current `any` proposal will do=
=20
> the=20
> > right thing. If the `any` variable is deduced as an lvalue reference to=
=20
> > `any`, then calling `any_cast` on it will return a copy of the value. I=
f=20
> it=20
> > is deduced as an rvalue reference to `any`, then calling `any_cast` on=
=20
> it=20
> > will return a moved value, leaving the `any` holding a moved-from=20
> object.=20
> >=20
> >=20
> > The proposal (from the recent mailing) quoted in the original post does=
=20
> not=20
> > implement this. It specifies a function signature with rvalue reference=
=20
> > return type, then specifies that it is initialized with an lvalue. It=
=E2=80=99s=20
> > broken for rvalue reference =E2=80=9CValueType.=E2=80=9D Moreover it ig=
nores the value=20
> > category of the argument.=20
>
> I don't quite follow how=20
>
> template<class ValueType>=20
> ValueType any_cast(any&& operand);=20
>
> does any of those things.=20
>
I see what he's saying.
N4488=20
<http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4480.html#any.non=
members>=20
says this about the return value of that function:
For the first form, *any_cast<add_const_t<remove_reference_t<ValueType>>>(&
operand). For the second and third forms, *any_cast<remove_reference_t<
ValueType>>(&operand).
Whether `operand` is an lvalue or rvalue-reference, `&operand` is a=20
*pointer*. So it'll use the pointer version of any cast, then dereference=
=20
the pointer, which yields an lvalue-reference.
--=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/.
------=_Part_2203_1146037228.1433399086387
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, June 4, 2015 at 2:09:02 AM UTC-4, Vil=
le Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 4 June=
2015 at 09:02, David Krauss <<a href=3D"javascript:" target=3D"_blank" =
gdf-obfuscated-mailto=3D"jx-rUlpDPkEJ" rel=3D"nofollow" onmousedown=3D"this=
..href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';re=
turn true;">pot...@mac.com</a>> wrote:
<br>> Ignoring that, as I understand it, the current `any` proposal will=
do the
<br>> right thing. If the `any` variable is deduced as an lvalue referen=
ce to
<br>> `any`, then calling `any_cast` on it will return a copy of the val=
ue. If it
<br>> is deduced as an rvalue reference to `any`, then calling `any_cast=
` on it
<br>> will return a moved value, leaving the `any` holding a moved-from =
object.
<br>>
<br>>
<br>> The proposal (from the recent mailing) quoted in the original post=
does not
<br>> implement this. It specifies a function signature with rvalue refe=
rence
<br>> return type, then specifies that it is initialized with an lvalue.=
It=E2=80=99s
<br>> broken for rvalue reference =E2=80=9CValueType.=E2=80=9D Moreover =
it ignores the value
<br>> category of the argument.
<br>
<br>I don't quite follow how
<br>
<br>template<class ValueType>
<br>ValueType any_cast(any&& operand);
<br>
<br>does any of those things.
<br></blockquote><div><br>I see what he's saying.<br><br><a href=3D"http://=
www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4480.html#any.nonmembers"=
>N4488</a> says this about the return value of that function:<br><br><div c=
lass=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-=
color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wra=
p: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><=
span style=3D"color: #606;" class=3D"styled-by-prettify">For</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> the first form</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">,</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;" =
class=3D"styled-by-prettify">any_cast</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify"><</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">add_const_t</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify"><</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">remove_reference_t</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify"><</span><span style=3D"color: #606;" class=3D"=
styled-by-prettify">ValueType</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">>>>(&</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">operand</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">).</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-pre=
ttify">For</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
the second </span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">and</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> thir=
d forms</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">*</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">any_cast</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">remove_reference_t</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=3D"=
color: #606;" class=3D"styled-by-prettify">ValueType</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">>>(&</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">operand</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">).</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br></span></div></code></div><br>Wheth=
er `operand` is an lvalue or rvalue-reference, `&operand` is a <i>point=
er</i>. So it'll use the pointer version of any cast, then dereference the =
pointer, which yields an lvalue-reference.<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 />
------=_Part_2203_1146037228.1433399086387--
------=_Part_2202_251398011.1433399086386--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 4 Jun 2015 09:36:28 +0300
Raw View
On 4 June 2015 at 09:24, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>
> On Thursday, June 4, 2015 at 2:09:02 AM UTC-4, Ville Voutilainen wrote:
>>
>> On 4 June 2015 at 09:02, David Krauss <pot...@mac.com> wrote:
>> > Ignoring that, as I understand it, the current `any` proposal will do
>> > the
>> > right thing. If the `any` variable is deduced as an lvalue reference t=
o
>> > `any`, then calling `any_cast` on it will return a copy of the value. =
If
>> > it
>> > is deduced as an rvalue reference to `any`, then calling `any_cast` on
>> > it
>> > will return a moved value, leaving the `any` holding a moved-from
>> > object.
>> >
>> >
>> > The proposal (from the recent mailing) quoted in the original post doe=
s
>> > not
>> > implement this. It specifies a function signature with rvalue referenc=
e
>> > return type, then specifies that it is initialized with an lvalue. It=
=E2=80=99s
>> > broken for rvalue reference =E2=80=9CValueType.=E2=80=9D Moreover it i=
gnores the value
>> > category of the argument.
>>
>> I don't quite follow how
>>
>> template<class ValueType>
>> ValueType any_cast(any&& operand);
>>
>> does any of those things.
>
>
> I see what he's saying.
>
> N4488 says this about the return value of that function:
>
> For the first form,
> *any_cast<add_const_t<remove_reference_t<ValueType>>>(&operand). For the
> second and third forms, *any_cast<remove_reference_t<ValueType>>(&operand=
).
>
> Whether `operand` is an lvalue or rvalue-reference, `&operand` is a point=
er.
> So it'll use the pointer version of any cast, then dereference the pointe=
r,
> which yields an lvalue-reference.
Ok, I see it now, thanks. any_cast seemingly doesn't support a
ValueType that is an rvalue
reference, and implementations agree. I would like to find out why.
--=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, 3 Jun 2015 23:42:49 -0700 (PDT)
Raw View
------=_Part_12_715027382.1433400170012
Content-Type: multipart/alternative;
boundary="----=_Part_13_146720662.1433400170012"
------=_Part_13_146720662.1433400170012
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, June 4, 2015 at 2:36:30 AM UTC-4, Ville Voutilainen wrote:
>
> On 4 June 2015 at 09:24, Nicol Bolas <jmck...@gmail.com <javascript:>>=20
> wrote:=20
> >=20
> >=20
> > On Thursday, June 4, 2015 at 2:09:02 AM UTC-4, Ville Voutilainen wrote:=
=20
> >>=20
> >> On 4 June 2015 at 09:02, David Krauss <pot...@mac.com> wrote:=20
> >> > Ignoring that, as I understand it, the current `any` proposal will d=
o=20
> >> > the=20
> >> > right thing. If the `any` variable is deduced as an lvalue reference=
=20
> to=20
> >> > `any`, then calling `any_cast` on it will return a copy of the value=
..=20
> If=20
> >> > it=20
> >> > is deduced as an rvalue reference to `any`, then calling `any_cast`=
=20
> on=20
> >> > it=20
> >> > will return a moved value, leaving the `any` holding a moved-from=20
> >> > object.=20
> >> >=20
> >> >=20
> >> > The proposal (from the recent mailing) quoted in the original post=
=20
> does=20
> >> > not=20
> >> > implement this. It specifies a function signature with rvalue=20
> reference=20
> >> > return type, then specifies that it is initialized with an lvalue.=
=20
> It=E2=80=99s=20
> >> > broken for rvalue reference =E2=80=9CValueType.=E2=80=9D Moreover it=
ignores the=20
> value=20
> >> > category of the argument.=20
> >>=20
> >> I don't quite follow how=20
> >>=20
> >> template<class ValueType>=20
> >> ValueType any_cast(any&& operand);=20
> >>=20
> >> does any of those things.=20
> >=20
> >=20
> > I see what he's saying.=20
> >=20
> > N4488 says this about the return value of that function:=20
> >=20
> > For the first form,=20
> > *any_cast<add_const_t<remove_reference_t<ValueType>>>(&operand). For th=
e=20
> > second and third forms,=20
> *any_cast<remove_reference_t<ValueType>>(&operand).=20
> >=20
> > Whether `operand` is an lvalue or rvalue-reference, `&operand` is a=20
> pointer.=20
> > So it'll use the pointer version of any cast, then dereference the=20
> pointer,=20
> > which yields an lvalue-reference.=20
>
>
> Ok, I see it now, thanks. any_cast seemingly doesn't support a=20
> ValueType that is an rvalue=20
> reference, and implementations agree. I would like to find out why.
>
What's really interesting is that the *current* version of boost::any=20
doesn't work this way=20
<http://www.boost.org/doc/libs/1_58_0/doc/html/boost/any_cast_idp32160608.h=
tml>.=20
They actually allow you to get references (presumably both lvalue and=20
rvalue) through any_cast<ValueType&>. So basically, Boost.Any works the way=
=20
the OP wants.
--=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/.
------=_Part_13_146720662.1433400170012
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, June 4, 2015 at 2:36:30 AM UTC-4, Vil=
le Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 4 June=
2015 at 09:24, Nicol Bolas <<a href=3D"javascript:" target=3D"_blank" g=
df-obfuscated-mailto=3D"MYoiMzFOATkJ" rel=3D"nofollow" onmousedown=3D"this.=
href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';ret=
urn true;">jmck...@gmail.com</a>> wrote:
<br>>
<br>>
<br>> On Thursday, June 4, 2015 at 2:09:02 AM UTC-4, Ville Voutilainen w=
rote:
<br>>>
<br>>> On 4 June 2015 at 09:02, David Krauss <<a>pot...@mac.com</a=
>> wrote:
<br>>> > Ignoring that, as I understand it, the current `any` prop=
osal will do
<br>>> > the
<br>>> > right thing. If the `any` variable is deduced as an lvalu=
e reference to
<br>>> > `any`, then calling `any_cast` on it will return a copy o=
f the value. If
<br>>> > it
<br>>> > is deduced as an rvalue reference to `any`, then calling =
`any_cast` on
<br>>> > it
<br>>> > will return a moved value, leaving the `any` holding a mo=
ved-from
<br>>> > object.
<br>>> >
<br>>> >
<br>>> > The proposal (from the recent mailing) quoted in the orig=
inal post does
<br>>> > not
<br>>> > implement this. It specifies a function signature with rv=
alue reference
<br>>> > return type, then specifies that it is initialized with a=
n lvalue. It=E2=80=99s
<br>>> > broken for rvalue reference =E2=80=9CValueType.=E2=80=9D =
Moreover it ignores the value
<br>>> > category of the argument.
<br>>>
<br>>> I don't quite follow how
<br>>>
<br>>> template<class ValueType>
<br>>> ValueType any_cast(any&& operand);
<br>>>
<br>>> does any of those things.
<br>>
<br>>
<br>> I see what he's saying.
<br>>
<br>> N4488 says this about the return value of that function:
<br>>
<br>> For the first form,
<br>> *any_cast<add_const_t<remove_<wbr>reference_t<ValueType&g=
t;>>(&<wbr>operand). For the
<br>> second and third forms, *any_cast<remove_reference_t<<wbr>Va=
lueType>>(&operand).
<br>>
<br>> Whether `operand` is an lvalue or rvalue-reference, `&operand`=
is a pointer.
<br>> So it'll use the pointer version of any cast, then dereference the=
pointer,
<br>> which yields an lvalue-reference.
<br>
<br>
<br>Ok, I see it now, thanks. any_cast seemingly doesn't support a
<br>ValueType that is an rvalue
<br>reference, and implementations agree. I would like to find out why.<br>=
</blockquote><div><br>What's really interesting is that <a href=3D"http://w=
ww.boost.org/doc/libs/1_58_0/doc/html/boost/any_cast_idp32160608.html">the =
<i>current</i> version of boost::any doesn't work this way</a>. They actual=
ly allow you to get references (presumably both lvalue and rvalue) through =
any_cast<ValueType&>. So basically, Boost.Any works the way the O=
P wants.<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 />
------=_Part_13_146720662.1433400170012--
------=_Part_12_715027382.1433400170012--
.
Author: Kazutoshi Satoda <k_satoda@f2.dion.ne.jp>
Date: Fri, 05 Jun 2015 03:34:58 +0900
Raw View
On 2015/06/04 15:42, Nicol Bolas wrote:
> <http://www.boost.org/doc/libs/1_58_0/doc/html/boost/any_cast_idp32160608.html>.
> They actually allow you to get references (presumably both lvalue and
> rvalue) through any_cast<ValueType&>. So basically, Boost.Any works the way
> the OP wants.
I don't like the way boost::any_cast on references works; which is
inconsistent with the pointer version, tends to make extra copies, and
requires explicit qualification to avoid such copies.
I got shocked seeing the recent paper that still had these issues as it
was in boost version. That's why I made the original post. I'm so sorry
for the late arrival.
(The issue on rvalue version was not the main point of my post. I
believe that it is just an error on canonicalization, and the intended
design is that of current boost::any_cast.)
Here are some examples of unnecessary copy with any_cast by searching
the wild (GitHub).
https://github.com/mallardtheduck/cobject-client/blob/0a3cd7e53589e0ec511121501e9398b3ed410a8d/serialize.cpp#L53
https://github.com/volnyja1/RCserver/blob/af68c2179e15a7430f41f6dc3c0f1b8b9562de6c/RemoteControlAPI/RemoteControlAPI/remotecontrol/command.cpp#L122
https://github.com/kvahed/codeare/blob/6061bc8a873f399c324b7f37c68c4c3e2e87325d/src/core/Workspace.cpp#L46
https://github.com/sssooonnnggg/RemoteControl/blob/558a39a94ef6e50dff9ba97c4546a331283b9bb3/ApplicationPathParser.cpp#L37
(via https://github.com/search?utf8=%E2%9C%93&q=any_cast+language%3Ac%2B%2B+-filename%3Aany_cast&type=Code&ref=searchresults
with some more additional "-filename:..."s to narrow down.)
I see four direction so far:
1. Leave the current design.
Just fix the specification of rvalue version.
2. Tweak the reference version to be consistent with the pointer version.
template<ValueType> ValueType& any_cast(any&);
...
This is what I was saying in the original post.
3. Tweak the pointer version to be consistent with built-in cast operators.
template<ValuePtrType> ValuePtrType any_cast(any*);
...
I think this is the worst.
4. Make a new accessor, and deprecate or remove any_cast.
This looks like the best for me now.
But it will take much time, with possible bekeshedding.
(get<T>, recover_cast<T>, ... ?)
I would like to hear what people (especially in LEWG) say about this.
--
k_satoda
--
---
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/.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 4 Jun 2015 12:03:57 -0700 (PDT)
Raw View
------=_Part_19_999052349.1433444637246
Content-Type: multipart/alternative;
boundary="----=_Part_20_2045677397.1433444637246"
------=_Part_20_2045677397.1433444637246
Content-Type: text/plain; charset=UTF-8
On Thursday, June 4, 2015 at 2:35:04 PM UTC-4, Kazutoshi SATODA wrote:
>
> On 2015/06/04 15:42, Nicol Bolas wrote:
> > <
> http://www.boost.org/doc/libs/1_58_0/doc/html/boost/any_cast_idp32160608.html>.
>
> > They actually allow you to get references (presumably both lvalue and
> > rvalue) through any_cast<ValueType&>. So basically, Boost.Any works the
> way
> > the OP wants.
>
> I don't like the way boost::any_cast on references works; which is
> inconsistent with the pointer version, tends to make extra copies, and
> requires explicit qualification to avoid such copies.
>
Well, that's how C++ works. By default, the language copies; if you want a
reference, you have to ask:
auto x = r.y; //Copy
auto &z = r.y; //Reference
Your problem seem to be less with `any_cast` and more with C++'s
copy-by-default nature.
The inconsistency for pointer access (specifying the value type rather than
a pointer-to-the-value-type) is odd, to be sure. But it seems rather late
to go about changing that, what with wanting std::any to be a drop-in
replacement for the Boost version.
It's not significant enough to go changing the API over. Now, it might be
worthwhile to allow pointer-to-the-pointer-type casting, so that if a user
wants to, they can say `any_cast<ValueType*>(&any_value)`. But for
backwards compatibility, they ought to be able to do that.
>
> I got shocked seeing the recent paper that still had these issues as it
> was in boost version. That's why I made the original post. I'm so sorry
> for the late arrival.
>
> (The issue on rvalue version was not the main point of my post. I
> believe that it is just an error on canonicalization, and the intended
> design is that of current boost::any_cast.)
>
> Here are some examples of unnecessary copy with any_cast by searching
> the wild (GitHub).
>
> https://github.com/mallardtheduck/cobject-client/blob/0a3cd7e53589e0ec511121501e9398b3ed410a8d/serialize.cpp#L53
>
> https://github.com/volnyja1/RCserver/blob/af68c2179e15a7430f41f6dc3c0f1b8b9562de6c/RemoteControlAPI/RemoteControlAPI/remotecontrol/command.cpp#L122
>
> https://github.com/kvahed/codeare/blob/6061bc8a873f399c324b7f37c68c4c3e2e87325d/src/core/Workspace.cpp#L46
>
> https://github.com/sssooonnnggg/RemoteControl/blob/558a39a94ef6e50dff9ba97c4546a331283b9bb3/ApplicationPathParser.cpp#L37
> (via
> https://github.com/search?utf8=%E2%9C%93&q=any_cast+language%3Ac%2B%2B+-filename%3Aany_cast&type=Code&ref=searchresults
> with some more additional "-filename:..."s to narrow down.)
>
> I see four direction so far:
>
> 1. Leave the current design.
> Just fix the specification of rvalue version.
>
> 2. Tweak the reference version to be consistent with the pointer
> version.
> template<ValueType> ValueType& any_cast(any&);
> ...
> This is what I was saying in the original post.
>
> 3. Tweak the pointer version to be consistent with built-in cast
> operators.
> template<ValuePtrType> ValuePtrType any_cast(any*);
> ...
> I think this is the worst.
>
> 4. Make a new accessor, and deprecate or remove any_cast.
> This looks like the best for me now.
> But it will take much time, with possible bekeshedding.
> (get<T>, recover_cast<T>, ... ?)
>
> I would like to hear what people (especially in LEWG) say about this.
>
> --
> k_satoda
>
--
---
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_20_2045677397.1433444637246
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, June 4, 2015 at 2:35:04 PM UTC-4, Kaz=
utoshi SATODA wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2015/06=
/04 15:42, Nicol Bolas wrote:
<br>> <<a href=3D"http://www.boost.org/doc/libs/1_58_0/doc/html/boost=
/any_cast_idp32160608.html" target=3D"_blank" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.boost.org%2=
Fdoc%2Flibs%2F1_58_0%2Fdoc%2Fhtml%2Fboost%2Fany_cast_idp32160608.html\46sa\=
75D\46sntz\0751\46usg\75AFQjCNEwdBjxebNOqaj7XCVGZYHC4RgSZQ';return true;" o=
nclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.boost=
..org%2Fdoc%2Flibs%2F1_58_0%2Fdoc%2Fhtml%2Fboost%2Fany_cast_idp32160608.html=
\46sa\75D\46sntz\0751\46usg\75AFQjCNEwdBjxebNOqaj7XCVGZYHC4RgSZQ';return tr=
ue;">http://www.boost.org/doc/<wbr>libs/1_58_0/doc/html/boost/<wbr>any_cast=
_idp32160608.html</a>>.=20
<br>> They actually allow you to get references (presumably both lvalue =
and=20
<br>> rvalue) through any_cast<ValueType&>. So basically, Boos=
t.Any works the way=20
<br>> the OP wants.
<br>
<br>I don't like the way boost::any_cast on references works; which is
<br>inconsistent with the pointer version, tends to make extra copies, and
<br>requires explicit qualification to avoid such copies.<br></blockquote><=
div><br>Well, that's how C++ works. By default, the language copies; if you=
want a reference, you have to ask:<br><br><div class=3D"prettyprint" style=
=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187);=
border-style: solid; border-width: 1px; word-wrap: break-word;"><code clas=
s=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;=
" class=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> x </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> r</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">y</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #800;" class=3D"styled-by-prettify">//Copy</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">&</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">z </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> r<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">y</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" =
class=3D"styled-by-prettify">//Reference</span></div></code></div><br>Your =
problem seem to be less with `any_cast` and more with C++'s copy-by-default=
nature.<br><br>The inconsistency for pointer access (specifying the value =
type rather than a pointer-to-the-value-type) is odd, to be sure. But it se=
ems rather late to go about changing that, what with wanting std::any to be=
a drop-in replacement for the Boost version.<br><br>It's not significant e=
nough to go changing the API over. Now, it might be worthwhile to allow poi=
nter-to-the-pointer-type casting, so that if a user wants to, they can say =
`any_cast<ValueType*>(&any_value)`. But for backwards compatibili=
ty, they ought to be able to do that.<br> </div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;">
<br>I got shocked seeing the recent paper that still had these issues as it
<br>was in boost version. That's why I made the original post. I'm so sorry
<br>for the late arrival.
<br>
<br>(The issue on rvalue version was not the main point of my post. I
<br>believe that it is just an error on canonicalization, and the intended
<br>design is that of current boost::any_cast.)
<br>
<br>Here are some examples of unnecessary copy with any_cast by searching
<br>the wild (GitHub).
<br><a href=3D"https://github.com/mallardtheduck/cobject-client/blob/0a3cd7=
e53589e0ec511121501e9398b3ed410a8d/serialize.cpp#L53" target=3D"_blank" rel=
=3D"nofollow" onmousedown=3D"this.href=3D'https://www.google.com/url?q\75ht=
tps%3A%2F%2Fgithub.com%2Fmallardtheduck%2Fcobject-client%2Fblob%2F0a3cd7e53=
589e0ec511121501e9398b3ed410a8d%2Fserialize.cpp%23L53\46sa\75D\46sntz\0751\=
46usg\75AFQjCNEaTOo4Tvm_Tk3OjUrqkq53mha3rw';return true;" onclick=3D"this.h=
ref=3D'https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fmallardthe=
duck%2Fcobject-client%2Fblob%2F0a3cd7e53589e0ec511121501e9398b3ed410a8d%2Fs=
erialize.cpp%23L53\46sa\75D\46sntz\0751\46usg\75AFQjCNEaTOo4Tvm_Tk3OjUrqkq5=
3mha3rw';return true;">https://github.com/<wbr>mallardtheduck/cobject-clien=
t/<wbr>blob/<wbr>0a3cd7e53589e0ec511121501e9398<wbr>b3ed410a8d/serialize.cp=
p#L53</a>
<br><a href=3D"https://github.com/volnyja1/RCserver/blob/af68c2179e15a7430f=
41f6dc3c0f1b8b9562de6c/RemoteControlAPI/RemoteControlAPI/remotecontrol/comm=
and.cpp#L122" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fvolnyja1%2FRC=
server%2Fblob%2Faf68c2179e15a7430f41f6dc3c0f1b8b9562de6c%2FRemoteControlAPI=
%2FRemoteControlAPI%2Fremotecontrol%2Fcommand.cpp%23L122\46sa\75D\46sntz\07=
51\46usg\75AFQjCNGU_DS2C-p3BRdMMyFt6YN5PwsHFw';return true;" onclick=3D"thi=
s.href=3D'https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fvolnyja=
1%2FRCserver%2Fblob%2Faf68c2179e15a7430f41f6dc3c0f1b8b9562de6c%2FRemoteCont=
rolAPI%2FRemoteControlAPI%2Fremotecontrol%2Fcommand.cpp%23L122\46sa\75D\46s=
ntz\0751\46usg\75AFQjCNGU_DS2C-p3BRdMMyFt6YN5PwsHFw';return true;">https://=
github.com/volnyja1/<wbr>RCserver/blob/<wbr>af68c2179e15a7430f41f6dc3c0f1b<=
wbr>8b9562de6c/RemoteControlAPI/<wbr>RemoteControlAPI/<wbr>remotecontrol/co=
mmand.cpp#L122</a>
<br><a href=3D"https://github.com/kvahed/codeare/blob/6061bc8a873f399c324b7=
f37c68c4c3e2e87325d/src/core/Workspace.cpp#L46" target=3D"_blank" rel=3D"no=
follow" onmousedown=3D"this.href=3D'https://www.google.com/url?q\75https%3A=
%2F%2Fgithub.com%2Fkvahed%2Fcodeare%2Fblob%2F6061bc8a873f399c324b7f37c68c4c=
3e2e87325d%2Fsrc%2Fcore%2FWorkspace.cpp%23L46\46sa\75D\46sntz\0751\46usg\75=
AFQjCNGNzjZzjkwwXSd1lMS7zJ-0nOWNKg';return true;" onclick=3D"this.href=3D'h=
ttps://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fkvahed%2Fcodeare%2=
Fblob%2F6061bc8a873f399c324b7f37c68c4c3e2e87325d%2Fsrc%2Fcore%2FWorkspace.c=
pp%23L46\46sa\75D\46sntz\0751\46usg\75AFQjCNGNzjZzjkwwXSd1lMS7zJ-0nOWNKg';r=
eturn true;">https://github.com/kvahed/<wbr>codeare/blob/<wbr>6061bc8a873f3=
99c324b7f37c68c4c<wbr>3e2e87325d/src/core/Workspace.<wbr>cpp#L46</a>
<br><a href=3D"https://github.com/sssooonnnggg/RemoteControl/blob/558a39a94=
ef6e50dff9ba97c4546a331283b9bb3/ApplicationPathParser.cpp#L37" target=3D"_b=
lank" rel=3D"nofollow" onmousedown=3D"this.href=3D'https://www.google.com/u=
rl?q\75https%3A%2F%2Fgithub.com%2Fsssooonnnggg%2FRemoteControl%2Fblob%2F558=
a39a94ef6e50dff9ba97c4546a331283b9bb3%2FApplicationPathParser.cpp%23L37\46s=
a\75D\46sntz\0751\46usg\75AFQjCNHx0FvDffc2ypTi9S_00b6Ymnznqg';return true;"=
onclick=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%2Fgithu=
b.com%2Fsssooonnnggg%2FRemoteControl%2Fblob%2F558a39a94ef6e50dff9ba97c4546a=
331283b9bb3%2FApplicationPathParser.cpp%23L37\46sa\75D\46sntz\0751\46usg\75=
AFQjCNHx0FvDffc2ypTi9S_00b6Ymnznqg';return true;">https://github.com/<wbr>s=
ssooonnnggg/RemoteControl/<wbr>blob/<wbr>558a39a94ef6e50dff9ba97c4546a3<wbr=
>31283b9bb3/<wbr>ApplicationPathParser.cpp#L37</a>
<br>(via <a href=3D"https://github.com/search?utf8=3D%E2%9C%93&q=3Dany_=
cast+language%3Ac%2B%2B+-filename%3Aany_cast&type=3DCode&ref=3Dsear=
chresults" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'h=
ttps://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fsearch%3Futf8%3D%2=
5E2%259C%2593%26q%3Dany_cast%2Blanguage%253Ac%252B%252B%2B-filename%253Aany=
_cast%26type%3DCode%26ref%3Dsearchresults\46sa\75D\46sntz\0751\46usg\75AFQj=
CNHLDANPd4MtiN8qcIzxGmzx9MeLGA';return true;" onclick=3D"this.href=3D'https=
://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fsearch%3Futf8%3D%25E2%=
259C%2593%26q%3Dany_cast%2Blanguage%253Ac%252B%252B%2B-filename%253Aany_cas=
t%26type%3DCode%26ref%3Dsearchresults\46sa\75D\46sntz\0751\46usg\75AFQjCNHL=
DANPd4MtiN8qcIzxGmzx9MeLGA';return true;">https://github.com/search?<wbr>ut=
f8=3D%E2%9C%93&q=3Dany_cast+<wbr>language%3Ac%2B%2B+-filename%<wbr>3Aan=
y_cast&type=3DCode&ref=3D<wbr>searchresults</a>
<br> with some more additional "-filename:..."s to narrow down.)
<br>
<br>I see four direction so far:
<br>
<br> 1. Leave the current design.
<br> Just fix the specification of rvalue version.
<br>
<br> 2. Tweak the reference version to be consistent with the pointer=
version.
<br> template<ValueType> ValueType& any_cast(=
any&);
<br> ...
<br> This is what I was saying in the original post.
<br>
<br> 3. Tweak the pointer version to be consistent with built-in cast=
operators.
<br> template<ValuePtrType> ValuePtrType any_cast=
(any*);
<br> ...
<br> I think this is the worst.
<br>
<br> 4. Make a new accessor, and deprecate or remove any_cast.
<br> This looks like the best for me now.
<br> But it will take much time, with possible bekeshedding.
<br> (get<T>, recover_cast<T>, ... ?)
<br>
<br>I would like to hear what people (especially in LEWG) say about this.
<br>
<br>--=20
<br>k_satoda
<br></blockquote></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_20_2045677397.1433444637246--
------=_Part_19_999052349.1433444637246--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 4 Jun 2015 22:09:52 +0300
Raw View
On 4 June 2015 at 22:03, Nicol Bolas <jmckesson@gmail.com> wrote:
>> I don't like the way boost::any_cast on references works; which is
>> inconsistent with the pointer version, tends to make extra copies, and
>> requires explicit qualification to avoid such copies.
> Well, that's how C++ works. By default, the language copies; if you want a
> reference, you have to ask:
> auto x = r.y; //Copy
> auto &z = r.y; //Reference
> Your problem seem to be less with `any_cast` and more with C++'s
> copy-by-default nature.
> The inconsistency for pointer access (specifying the value type rather than
> a pointer-to-the-value-type) is odd, to be sure. But it seems rather late to
> go about changing that, what with wanting std::any to be a drop-in
> replacement for the Boost version.
> It's not significant enough to go changing the API over. Now, it might be
> worthwhile to allow pointer-to-the-pointer-type casting, so that if a user
> wants to, they can say `any_cast<ValueType*>(&any_value)`. But for backwards
> compatibility, they ought to be able to do that.
Also, if you want such an API change to happen, you need to write a paper.
For what it's worth, I reported the rvalue-reference target problem
pointed out by
David to LWG. I also mentioned that a strict reading of the
specification of any_cast
means that an implementation cannot move even if the target is a value
instead of
a reference. I haven't turned it into an actual issue submission yet,
but I think I should.
--
---
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/.
.
Author: Kazutoshi Satoda <k_satoda@f2.dion.ne.jp>
Date: Sun, 07 Jun 2015 06:48:56 +0900
Raw View
On 2015/06/05 4:09, Ville Voutilainen wrote:
> Also, if you want such an API change to happen, you need to write a paper.
Here is what I could made so far.
https://github.com/k-satoda/any-accessor-improvement/
I turned down the idea of additional interface because it spoils
grep-ability of any_cast and miss relation (about name) to
bad_any_cast.
https://github.com/k-satoda/any-accessor-improvement/commit/7ab25ab888e6c30d366e367aa59f746f4a7b3444
Just changing return value of lvalue reference versions passed all of
tests on Boost.Any by virtue of reference collapsing.
I'm stuck here as I learned that forwarding cases got priority over
local reference variable cases where returning rvalue reference may
cause dangling references.
https://groups.google.com/a/isocpp.org/d/topic/std-proposals/U26F4A_ai1E/discussion
Under this mind, rvalue version of any_cast may return rvalue reference.
But it clearly opposes the decision of Boost.Any.
I'm now thinking again about additional interface which will work
in forwarding cases...
Suggestions are welcome.
--
k_satoda
--
---
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/.
.