Topic: auto type deduction for *_cast return argument
Author: xavinaar@gmail.com
Date: Tue, 5 Jul 2016 00:47:02 -0700 (PDT)
Raw View
------=_Part_1397_473365688.1467704822121
Content-Type: multipart/alternative;
boundary="----=_Part_1398_1831151153.1467704822121"
------=_Part_1398_1831151153.1467704822121
Content-Type: text/plain; charset=UTF-8
When using* reinterpret_cast,* *dynamic_cast*, *static_cast* and
*const_cast*, you always have to specify type explicitly, yet it almost
always can be deduced from the context.
Consider an example:
void someFunc(Derived *d);
// ...
const Base *cbase = new Base;
const Derived *cderived = dynamic_cast<const Derived *>(cbase);
Derived *derived = const_cast<Derived *>(cderived);
someFunc(derived);
Having knowledge of desired argument type (such as explicitly declared
variable type or function argument type) we can auto-deduce desired return
types. My suggestion is to make type specialization for cast operations
optional in such cases which will result in much cleaner code:
const Base *cbase = new Base;
someFunc(dynamic_cast(const_cast(cbase)));
Furthermore, as soon as *const_cast* is mostly used to cast const
pointers/references to mutable ones (backwards conversion is implicit), I
also suggest to define default behavior of *const_cast* as to return
non-const pointer/reference to argument type, such as:
const Base *cbase = new Base;
auto base = const_cast(cbase); // type of base is "Base"
This rule can also be generalized to any templated function:
template <typename T>
T someFunc();
// ...
int i = someFunc(); // will invoke someFunc<int>();
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/58140e46-2adc-4eac-8f51-72d3685cdf0b%40isocpp.org.
------=_Part_1398_1831151153.1467704822121
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">When using<b> reinterpret_cast,</b> <b>dynamic_cast</b>, <=
b>static_cast</b> and <b>const_cast</b>, you always have to specify type ex=
plicitly, yet it almost always can be deduced from the context.<br><br>Cons=
ider an example:<br><br>=C2=A0=C2=A0=C2=A0 void someFunc(Derived *d);<br><b=
r>=C2=A0=C2=A0=C2=A0 // ...<br><br>=C2=A0=C2=A0=C2=A0 const Base *cbase =3D=
new Base;<br>=C2=A0=C2=A0=C2=A0 const Derived *cderived =3D dynamic_cast&l=
t;const Derived *>(cbase);<br>=C2=A0=C2=A0=C2=A0 Derived *derived =3D co=
nst_cast<Derived *>(cderived);<br>=C2=A0=C2=A0=C2=A0 someFunc(derived=
);<br><br>Having knowledge of desired argument type (such as explicitly dec=
lared variable type or function argument type) we can auto-deduce desired r=
eturn types. My suggestion is to make type specialization for cast operatio=
ns optional in such cases which will result in much cleaner code:<br><br>=
=C2=A0=C2=A0=C2=A0 const Base *cbase =3D new Base;<br>=C2=A0=C2=A0=C2=A0 so=
meFunc(dynamic_cast(const_cast(cbase)));<br><br>Furthermore, as soon as <b>=
const_cast</b> is mostly used to cast const pointers/references to mutable =
ones (backwards conversion is implicit), I also suggest to define default b=
ehavior of <b>const_cast</b> as to return non-const pointer/reference to ar=
gument type, such as:<br><br>=C2=A0=C2=A0=C2=A0 const Base *cbase =3D new B=
ase;<br>=C2=A0=C2=A0=C2=A0 auto base =3D const_cast(cbase); // type of base=
is "Base"<br><br>This rule can also be generalized to any templa=
ted function:<br><br>=C2=A0=C2=A0=C2=A0 template <typename T><br>=C2=
=A0=C2=A0=C2=A0 T someFunc();<br><br>=C2=A0=C2=A0=C2=A0 // ...<br><br>=C2=
=A0=C2=A0=C2=A0 int i =3D someFunc(); // will invoke someFunc<int>();=
<br></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/58140e46-2adc-4eac-8f51-72d3685cdf0b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/58140e46-2adc-4eac-8f51-72d3685cdf0b=
%40isocpp.org</a>.<br />
------=_Part_1398_1831151153.1467704822121--
------=_Part_1397_473365688.1467704822121--
.
Author: Jonathan Coe <jonathanbcoe@gmail.com>
Date: Tue, 5 Jul 2016 08:59:03 +0100
Raw View
--Apple-Mail-F1A4DED3-8A03-4DCE-AA0E-20125957F19A
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Thanks for suggesting this, I'm afraid I don't think I like this idea.
It saves a bit of typing but would make it less clear what's going on and i=
n cases where a function signature changes would change the meaning of exis=
ting code without any edits being made
f(A a);
Changed to
f(B b);
Would change the meaning of=20
f(dynamic_cast(x));
In a rather non-obvious way.
Regards
Jon
> On 5 Jul 2016, at 08:47, xavinaar@gmail.com wrote:
>=20
> When using reinterpret_cast, dynamic_cast, static_cast and const_cast, yo=
u always have to specify type explicitly, yet it almost always can be deduc=
ed from the context.
>=20
> Consider an example:
>=20
> void someFunc(Derived *d);
>=20
> // ...
>=20
> const Base *cbase =3D new Base;
> const Derived *cderived =3D dynamic_cast<const Derived *>(cbase);
> Derived *derived =3D const_cast<Derived *>(cderived);
> someFunc(derived);
>=20
> Having knowledge of desired argument type (such as explicitly declared va=
riable type or function argument type) we can auto-deduce desired return ty=
pes. My suggestion is to make type specialization for cast operations optio=
nal in such cases which will result in much cleaner code:
>=20
> const Base *cbase =3D new Base;
> someFunc(dynamic_cast(const_cast(cbase)));
>=20
> Furthermore, as soon as const_cast is mostly used to cast const pointers/=
references to mutable ones (backwards conversion is implicit), I also sugge=
st to define default behavior of const_cast as to return non-const pointer/=
reference to argument type, such as:
>=20
> const Base *cbase =3D new Base;
> auto base =3D const_cast(cbase); // type of base is "Base"
>=20
> This rule can also be generalized to any templated function:
>=20
> template <typename T>
> T someFunc();
>=20
> // ...
>=20
> int i =3D someFunc(); // will invoke someFunc<int>();
> --=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=
email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/isoc=
pp.org/d/msgid/std-proposals/58140e46-2adc-4eac-8f51-72d3685cdf0b%40isocpp.=
org.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/7E3409C2-A2AC-4562-BB06-6D5D5ACE8AC8%40gmail.com=
..
--Apple-Mail-F1A4DED3-8A03-4DCE-AA0E-20125957F19A
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dutf-8"></head><body dir=3D"auto"><div></div><div>Thanks for suggesting t=
his, I'm afraid I don't think I like this idea.</div><div><br></div><div>It=
saves a bit of typing but would make it less clear what's going on and in =
cases where a function signature changes would change the meaning of existi=
ng code without any edits being made</div><div><br></div><div>f(A a);</div>=
<div><br></div><div>Changed to</div><div><br></div><div>f(B b);</div><div><=
br></div><div>Would change the meaning of </div><div><br></div><div>f(=
dynamic_cast(x));</div><div><br></div><div>In a rather non-obvious way.</di=
v><div><br></div><div>Regards</div><div><br></div><div>Jon</div><div><br>On=
5 Jul 2016, at 08:47, <a href=3D"mailto:xavinaar@gmail.com">xavinaar@gmail=
..com</a> wrote:<br><br></div><blockquote type=3D"cite"><div><div dir=3D"ltr=
">When using<b> reinterpret_cast,</b> <b>dynamic_cast</b>, <b>static_cast</=
b> and <b>const_cast</b>, you always have to specify type explicitly, yet i=
t almost always can be deduced from the context.<br><br>Consider an example=
:<br><br> void someFunc(Derived *d);<br><br> &=
nbsp; // ...<br><br> const Base *cbase =3D new Base;<br>&=
nbsp; const Derived *cderived =3D dynamic_cast<const Derived=
*>(cbase);<br> Derived *derived =3D const_cast<Der=
ived *>(cderived);<br> someFunc(derived);<br><br>Havin=
g knowledge of desired argument type (such as explicitly declared variable =
type or function argument type) we can auto-deduce desired return types. My=
suggestion is to make type specialization for cast operations optional in =
such cases which will result in much cleaner code:<br><br>  =
; const Base *cbase =3D new Base;<br> someFunc(dynamic_ca=
st(const_cast(cbase)));<br><br>Furthermore, as soon as <b>const_cast</b> is=
mostly used to cast const pointers/references to mutable ones (backwards c=
onversion is implicit), I also suggest to define default behavior of <b>con=
st_cast</b> as to return non-const pointer/reference to argument type, such=
as:<br><br> const Base *cbase =3D new Base;<br> &nb=
sp; auto base =3D const_cast(cbase); // type of base is "Base"<br><br=
>This rule can also be generalized to any templated function:<br><br> =
template <typename T><br> T someFunc()=
;<br><br> // ...<br><br> int i =3D some=
Func(); // will invoke someFunc<int>();<br></div>
<p></p>
-- <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 e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/58140e46-2adc-4eac-8f51-72d3685cdf0b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/58140e46-2adc-4eac-8f51-72d3685c=
df0b%40isocpp.org</a>.<br>
</div></blockquote></body></html>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7E3409C2-A2AC-4562-BB06-6D5D5ACE8AC8%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7E3409C2-A2AC-4562-BB06-6D5D5ACE8AC8%=
40gmail.com</a>.<br />
--Apple-Mail-F1A4DED3-8A03-4DCE-AA0E-20125957F19A--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 5 Jul 2016 11:08:37 +0300
Raw View
On 5 July 2016 at 10:59, Jonathan Coe <jonathanbcoe@gmail.com> wrote:
> Thanks for suggesting this, I'm afraid I don't think I like this idea.
>
> It saves a bit of typing but would make it less clear what's going on and in
> cases where a function signature changes would change the meaning of
> existing code without any edits being made
>
> f(A a);
>
> Changed to
>
> f(B b);
>
> Would change the meaning of
>
> f(dynamic_cast(x));
>
> In a rather non-obvious way.
I don't think the behaviour of existing casts should be changed, but
presumably, with template argument deduction for
constructors, we can define new wrapper types that take the wrapped
type as an argument of a constructor template
and have a conversion operator template that does the right kind of
cast before returning the result. Then we can
do something like
f(auto_dyn_cast(x));
There are of course cases where the target type can't be deduced from
the context, like when used in an init-capture
of a lambda, or with an auto-typed variable declaration, or in a
deduced template argument.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUaaP4XC9H7d9e1GBDi8JA4F2dSf2i%3DqB7mqRUXj1Lui5Q%40mail.gmail.com.
.
Author: xavinaar@gmail.com
Date: Tue, 5 Jul 2016 01:18:44 -0700 (PDT)
Raw View
------=_Part_103_462831137.1467706724557
Content-Type: multipart/alternative;
boundary="----=_Part_104_1575461357.1467706724557"
------=_Part_104_1575461357.1467706724557
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On countrary: passing *dynamic_cast* to function always means you want to=
=20
cast to function argument type.
=D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 5 =D0=B8=D1=8E=D0=BB=D1=8F 2016=
=D0=B3., 14:59:06 UTC+7 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=
=D1=82=D0=B5=D0=BB=D1=8C Jonathan Coe =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=
=D0=BB:
>
> Thanks for suggesting this, I'm afraid I don't think I like this idea.
>
> It saves a bit of typing but would make it less clear what's going on and=
=20
> in cases where a function signature changes would change the meaning of=
=20
> existing code without any edits being made
>
> f(A a);
>
> Changed to
>
> f(B b);
>
> Would change the meaning of=20
>
> f(dynamic_cast(x));
>
> In a rather non-obvious way.
>
> Regards
>
> Jon
>
>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/00caca39-d36a-475c-840f-79759e99265d%40isocpp.or=
g.
------=_Part_104_1575461357.1467706724557
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On countrary: passing <b>dynamic_cast</b> to function alwa=
ys means you want to cast to function argument type.<br><br>=D0=B2=D1=82=D0=
=BE=D1=80=D0=BD=D0=B8=D0=BA, 5 =D0=B8=D1=8E=D0=BB=D1=8F 2016 =D0=B3., 14:59=
:06 UTC+7 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=
=BB=D1=8C Jonathan Coe =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:<blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
1px #ccc solid;padding-left: 1ex;"><div dir=3D"auto"><div></div><div>Thank=
s for suggesting this, I'm afraid I don't think I like this idea.</=
div><div><br></div><div>It saves a bit of typing but would make it less cle=
ar what's going on and in cases where a function signature changes woul=
d change the meaning of existing code without any edits being made</div><di=
v><br></div><div>f(A a);</div><div><br></div><div>Changed to</div><div><br>=
</div><div>f(B b);</div><div><br></div><div>Would change the meaning of=C2=
=A0</div><div><br></div><div>f(dynamic_cast(x));</div><div><br></div><div>I=
n a rather non-obvious way.</div><div><br></div><div>Regards</div><div><br>=
</div><div>Jon<br><br></div></div></blockquote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/00caca39-d36a-475c-840f-79759e99265d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/00caca39-d36a-475c-840f-79759e99265d=
%40isocpp.org</a>.<br />
------=_Part_104_1575461357.1467706724557--
------=_Part_103_462831137.1467706724557--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 5 Jul 2016 08:07:31 -0700 (PDT)
Raw View
------=_Part_367_161175421.1467731251596
Content-Type: multipart/alternative;
boundary="----=_Part_368_848721670.1467731251596"
------=_Part_368_848721670.1467731251596
Content-Type: text/plain; charset=UTF-8
On Tuesday, July 5, 2016 at 4:18:44 AM UTC-4, xavi...@gmail.com wrote:
>
> On countrary: passing *dynamic_cast* to function always means you want to
> cast to function argument type.
>
*Which* function's argument type? By foisting deduction on the function,
you basically make overloading impossible for that particular argument.
Additionally, you've forgotten something very important about
`dynamic_cast`: *it can fail*.
If `f` takes a pointer, does it expect to get a nullptr for that parameter?
If `f` takes a reference, does the code calling `f` expect to get a
`std::bad_cast` exception? Will throwing such an exception break other
expressions being evaluated to call `f`?
Indeed, this is a good reason to *not* make such casts easier to type. If
you're using casts so frequently that you need a language change to avoid
lots of repetition, then I'd say that your code is doing something wrong.
Explicit casting should be sufficiently exceptional in your codebase that
if it takes a few extra keystrokes, you can live with it.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4ac3803f-a87d-4551-947f-43f106bdda20%40isocpp.org.
------=_Part_368_848721670.1467731251596
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, July 5, 2016 at 4:18:44 AM UTC-4, xavi...@gmai=
l.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">O=
n countrary: passing <b>dynamic_cast</b> to function always means you want =
to cast to function argument type.<br></div></blockquote><div><br><i>Which<=
/i> function's argument type? By foisting deduction on the function, yo=
u basically make overloading impossible for that particular argument.<br><b=
r>Additionally, you've forgotten something very important about `dynami=
c_cast`: <i>it can fail</i>.<br><br>If `f` takes a pointer, does it expect =
to get a nullptr for that parameter? If `f` takes a reference, does the cod=
e calling `f` expect to get a `std::bad_cast` exception? Will throwing such=
an exception break other expressions being evaluated to call `f`?<br><br>I=
ndeed, this is a good reason to <i>not</i> make such casts easier to type. =
If you're using casts so frequently that you need a language change to =
avoid lots of repetition, then I'd say that your code is doing somethin=
g wrong.<br><br>Explicit casting should be sufficiently exceptional in your=
codebase that if it takes a few extra keystrokes, you can live with it.<br=
></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4ac3803f-a87d-4551-947f-43f106bdda20%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4ac3803f-a87d-4551-947f-43f106bdda20=
%40isocpp.org</a>.<br />
------=_Part_368_848721670.1467731251596--
------=_Part_367_161175421.1467731251596--
.
Author: "'Johannes Schaub' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Tue, 5 Jul 2016 17:18:12 +0200
Raw View
--94eb2c05ce5e45ef750536e4f631
Content-Type: text/plain; charset=UTF-8
It is not obvious that the type of the target is chosen, of you omit the
type. Another choice is that no conversion at all is done (the type is the
operand type) which is also sensible.
Therefore i do not like this change, it is ambiguous.
Am 05.07.2016 09:47 schrieb <xavinaar@gmail.com>:
>
> When using reinterpret_cast, dynamic_cast, static_cast and const_cast,
you always have to specify type explicitly, yet it almost always can be
deduced from the context.
>
> Consider an example:
>
> void someFunc(Derived *d);
>
> // ...
>
> const Base *cbase = new Base;
> const Derived *cderived = dynamic_cast<const Derived *>(cbase);
> Derived *derived = const_cast<Derived *>(cderived);
> someFunc(derived);
>
> Having knowledge of desired argument type (such as explicitly declared
variable type or function argument type) we can auto-deduce desired return
types. My suggestion is to make type specialization for cast operations
optional in such cases which will result in much cleaner code:
>
> const Base *cbase = new Base;
> someFunc(dynamic_cast(const_cast(cbase)));
>
> Furthermore, as soon as const_cast is mostly used to cast const
pointers/references to mutable ones (backwards conversion is implicit), I
also suggest to define default behavior of const_cast as to return
non-const pointer/reference to argument type, such as:
>
> const Base *cbase = new Base;
> auto base = const_cast(cbase); // type of base is "Base"
>
> This rule can also be generalized to any templated function:
>
> template <typename T>
> T someFunc();
>
> // ...
>
> int i = someFunc(); // will invoke someFunc<int>();
>
> --
> You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/58140e46-2adc-4eac-8f51-72d3685cdf0b%40isocpp.org
..
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANu6V4UKX2sUOv%2Bb_H8M4oegpG2OYL6rY13mkvG8qOKdzO6_ZQ%40mail.gmail.com.
--94eb2c05ce5e45ef750536e4f631
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">It is not obvious that the type of the target is chosen, of =
you omit the type. Another choice is that no conversion at all is done (the=
type is the operand type) which is also sensible.</p>
<p dir=3D"ltr">Therefore i do not like this change, it is ambiguous.</p>
<p dir=3D"ltr">Am 05.07.2016 09:47 schrieb <<a href=3D"mailto:xavinaar@g=
mail.com">xavinaar@gmail.com</a>>:<br>
><br>
> When using reinterpret_cast, dynamic_cast, static_cast and const_cast,=
you always have to specify type explicitly, yet it almost always can be de=
duced from the context.<br>
><br>
> Consider an example:<br>
><br>
> =C2=A0=C2=A0=C2=A0 void someFunc(Derived *d);<br>
><br>
> =C2=A0=C2=A0=C2=A0 // ...<br>
><br>
> =C2=A0=C2=A0=C2=A0 const Base *cbase =3D new Base;<br>
> =C2=A0=C2=A0=C2=A0 const Derived *cderived =3D dynamic_cast<const D=
erived *>(cbase);<br>
> =C2=A0=C2=A0=C2=A0 Derived *derived =3D const_cast<Derived *>(cd=
erived);<br>
> =C2=A0=C2=A0=C2=A0 someFunc(derived);<br>
><br>
> Having knowledge of desired argument type (such as explicitly declared=
variable type or function argument type) we can auto-deduce desired return=
types. My suggestion is to make type specialization for cast operations op=
tional in such cases which will result in much cleaner code:<br>
><br>
> =C2=A0=C2=A0=C2=A0 const Base *cbase =3D new Base;<br>
> =C2=A0=C2=A0=C2=A0 someFunc(dynamic_cast(const_cast(cbase)));<br>
><br>
> Furthermore, as soon as const_cast is mostly used to cast const pointe=
rs/references to mutable ones (backwards conversion is implicit), I also su=
ggest to define default behavior of const_cast as to return non-const point=
er/reference to argument type, such as:<br>
><br>
> =C2=A0=C2=A0=C2=A0 const Base *cbase =3D new Base;<br>
> =C2=A0=C2=A0=C2=A0 auto base =3D const_cast(cbase); // type of base is=
"Base"<br>
><br>
> This rule can also be generalized to any templated function:<br>
><br>
> =C2=A0=C2=A0=C2=A0 template <typename T><br>
> =C2=A0=C2=A0=C2=A0 T someFunc();<br>
><br>
> =C2=A0=C2=A0=C2=A0 // ...<br>
><br>
> =C2=A0=C2=A0=C2=A0 int i =3D someFunc(); // will invoke someFunc<in=
t>();<br>
><br>
> -- <br>
> You received this message because you are subscribed to the Google Gro=
ups "ISO C++ Standard - Future Proposals" group.<br>
> To unsubscribe from this group and stop receiving emails from it, send=
an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
> To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
> To view this discussion on the web visit <a href=3D"https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/58140e46-2adc-4eac-8f51-72d3685c=
df0b%40isocpp.org">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/58140e46-2adc-4eac-8f51-72d3685cdf0b%40isocpp.org</a>.<br>
</p>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANu6V4UKX2sUOv%2Bb_H8M4oegpG2OYL6rY1=
3mkvG8qOKdzO6_ZQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANu6V4UKX2sUOv=
%2Bb_H8M4oegpG2OYL6rY13mkvG8qOKdzO6_ZQ%40mail.gmail.com</a>.<br />
--94eb2c05ce5e45ef750536e4f631--
.
Author: Jim Porter <jvp4846@g.rit.edu>
Date: Tue, 5 Jul 2016 10:57:56 -0500
Raw View
On 7/5/2016 10:07 AM, Nicol Bolas wrote:
> Indeed, this is a good reason to /not/ make such casts easier to type.
> If you're using casts so frequently that you need a language change to
> avoid lots of repetition, then I'd say that your code is doing something
> wrong.
Agreed. I seem to recall a (possibly apocryphal) explanation that the
C++ cast functions were verbose *because* they should be avoided unless
absolutely necessary; the verbosity thus serves as a warning to the
developer to rethink things.
- Jim
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/nlgled%24jdo%241%40ger.gmane.org.
.
Author: Jonathan Coe <jonathanbcoe@gmail.com>
Date: Tue, 5 Jul 2016 17:12:02 +0100
Raw View
> On 5 Jul 2016, at 16:57, Jim Porter <jvp4846@g.rit.edu> wrote:
>
>> On 7/5/2016 10:07 AM, Nicol Bolas wrote:
>> Indeed, this is a good reason to /not/ make such casts easier to type.
>> If you're using casts so frequently that you need a language change to
>> avoid lots of repetition, then I'd say that your code is doing something
>> wrong.
>
> Agreed. I seem to recall a (possibly apocryphal) explanation that the C++ cast functions were verbose *because* they should be avoided unless absolutely necessary; the verbosity thus serves as a warning to the developer to rethink things.
>
static_cast is an occasional exception to this rule as it can trigger user-defined conversions. Always seems a bit awkward to me.
> - Jim
>
>
> --
> You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/nlgled%24jdo%241%40ger.gmane.org.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/EBAA14C1-2C3A-4078-8A49-B3CA1D6A17DC%40gmail.com.
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Tue, 12 Jul 2016 09:24:30 -0700 (PDT)
Raw View
------=_Part_273_1952398638.1468340670505
Content-Type: multipart/alternative;
boundary="----=_Part_274_15922509.1468340670506"
------=_Part_274_15922509.1468340670506
Content-Type: text/plain; charset=UTF-8
I also wanted this for const_cast as it can deduce what to cast to from the
_argument_ and does not have to look at the possible uses of the returned
value as the other casts would have to, creating a lot of awkward special
rules. This is for instance useful when const_cast is used to avoid
duplicating methods that do the same in a const and non-const version, such
as a container operator[]. In particular with complicated template type
names it can becomde rather boring, as in this example from the other day:
return const_cast<matrix_view_base<T, Ss...>&>(*this)(ixes...);
But this can be implemented as a library function, which solves most of the
problem:
template<typename T> T* ConstCast(const T* src) { return const_cast<T*>(src
); }
template<typename T> T& ConstCast(const T& src) { return const_cast<T&>(src
); }
So unless someone sees a need to standardize this function I would argue
that this can be solved as needed in specific code bases.
Den tisdag 5 juli 2016 kl. 18:12:06 UTC+2 skrev Jonathan Coe:
>
>
>
> > On 5 Jul 2016, at 16:57, Jim Porter <jvp...@g.rit.edu <javascript:>>
> wrote:
> >
> >> On 7/5/2016 10:07 AM, Nicol Bolas wrote:
> >> Indeed, this is a good reason to /not/ make such casts easier to type.
> >> If you're using casts so frequently that you need a language change to
> >> avoid lots of repetition, then I'd say that your code is doing
> something
> >> wrong.
> >
> > Agreed. I seem to recall a (possibly apocryphal) explanation that the
> C++ cast functions were verbose *because* they should be avoided unless
> absolutely necessary; the verbosity thus serves as a warning to the
> developer to rethink things.
> >
>
> static_cast is an occasional exception to this rule as it can trigger
> user-defined conversions. Always seems a bit awkward to me.
>
> > - Jim
> >
> >
> > --
> > 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-proposal...@isocpp.org <javascript:>.
> > To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>
> > To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/nlgled%24jdo%241%40ger.gmane.org.
>
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/fe93ce3f-5a6a-46dd-808e-d10ec60fb111%40isocpp.org.
------=_Part_274_15922509.1468340670506
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I also wanted this for const_cast as it can deduce what to=
cast to from the _argument_ and does not have to look at the possible uses=
of the returned value as the other casts would have to, creating a lot of =
awkward special rules. This is for instance useful when const_cast is used =
to avoid duplicating methods that do the same in a const and non-const vers=
ion, such as a container operator[]. In particular with complicated templat=
e type names it can becomde rather boring, as in this example from the othe=
r day:<div><br></div><div><div class=3D"prettyprint" style=3D"border: 1px s=
olid rgb(187, 187, 187); word-wrap: break-word; background-color: rgb(250, =
250, 250);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span=
style=3D"color: #000;" class=3D"styled-by-prettify">=C2=A0</span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">return</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">const_cast</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify"><</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">matrix_view_base</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify"><</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-pret=
tify">Ss</span><span style=3D"color: #660;" class=3D"styled-by-prettify">..=
..>&>(*</span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">this</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
)(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">ixes</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">...);</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span></di=
v></code></div><div><br><br></div><div>But this can be implemented as a lib=
rary function, which solves most of the problem:</div><div><br></div><div c=
lass=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); word-wr=
ap: break-word; background-color: rgb(250, 250, 250);"><code class=3D"prett=
yprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D=
"styled-by-prettify">template</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify"><</span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">typename</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> T</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">></span><span style=3D"color: #000;" class=3D"styled-by-prettify"> T<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">ConstCast</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">const</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">*</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> src</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: #660;" class=3D"styled-by-prettify">{</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">return</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">const_cast</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify"><</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">*>(</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">src</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">template</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">typename</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">></span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">&</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by=
-prettify">ConstCast</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>const</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> T</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">&</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> src</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: #6=
60;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">return</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">const_cast</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y"><</span><span style=3D"color: #000;" class=3D"styled-by-prettify">T</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">&>(</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">src</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"><br><br></span></div></code></div><div><br>So=
unless someone sees a need to standardize this function I would argue that=
this can be solved as needed in specific code bases.</div><div><br></div><=
br>Den tisdag 5 juli 2016 kl. 18:12:06 UTC+2 skrev Jonathan Coe:<blockquote=
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;">
<br>
<br>> On 5 Jul 2016, at 16:57, Jim Porter <<a href=3D"javascript:" ta=
rget=3D"_blank" gdf-obfuscated-mailto=3D"HeUzokGLCAAJ" rel=3D"nofollow" onm=
ousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this=
..href=3D'javascript:';return true;">jvp...@g.rit.edu</a>> wrote:
<br>>=20
<br>>> On 7/5/2016 10:07 AM, Nicol Bolas wrote:
<br>>> Indeed, this is a good reason to /not/ make such casts easier =
to type.
<br>>> If you're using casts so frequently that you need a langua=
ge change to
<br>>> avoid lots of repetition, then I'd say that your code is d=
oing something
<br>>> wrong.
<br>>=20
<br>> Agreed. I seem to recall a (possibly apocryphal) explanation that =
the C++ cast functions were verbose *because* they should be avoided unless=
absolutely necessary; the verbosity thus serves as a warning to the develo=
per to rethink things.
<br>>=20
<br>
<br>static_cast is an occasional exception to this rule as it can trigger u=
ser-defined conversions. Always seems a bit awkward to me.
<br>
<br>> - Jim
<br>>=20
<br>>=20
<br>> --=20
<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=3D"javascript:" target=3D"_blank" gdf-obfuscated-m=
ailto=3D"HeUzokGLCAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'jav=
ascript:';return true;" onclick=3D"this.href=3D'javascript:';re=
turn true;">std-proposal...@<wbr>isocpp.org</a>.
<br>> To post to this group, send email to <a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"HeUzokGLCAAJ" rel=3D"nofollow" onmous=
edown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.hr=
ef=3D'javascript:';return true;">std-pr...@isocpp.org</a>.
<br>> To view this discussion on the web visit <a href=3D"https://groups=
..google.com/a/isocpp.org/d/msgid/std-proposals/nlgled%24jdo%241%40ger.gmane=
..org" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'ht=
tps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/nlgled%24jdo%241=
%40ger.gmane.org';return true;" onclick=3D"this.href=3D'https://gro=
ups.google.com/a/isocpp.org/d/msgid/std-proposals/nlgled%24jdo%241%40ger.gm=
ane.org';return true;">https://groups.google.com/a/<wbr>isocpp.org/d/ms=
gid/std-<wbr>proposals/nlgled%24jdo%241%<wbr>40ger.gmane.org</a>.
<br></blockquote></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/fe93ce3f-5a6a-46dd-808e-d10ec60fb111%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fe93ce3f-5a6a-46dd-808e-d10ec60fb111=
%40isocpp.org</a>.<br />
------=_Part_274_15922509.1468340670506--
------=_Part_273_1952398638.1468340670505--
.