------=_Part_2983_431619108.1499239482162
Content-Type: multipart/alternative;
 boundary="----=_Part_2984_1147767567.1499239482162"

------=_Part_2984_1147767567.1499239482162
Content-Type: text/plain; charset="UTF-8"

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.

------=_Part_2984_1147767567.1499239482162
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<div>I think a lot of us feel like the &quot;-&gt;&quot=
; operator feels quite archaic,<br><div>so it&#39;s not uncommon to use the=
 &#39;.&#39; operator while using a pointer or a shared or unique pointer b=
y accident.</div><div>The result is a compile error with an indication on w=
here the mistake was made along with a &quot;<span style=3D"color: rgb(0, 0=
, 0); font-family: monospace; font-size: 12px; white-space: pre;">(maybe yo=
u meant to use &#39;-&gt;&#39; ?)&quot; error message.</span></div><div><sp=
an style=3D"color: rgb(0, 0, 0); font-family: monospace; font-size: 12px; w=
hite-space: pre;"><br></span></div><div><font color=3D"#000000" face=3D"mon=
ospace"><span style=3D"font-size: 12px; white-space: pre;">For people comin=
g from languages like Java it&#39;s a recurring error, one that frankly see=
m a bit dull and really annoying for big projects.</span></font></div><div>=
<br></div><div>My &quot;solution&quot; would be really simple to implement =
I believe.</div><div>If said error is detected instead of stopping the comp=
ilation and issuing the error we could simply fallback on the struct derefe=
rence operator (&quot;-&gt;&quot;).</div><div>This wouldn&#39;t have any im=
pact on legacy, or C code (or only malformed one).</div><div>It would allow=
 the implicit declaration of the overloading of the structure reference ope=
rator.</div><div>Also make optional the &quot;-&gt;&quot; operator for a le=
ss cumbersome syntax at the end.</div><div>The compile time impact would be=
 minimal as it would only happen in fail states and the computation is not =
really complex.</div><div><br></div><div>So what do you think ?</div><div>I=
s there issues I haven&#39;t considered ?</div><div><br></div><div>Thanks i=
n 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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e2d61492-c318-46b1-89e1-94f9697875dd=
%40isocpp.org</a>.<br />

------=_Part_2984_1147767567.1499239482162--

------=_Part_2983_431619108.1499239482162--

.