Topic: Struture dereference operator as fallback for
Author: =?UTF-8?Q?Micha=C5=82_Dominiak?= <griwes@griwes.info>
Date: Wed, 05 Jul 2017 07:28:04 +0000
Raw View
--94eb2c18a42e81e83105538cf192
Content-Type: text/plain; charset="UTF-8"
This would:
1) Make it very easy to refer to the wrong field accidentally (of the
wrapper instead of of the wrapped object).
2) Make it so that a change in the wrapper's interface (say, adding a
field) changes the semantics of the code in a potentially silent manner -
no-one would ever again be able to add to the interface of a type exposing
the -> operator.
No.
Educate your programmers, don't hire incompetent people. It's really that
simple.
On Wed, Jul 5, 2017 at 9:24 AM Daemon Snake <swac31@gmail.com> wrote:
> Hi,
> I think a lot of us feel like the "->" operator feels quite archaic,
> so it's not uncommon to use the '.' operator while using a pointer or a
> shared or unique pointer by accident.
> The result is a compile error with an indication on where the mistake was
> made along with a "(maybe you meant to use '->' ?)" error message.
>
> For people coming from languages like Java it's a recurring error, one
> that frankly seem a bit dull and really annoying for big projects.
>
> My "solution" would be really simple to implement I believe.
> If said error is detected instead of stopping the compilation and issuing
> the error we could simply fallback on the struct dereference operator
> ("->").
> This wouldn't have any impact on legacy, or C code (or only malformed one).
> It would allow the implicit declaration of the overloading of the
> structure reference operator.
> Also make optional the "->" operator for a less cumbersome syntax at the
> end.
> The compile time impact would be minimal as it would only happen in fail
> states and the computation is not really complex.
>
> So what do you think ?
> Is there issues I haven't considered ?
>
> Thanks in advance.
> Bastien Penavayre
>
> --
> 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/e2d61492-c318-46b1-89e1-94f9697875dd%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e2d61492-c318-46b1-89e1-94f9697875dd%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdSzcO6_4fWYE6SjDpTKTuU1NsGdZCmMzEVJF%3DLajvgpew%40mail.gmail.com.
--94eb2c18a42e81e83105538cf192
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">This would:<div><br></div><div>1) Make it very easy to ref=
er to the wrong field accidentally (of the wrapper instead of of the wrappe=
d object).</div><div>2) Make it so that a change in the wrapper's inter=
face (say, adding a field) changes the semantics of the code in a potential=
ly silent manner - no-one would ever again be able to add to the interface =
of a type exposing the -> operator.</div><div><br></div><div>No.</div><d=
iv><br></div><div>Educate your programmers, don't hire incompetent peop=
le. It's really that simple.</div></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr">On Wed, Jul 5, 2017 at 9:24 AM Daemon Snake <<a href=3D=
"mailto:swac31@gmail.com">swac31@gmail.com</a>> wrote:<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr">Hi,<div>I think a lot of us feel li=
ke the "->" operator feels quite archaic,<br><div>so it's =
not uncommon to use the '.' operator while using a pointer or a sha=
red or unique pointer by accident.</div><div>The result is a compile error =
with an indication on where the mistake was made along with a "<span s=
tyle=3D"color:rgb(0,0,0);font-family:monospace;font-size:12px;white-space:p=
re-wrap">(maybe you meant to use '->' ?)" error message.</s=
pan></div><div><span style=3D"color:rgb(0,0,0);font-family:monospace;font-s=
ize:12px;white-space:pre-wrap"><br></span></div><div><font color=3D"#000000=
" face=3D"monospace"><span style=3D"font-size:12px;white-space:pre-wrap">Fo=
r people coming from languages like Java it's a recurring error, one th=
at frankly seem a bit dull and really annoying for big projects.</span></fo=
nt></div><div><br></div><div>My "solution" would be really simple=
to implement I believe.</div><div>If said error is detected instead of sto=
pping the compilation and issuing the error we could simply fallback on the=
struct dereference operator ("->").</div><div>This wouldn'=
;t have any impact on legacy, or C code (or only malformed one).</div><div>=
It would allow the implicit declaration of the overloading of the structure=
reference operator.</div><div>Also make optional the "->" ope=
rator for a less cumbersome syntax at the end.</div><div>The compile time i=
mpact would be minimal as it would only happen in fail states and the compu=
tation is not really complex.</div><div><br></div><div>So what do you think=
?</div><div>Is there issues I haven't considered ?</div><div><br></div=
><div>Thanks in advance.</div></div><div>Bastien Penavayre</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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e2d61492-c318-46b1-89e1-94f9697875dd%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e2d61492-c318-=
46b1-89e1-94f9697875dd%40isocpp.org</a>.<br>
</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/CAPCFJdSzcO6_4fWYE6SjDpTKTuU1NsGdZCmM=
zEVJF%3DLajvgpew%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdSzcO6_4f=
WYE6SjDpTKTuU1NsGdZCmMzEVJF%3DLajvgpew%40mail.gmail.com</a>.<br />
--94eb2c18a42e81e83105538cf192--
.
Author: Daemon Snake <swac31@gmail.com>
Date: Wed, 5 Jul 2017 00:41:41 -0700 (PDT)
Raw View
------=_Part_978_311487368.1499240502012
Content-Type: multipart/alternative;
boundary="----=_Part_979_1743032249.1499240502012"
------=_Part_979_1743032249.1499240502012
Content-Type: text/plain; charset="UTF-8"
"1)" Is already the case.
struct A { int i; };
struct B {
int i;
A m;
A &operator ->() { return m; }
};
"B().i" now or with the fallback would still refer to B's "i";
If the dev mistakes "." with "->" now or with the fallback the compiler
wouldn't give him any indications either way.
--
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/4f15e79b-fb2d-4609-94e8-e9e7c0115eab%40isocpp.org.
------=_Part_979_1743032249.1499240502012
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">"1)" Is already the case.<div><br></div><div>str=
uct A { int i; };</div><div><br></div><div>struct =C2=A0B {</div><div>=C2=
=A0 int i;</div><div>=C2=A0 A m;</div><div>=C2=A0 A &operator ->() {=
return m; }</div><div>};</div><div><br></div><div>"B().i" now or=
with the fallback would still refer to B's "i";</div><div>If=
the dev mistakes "." with "->" now or with the fall=
back the compiler wouldn't give him any indications either way.</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/4f15e79b-fb2d-4609-94e8-e9e7c0115eab%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4f15e79b-fb2d-4609-94e8-e9e7c0115eab=
%40isocpp.org</a>.<br />
------=_Part_979_1743032249.1499240502012--
------=_Part_978_311487368.1499240502012--
.
Author: Jonathan Coe <jonathanbcoe@gmail.com>
Date: Wed, 5 Jul 2017 09:04:34 +0100
Raw View
--Apple-Mail-F8FD5D6E-76E1-4348-A312-AB05D8390CA8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
> On 5 Jul 2017, at 08:28, Micha=C5=82 Dominiak <griwes@griwes.info> wrote:
>=20
> This would:
>=20
> 1) Make it very easy to refer to the wrong field accidentally (of the wra=
pper instead of of the wrapped object).
> 2) Make it so that a change in the wrapper's interface (say, adding a fie=
ld) changes the semantics of the code in a potentially silent manner - no-o=
ne would ever again be able to add to the interface of a type exposing the =
-> operator.
>=20
> No.
>=20
> Educate your programmers, don't hire incompetent people. It's really that=
simple.
>=20
>> On Wed, Jul 5, 2017 at 9:24 AM Daemon Snake <swac31@gmail.com> wrote:
>> Hi,
>> I think a lot of us feel like the "->" operator feels quite archaic,
>> so it's not uncommon to use the '.' operator while using a pointer or a =
shared or unique pointer by accident.
>> The result is a compile error with an indication on where the mistake wa=
s made along with a "(maybe you meant to use '->' ?)" error message.
>>=20
>> For people coming from languages like Java it's a recurring error, one t=
hat frankly seem a bit dull and really annoying for big projects.
>>=20
>> My "solution" would be really simple to implement I believe.
>> If said error is detected instead of stopping the compilation and issuin=
g the error we could simply fallback on the struct dereference operator ("-=
>").
>> This wouldn't have any impact on legacy, or C code (or only malformed on=
e).
>> It would allow the implicit declaration of the overloading of the struct=
ure reference operator.
>> Also make optional the "->" operator for a less cumbersome syntax at the=
end.
>> The compile time impact would be minimal as it would only happen in fail=
states and the computation is not really complex.
>>=20
>> So what do you think ?
>> Is there issues I haven't considered ?
>>=20
To me '->' suggests that the object could be in a null state, '.' does not.=
=20
I'd be concerned about lost information for readers if '.' no longer implie=
d non-nullable.
>> Thanks in advance.
>> Bastien Penavayre
>> --=20
>> You received this message because you are subscribed to the Google Group=
s "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n 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/iso=
cpp.org/d/msgid/std-proposals/e2d61492-c318-46b1-89e1-94f9697875dd%40isocpp=
..org.
>=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=
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/CAPCFJdSzcO6_4fWYE6SjDpTKTuU1NsGdZCmMzEVJF%3DL=
ajvgpew%40mail.gmail.com.
--=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/A6913DF9-37C5-4465-B663-3FC808583F61%40gmail.com=
..
--Apple-Mail-F8FD5D6E-76E1-4348-A312-AB05D8390CA8
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><br></div><div><br>On 5=
Jul 2017, at 08:28, Micha=C5=82 Dominiak <<a href=3D"mailto:griwes@griw=
es.info">griwes@griwes.info</a>> wrote:<br><br></div><blockquote type=3D=
"cite"><div><div dir=3D"ltr">This would:<div><br></div><div>1) Make it very=
easy to refer to the wrong field accidentally (of the wrapper instead of o=
f the wrapped object).</div><div>2) Make it so that a change in the wrapper=
's interface (say, adding a field) changes the semantics of the code in a p=
otentially silent manner - no-one would ever again be able to add to the in=
terface of a type exposing the -> operator.</div><div><br></div><div>No.=
</div><div><br></div><div>Educate your programmers, don't hire incompetent =
people. It's really that simple.</div></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr">On Wed, Jul 5, 2017 at 9:24 AM Daemon Snake <<a href=3D=
"mailto:swac31@gmail.com">swac31@gmail.com</a>> wrote:<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr">Hi,<div>I think a lot of us feel li=
ke the "->" operator feels quite archaic,<br><div>so it's not uncommon t=
o use the '.' operator while using a pointer or a shared or unique pointer =
by accident.</div><div>The result is a compile error with an indication on =
where the mistake was made along with a "<span style=3D"color:rgb(0,0,0);fo=
nt-family:monospace;font-size:12px;white-space:pre-wrap">(maybe you meant t=
o use '->' ?)" error message.</span></div><div><span style=3D"color:rgb(=
0,0,0);font-family:monospace;font-size:12px;white-space:pre-wrap"><br></spa=
n></div><div><font color=3D"#000000" face=3D"monospace"><span style=3D"font=
-size:12px;white-space:pre-wrap">For people coming from languages like Java=
it's a recurring error, one that frankly seem a bit dull and really annoyi=
ng for big projects.</span></font></div><div><br></div><div>My "solution" w=
ould be really simple to implement I believe.</div><div>If said error is de=
tected instead of stopping the compilation and issuing the error we could s=
imply fallback on the struct dereference operator ("->").</div><div>This=
wouldn't have any impact on legacy, or C code (or only malformed one).</di=
v><div>It would allow the implicit declaration of the overloading of the st=
ructure reference operator.</div><div>Also make optional the "->" operat=
or for a less cumbersome syntax at the end.</div><div>The compile time impa=
ct would be minimal as it would only happen in fail states and the computat=
ion is not really complex.</div><div><br></div><div>So what do you think ?<=
/div><div>Is there issues I haven't considered ?</div><div><br></div></div>=
</div></blockquote></div></div></blockquote><div><br></div><div>To me '->=
;' suggests that the object could be in a null state, '.' does not. </=
div><div>I'd be concerned about lost information for readers if '.' no long=
er implied non-nullable.</div><br><blockquote type=3D"cite"><div><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div>=
Thanks in advance.</div></div><div>Bastien Penavayre</div></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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e2d61492-c318-46b1-89e1-94f9697875dd%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e2d61492-c318-=
46b1-89e1-94f9697875dd%40isocpp.org</a>.<br>
</blockquote></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/CAPCFJdSzcO6_4fWYE6SjDpTKTuU1NsGdZCmM=
zEVJF%3DLajvgpew%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdSzcO=
6_4fWYE6SjDpTKTuU1NsGdZCmMzEVJF%3DLajvgpew%40mail.gmail.com</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/A6913DF9-37C5-4465-B663-3FC808583F61%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/A6913DF9-37C5-4465-B663-3FC808583F61%=
40gmail.com</a>.<br />
--Apple-Mail-F8FD5D6E-76E1-4348-A312-AB05D8390CA8--
.