Topic: this in non-member functions


Author: Viacheslav Usov <via.usov@gmail.com>
Date: Wed, 3 Aug 2016 11:58:15 +0200
Raw View
--001a1141024249b2b2053927df4a
Content-Type: text/plain; charset=UTF-8

Something like this may have been proposed or discussed earlier, please
point me to prior work.

Today the 'this' pointer is available only in member functions and lambda
expressions where it is captured, explicitly or implicitly.

I propose generalising this further and making it available in non-member
functions, where it must be introduced via a regular declaration, either as
a parameter or a local variable.

In a non-member function where 'this' is declared, name lookup should work
as if the function were a member of the class of 'this'. A non-member
function with a declared this can still access only the public members of
the class.

Examples:

struct A { int x; };

void foo(A *this) { x = 1; } // equivalent to this->x = 1

void bar(A *ptr) { A *this = ptr; x = 2; } // equivalent to ptr->x = 2

Open questions.

A. Should we allow this to be an lvalue, i.e., after it was declared, can
it be assigned a different value?

A'. Note today 'this' is specified as a prvalue, which is probably the way
it should stay in member functions (essentially as if it were declared via
X * const this).

B. Should we allow only one declaration of this per non-member function,
i.e., disallow its re-declaration in nested scopes?

B'. If the answer to B is no, what about member functions? Should they
still not allow such re-declarations?

In principle, as seen in the open questions, a more radical proposal can be
made, where this could be coupled with an object per scope rather than per
function, and the only distinction between member and non-member is that
the former have 'this' implicitly declared as a const pointer.

Cheers,
V.

--
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/CAA7YVg3ObHqk-rfGRqgCqw3D-%3Du2pOwz%3Dp8NHtC6n9tpBLq-Aw%40mail.gmail.com.

--001a1141024249b2b2053927df4a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Something like this may have been proposed or discussed ea=
rlier, please point me to prior work.<div><br></div><div>Today the &#39;thi=
s&#39; pointer is available only in member functions and lambda expressions=
 where it is captured, explicitly or implicitly.</div><div><br></div><div>I=
 propose generalising this further and making it available in non-member fu=
nctions, where it must be introduced via a regular declaration, either as a=
 parameter or a local variable.</div><div><br></div><div>In a non-member fu=
nction where &#39;this&#39; is declared, name lookup should work as if the =
function were a member of the class of &#39;this&#39;. A non-member functio=
n with a declared this can still access only the public members of the clas=
s.<br></div><div><br></div><div>Examples:</div><div><br></div><div>struct A=
 { int x; };</div><div><br></div><div>void foo(A *this) { x =3D 1; } // equ=
ivalent to this-&gt;x =3D 1</div><div><br></div><div>void bar(A *ptr) { A *=
this =3D ptr; x =3D 2; } // equivalent to ptr-&gt;x =3D 2</div><div><br></d=
iv><div>Open questions.</div><div><br></div><div>A. Should we allow this to=
 be an lvalue, i.e., after it was declared, can it be assigned a different =
value?</div><div><br></div><div>A&#39;. Note today &#39;this&#39; is specif=
ied as a prvalue, which is probably the way it should stay in member functi=
ons (essentially as if it were declared via X * const this).</div><div><br>=
</div><div>B. Should we allow only one declaration of this per non-member f=
unction, i.e., disallow its re-declaration in nested scopes?</div><div><br>=
</div><div>B&#39;. If the answer to B is no, what=C2=A0about member functio=
ns? Should they still not allow such re-declarations?</div><div><br></div><=
div>In principle, as seen in the open questions, a more radical proposal ca=
n be made, where this could be coupled with an object per scope rather than=
 per function, and the only distinction between member and non-member is th=
at the former have &#39;this&#39; implicitly declared as a const pointer.</=
div><div><br></div><div>Cheers,</div><div>V.</div><div><br></div><div><br><=
/div><div><br></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/CAA7YVg3ObHqk-rfGRqgCqw3D-%3Du2pOwz%3=
Dp8NHtC6n9tpBLq-Aw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3ObHqk=
-rfGRqgCqw3D-%3Du2pOwz%3Dp8NHtC6n9tpBLq-Aw%40mail.gmail.com</a>.<br />

--001a1141024249b2b2053927df4a--

.


Author: "D. B." <db0451@gmail.com>
Date: Wed, 3 Aug 2016 11:10:09 +0100
Raw View
--001a114be8fedca3c80539280984
Content-Type: text/plain; charset=UTF-8

This looks like an attempt to provide something more like (there are
probably better examples available, but:) Visual Basic's *With *keyword,
i.e. to avoid people typing the name of a repeatedly used object, rather
than the real purpose of *this*, which is to refer to the current object
within a member function (or honorary member lambda).

Perhaps for the same reason, a separate syntax would be required or at
least highly advisable. I feel sharing *this* for different purposes could
get far too confusing. But I have always felt *With* to be perhaps the sole
redeeming feature of VB... ;-)

That said, in reality, I'm OK with declaring an input reference with a
short name and using that. Usually if one is repeatedly referring to a long
object name and wants a way to continue doing so while saving keystrokes -
I think there are more pressing program design considerations to address,
rather than requiring a new keyword.

--
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/CACGiwhFQLRA2M3ai7RNU5Zn3LdoV_TyZr2ySCshGEk%3DHy7-rsA%40mail.gmail.com.

--001a114be8fedca3c80539280984
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>This looks like an attempt to provide somet=
hing more like (there are probably better examples available, but:) Visual =
Basic&#39;s <i>With </i>keyword, i.e. to avoid people typing the name of a =
repeatedly used object, rather than the real purpose of <i>this</i>, which =
is to refer to the current object within a member function (or honorary mem=
ber lambda).<br><br></div>Perhaps for the same reason, a separate syntax wo=
uld be required or at least highly advisable. I feel sharing <i>this</i> fo=
r different purposes could get far too confusing. But I have always felt <i=
>With</i> to be perhaps the sole redeeming feature of VB... ;-)<br><br></di=
v>That said, in reality, I&#39;m OK with declaring an input reference with =
a short name and using that. Usually if one is repeatedly referring to a lo=
ng object name and wants a way to continue doing so while saving keystrokes=
 - I think there are more pressing program design considerations to address=
, rather than requiring a new keyword.<br><br></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/CACGiwhFQLRA2M3ai7RNU5Zn3LdoV_TyZr2yS=
CshGEk%3DHy7-rsA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhFQLRA2M3=
ai7RNU5Zn3LdoV_TyZr2ySCshGEk%3DHy7-rsA%40mail.gmail.com</a>.<br />

--001a114be8fedca3c80539280984--

.


Author: Viacheslav Usov <via.usov@gmail.com>
Date: Wed, 3 Aug 2016 12:28:05 +0200
Raw View
--001a114187e80250cc0539284a57
Content-Type: text/plain; charset=UTF-8

On Wed, Aug 3, 2016 at 12:10 PM, D. B. <db0451@gmail.com> wrote:

> This looks like an attempt to provide something more like (there are
probably better examples available, but:) Visual Basic's *With *keyword,
i.e. to avoid people typing the name of a repeatedly used object, rather
than the real purpose of *this*, which is to refer to the current object
within a member function (or honorary member lambda).

I'd say 'this' has two functions. One is indeed "to refer to the current
object within a member function", but that alone is achievable by the
"fully qualified" syntax this->X. And another function is merely "to avoid
people typing the name of a repeatedly used object", but it only works
where 'this' is available.

The second function *is* useful per se, and I see no reason why the second
function could not be generalised. I think it sort of follows the paradigm
that x.f(y) and f(x, y) are just really two different syntaxes meaning the
same thing, and generalising 'this' as proposed would allow the latter to
be written internally almost like the former.

Cheers,
V.

--
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/CAA7YVg3okF2gn3d5yaez94GMiv2tUFumvPsaKbXg6m0Y530-QA%40mail.gmail.com.

--001a114187e80250cc0539284a57
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Aug 3, 2016 at 12:10 PM, D. B. <span dir=3D"ltr">&lt;<a href=3D"mailto:=
db0451@gmail.com" target=3D"_blank">db0451@gmail.com</a>&gt;</span> wrote:<=
/div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">&gt; T=
his looks like an attempt to provide something more like (there are probabl=
y better examples available, but:) Visual Basic&#39;s <i>With </i>keyword, =
i.e. to avoid people typing the name of a repeatedly used object, rather th=
an the real purpose of <i>this</i>, which is to refer to the current object=
 within a member function (or honorary member lambda).</div><div class=3D"g=
mail_quote"><br></div><div class=3D"gmail_quote">I&#39;d say &#39;this&#39;=
 has two functions. One is indeed &quot;to refer to the current object with=
in a member function&quot;, but that alone is achievable by the &quot;fully=
 qualified&quot; syntax this-&gt;X. And another function is merely &quot;to=
 avoid people typing the name of a repeatedly used object&quot;, but it onl=
y works where &#39;this&#39; is available.</div><div class=3D"gmail_quote">=
<br></div><div class=3D"gmail_quote">The second function <i>is</i>=C2=A0use=
ful per se, and=C2=A0I see no reason why the second function could not be g=
eneralised. I think it sort of follows the paradigm that x.f(y) and f(x, y)=
 are just really two different syntaxes meaning the same thing, and general=
ising &#39;this&#39; as proposed would allow the latter to be written inter=
nally almost like the former.</div><div class=3D"gmail_quote"><br></div><di=
v class=3D"gmail_quote">Cheers,</div><div class=3D"gmail_quote">V.</div></d=
iv></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/CAA7YVg3okF2gn3d5yaez94GMiv2tUFumvPsa=
KbXg6m0Y530-QA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3okF2gn3d5=
yaez94GMiv2tUFumvPsaKbXg6m0Y530-QA%40mail.gmail.com</a>.<br />

--001a114187e80250cc0539284a57--

.


Author: jsphadetula@gmail.com
Date: Wed, 3 Aug 2016 10:55:34 +0000 (UTC)
Raw View
------=_Part_1514_497194241.1470221734790
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



I think if the Uniform Call Syntax proposal is eventually accepted, there w=
ill no need for this feature anymore


Get Outlook for Android






On Wed, Aug 3, 2016 at 11:28 AM +0100, "Viacheslav Usov" <via.usov@gmail.co=
m> wrote:










On Wed, Aug 3, 2016 at 12:10 PM, D. B. <db0451@gmail.com> wrote:
> This looks like an attempt to provide something more like (there are prob=
ably better examples available, but:) Visual Basic's With keyword, i.e. to =
avoid people typing the name of a repeatedly used object, rather than the r=
eal purpose of this, which is to refer to the current object within a membe=
r function (or honorary member lambda).
I'd say 'this' has two functions. One is indeed "to refer to the current ob=
ject within a member function", but that alone is achievable by the "fully =
qualified" syntax this->X. And another function is merely "to avoid people =
typing the name of a repeatedly used object", but it only works where 'this=
' is available.
The second function is=C2=A0useful per se, and=C2=A0I see no reason why the=
 second function could not be generalised. I think it sort of follows the p=
aradigm that x.f(y) and f(x, y) are just really two different syntaxes mean=
ing the same thing, and generalising 'this' as proposed would allow the lat=
ter to be written internally almost like the former.
Cheers,V.





--=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/CAA7YVg3okF2gn3d5yaez94GMiv2tUFumvPsaKbXg6m0Y530=
-QA%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/997FEFE7601FB061.02d36407-64db-41ec-a64b-eabcdd0=
bd9c8%40mail.outlook.com.

------=_Part_1514_497194241.1470221734790
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html><head></head><body><p dir=3D"auto">I think if the Uniform Call Syntax=
 proposal is eventually accepted, there will no need for this feature anymo=
re</p>
<p dir=3D"auto">Get <a href=3D"https://aka.ms/ghei36">Outlook for Android</=
a><br>
</p>
<br><br><br>
<div class=3D"gmail_quote">On Wed, Aug 3, 2016 at 11:28 AM +0100, "Viachesl=
av Usov" <span dir=3D"ltr">&lt;<a href=3D"mailto:via.usov@gmail.com" target=
=3D"_blank">via.usov@gmail.com</a>&gt;</span> wrote:<br>
<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">




<div dir=3D"3D&quot;ltr&quot;">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Aug 3, 2016 at 12:10 PM, D. B. <span dir=3D"ltr">&lt;<a href=3D"mailto:=
db0451@gmail.com" target=3D"_blank">db0451@gmail.com</a>&gt;</span> wrote:<=
/div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">&gt; T=
his looks like an attempt to provide something more like (there are probabl=
y better examples available, but:) Visual Basic's <i>With </i>keyword, i.e.=
 to avoid people typing the name of a repeatedly used object, rather than t=
he real purpose of <i>this</i>, which is to refer to the current object wit=
hin a member function (or honorary member lambda).</div><div class=3D"gmail=
_quote"><br></div><div class=3D"gmail_quote">I'd say 'this' has two functio=
ns. One is indeed "to refer to the current object within a member function"=
, but that alone is achievable by the "fully qualified" syntax this-&gt;X. =
And another function is merely "to avoid people typing the name of a repeat=
edly used object", but it only works where 'this' is available.</div><div c=
lass=3D"gmail_quote"><br></div><div class=3D"gmail_quote">The second functi=
on <i>is</i>&nbsp;useful per se, and&nbsp;I see no reason why the second fu=
nction could not be generalised. I think it sort of follows the paradigm th=
at x.f(y) and f(x, y) are just really two different syntaxes meaning the sa=
me thing, and generalising 'this' as proposed would allow the latter to be =
written internally almost like the former.</div><div class=3D"gmail_quote">=
<br></div><div class=3D"gmail_quote">Cheers,</div><div class=3D"gmail_quote=
">V.</div></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">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/CAA7YVg3okF2gn3d5yaez94GMiv2tUFumvPsa=
KbXg6m0Y530-QA%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3okF2g=
n3d5yaez94GMiv2tUFumvPsaKbXg6m0Y530-QA%40mail.gmail.com</a>.<br>

</div>

</blockquote>
</div>
</body></html>

<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/997FEFE7601FB061.02d36407-64db-41ec-a=
64b-eabcdd0bd9c8%40mail.outlook.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/997FEFE7601FB=
061.02d36407-64db-41ec-a64b-eabcdd0bd9c8%40mail.outlook.com</a>.<br />

------=_Part_1514_497194241.1470221734790--

.


Author: Viacheslav Usov <via.usov@gmail.com>
Date: Wed, 3 Aug 2016 13:01:26 +0200
Raw View
--001a1142b9403ae2a6053928c19d
Content-Type: text/plain; charset=UTF-8

On Wed, Aug 3, 2016 at 12:55 PM, <jsphadetula@gmail.com> wrote:

> I think if the Uniform Call Syntax proposal is eventually accepted, there
will no need for this feature anymore

I do not see why. Can you explain?

Cheers,
V.

--
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/CAA7YVg1322csXfxyQ72-dUB9%3D4HKYEOt707OOQZqLHCBph%2Bsdw%40mail.gmail.com.

--001a1142b9403ae2a6053928c19d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Aug 3, 2016 at 12:55 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:jspha=
detula@gmail.com" target=3D"_blank">jsphadetula@gmail.com</a>&gt;</span> wr=
ote:</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">&=
gt; I think if the Uniform Call Syntax proposal is eventually accepted, the=
re will no need for this feature anymore</div><div class=3D"gmail_quote"><b=
r></div><div class=3D"gmail_quote">I do not see why. Can you explain?</div>=
<div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Cheers,</di=
v><div class=3D"gmail_quote">V.</div></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/CAA7YVg1322csXfxyQ72-dUB9%3D4HKYEOt70=
7OOQZqLHCBph%2Bsdw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg1322cs=
XfxyQ72-dUB9%3D4HKYEOt707OOQZqLHCBph%2Bsdw%40mail.gmail.com</a>.<br />

--001a1142b9403ae2a6053928c19d--

.


Author: gmisocpp@gmail.com
Date: Wed, 3 Aug 2016 04:45:39 -0700 (PDT)
Raw View
------=_Part_6961_1921104750.1470224739954
Content-Type: multipart/alternative;
 boundary="----=_Part_6962_1408277784.1470224739954"

------=_Part_6962_1408277784.1470224739954
Content-Type: text/plain; charset=UTF-8



On Wednesday, August 3, 2016 at 11:01:29 PM UTC+12, Viacheslav Usov wrote:
>
> On Wed, Aug 3, 2016 at 12:55 PM, <jspha...@gmail.com <javascript:>> wrote:
>
> > I think if the Uniform Call Syntax proposal is eventually accepted,
> there will no need for this feature anymore
>

That was my thought too.


> I do not see why. Can you explain?
>
> Cheers,
> V.
>

So taking your example:
Struct A { int x; };
void foo(A *this) { x = 1; }
I thought that with UFCS, this would be allowed:
A a;
a.foo();
resulting in foo(A* a) being called
and a->x = 1 would perform the same action as your example.

If that's wrong or missing the point, what's your proposal about or aiming
at compared to UFC?


--
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/040024a5-3390-4613-afef-a4a8aea0ca8c%40isocpp.org.

------=_Part_6962_1408277784.1470224739954
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, August 3, 2016 at 11:01:29 PM UTC+12=
, Viacheslav Usov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204)=
; border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div>=
<div class=3D"gmail_quote">On Wed, Aug 3, 2016 at 12:55 PM,  <span dir=3D"l=
tr">&lt;<a onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" o=
nclick=3D"this.href=3D&#39;javascript:&#39;;return true;" href=3D"javascrip=
t:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"bsOuCJk-BwA=
J">jspha...@gmail.com</a>&gt;</span> wrote:</div><div class=3D"gmail_quote"=
><br></div><div class=3D"gmail_quote">&gt; I think if the Uniform Call Synt=
ax proposal is eventually accepted, there will no need for this feature any=
more</div></div></div></blockquote><div><br></div><div>That was my thought =
too.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204=
); border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div=
><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">I do not s=
ee why. Can you explain?</div><div class=3D"gmail_quote"><br></div><div cla=
ss=3D"gmail_quote">Cheers,</div><div class=3D"gmail_quote">V.</div></div></=
div></blockquote><div><br></div><div><div>So taking your example:<br>Struct=
 A { int x; };<br>void foo(A *this) { x =3D 1; } </div><div>I thought that =
with UFCS, this would be allowed:</div><div>A a;<br>a.foo();</div><div>resu=
lting in foo(A* a) being called<br>and a-&gt;x =3D 1 would perform the same=
 action=C2=A0as your example.</div><div><br></div><div>If that&#39;s wrong =
or missing the point, what&#39;s your proposal about or aiming at compared =
to UFC?<br>=C2=A0=C2=A0</div></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/040024a5-3390-4613-afef-a4a8aea0ca8c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/040024a5-3390-4613-afef-a4a8aea0ca8c=
%40isocpp.org</a>.<br />

------=_Part_6962_1408277784.1470224739954--

------=_Part_6961_1921104750.1470224739954--

.


Author: Viacheslav Usov <via.usov@gmail.com>
Date: Wed, 3 Aug 2016 13:57:31 +0200
Raw View
--001a11410242cdc696053929892d
Content-Type: text/plain; charset=UTF-8

On Wed, Aug 3, 2016 at 1:45 PM, <gmisocpp@gmail.com> wrote:


> So taking your example:
> Struct A { int x; };
> void foo(A *this) { x = 1; }
> I thought that with UFCS, this would be allowed:
> A a;
> a.foo();
> resulting in foo(A* a) being called
> and a->x = 1 would perform the same action as your example.
>

With unified call syntax and without my proposal, the example is
ill-formed, because you cannot use this as foo's parameter name. You would
need to modify it somehow, say as void foo(A *ptr) { x = 1; }. But that
would also be ill-formed, unless there is a global variable named 'x'. If
there is a global named 'x', then the effect of foo would be to set the
value of that global, not the field 'x' in a structure pointed to by its
parameter.

Cheers,
V.

--
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/CAA7YVg2yPQ9NbZuxU7fMJ1bkErAJsi5LuM2%3DuOuNn0pU%2BpNfag%40mail.gmail.com.

--001a11410242cdc696053929892d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Aug 3, 2016 at 1:45 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:gmisoc=
pp@gmail.com" target=3D"_blank">gmisocpp@gmail.com</a>&gt;</span> wrote:<br=
><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:=
rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div>So taking you=
r example:<br>Struct A { int x; };<br>void foo(A *this) { x =3D 1; } </div>=
<div>I thought that with UFCS, this would be allowed:</div><div>A a;<br>a.f=
oo();</div><div>resulting in foo(A* a) being called<br>and a-&gt;x =3D 1 wo=
uld perform the same action=C2=A0as your example.</div></div></div></blockq=
uote><div><br></div><div>With unified call syntax and without my proposal, =
the example is ill-formed, because you cannot use this as foo&#39;s paramet=
er name. You would need to modify it somehow, say as void foo(A *ptr) { x =
=3D 1; }. But that would also be ill-formed, unless there is a global varia=
ble named &#39;x&#39;. If there is a global named &#39;x&#39;, then the eff=
ect of foo would be to set the value of that global, not the field &#39;x&#=
39; in a structure pointed to by its parameter.</div><div><br></div><div>Ch=
eers,</div><div>V.</div></div></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/CAA7YVg2yPQ9NbZuxU7fMJ1bkErAJsi5LuM2%=
3DuOuNn0pU%2BpNfag%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2yPQ9N=
bZuxU7fMJ1bkErAJsi5LuM2%3DuOuNn0pU%2BpNfag%40mail.gmail.com</a>.<br />

--001a11410242cdc696053929892d--

.


Author: gmisocpp@gmail.com
Date: Wed, 3 Aug 2016 05:11:47 -0700 (PDT)
Raw View
------=_Part_7820_96124510.1470226307785
Content-Type: multipart/alternative;
 boundary="----=_Part_7821_2000410389.1470226307785"

------=_Part_7821_2000410389.1470226307785
Content-Type: text/plain; charset=UTF-8



On Wednesday, August 3, 2016 at 11:57:34 PM UTC+12, Viacheslav Usov wrote:
>
> On Wed, Aug 3, 2016 at 1:45 PM, <gmis...@gmail.com <javascript:>> wrote:
>
>
>> So taking your example:
>> Struct A { int x; };
>> void foo(A *this) { x = 1; }
>> I thought that with UFCS, this would be allowed:
>> A a;
>> a.foo();
>> resulting in foo(A* a) being called
>> and a->x = 1 would perform the same action as your example.
>>
>
> With unified call syntax and without my proposal, the example is
> ill-formed, because you cannot use this as foo's parameter name. You would
> need to modify it somehow, say as void foo(A *ptr) { x = 1; }. But that
> would also be ill-formed, unless there is a global variable named 'x'. If
> there is a global named 'x', then the effect of foo would be to set the
> value of that global, not the field 'x' in a structure pointed to by its
> parameter.
>
> Cheers,
> V.
>

ok but if I had UFCS why wouldn't I be content with a descriptive name like
ptr instead of 'this'.
What is it your proposal doing for me that I still want/need if I had UFCS.
Sorry I'm not seeing it already I'm sure it's my fault.

--
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/cf5b6196-63bc-49ff-8a6a-bfdfb8a7ab0e%40isocpp.org.

------=_Part_7821_2000410389.1470226307785
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, August 3, 2016 at 11:57:34 PM UTC+12=
, Viacheslav Usov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204)=
; border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div>=
<div class=3D"gmail_quote">On Wed, Aug 3, 2016 at 1:45 PM,  <span dir=3D"lt=
r">&lt;<a onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" on=
click=3D"this.href=3D&#39;javascript:&#39;;return true;" href=3D"javascript=
:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"gfJqm6hBBwAJ=
">gmis...@gmail.com</a>&gt;</span> wrote:<br><div>=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex;=
 border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left=
-style: solid;"><div dir=3D"ltr"><div><div>So taking your example:<br>Struc=
t A { int x; };<br>void foo(A *this) { x =3D 1; } </div><div>I thought that=
 with UFCS, this would be allowed:</div><div>A a;<br>a.foo();</div><div>res=
ulting in foo(A* a) being called<br>and a-&gt;x =3D 1 would perform the sam=
e action=C2=A0as your example.</div></div></div></blockquote><div><br></div=
><div>With unified call syntax and without my proposal, the example is ill-=
formed, because you cannot use this as foo&#39;s parameter name. You would =
need to modify it somehow, say as void foo(A *ptr) { x =3D 1; }. But that w=
ould also be ill-formed, unless there is a global variable named &#39;x&#39=
;. If there is a global named &#39;x&#39;, then the effect of foo would be =
to set the value of that global, not the field &#39;x&#39; in a structure p=
ointed to by its parameter.</div><div><br></div><div>Cheers,</div><div>V.</=
div></div></div></div></blockquote><div><br></div><div>ok but=C2=A0if I had=
 UFCS why wouldn&#39;t=C2=A0I be=C2=A0content with=C2=A0a descriptive name =
like ptr instead of &#39;this&#39;.</div><div>What is it=C2=A0your proposal=
 doing for me that I still want/need if I had UFCS.</div><div>Sorry I&#39;m=
 not seeing it already I&#39;m sure it&#39;s my fault.</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/cf5b6196-63bc-49ff-8a6a-bfdfb8a7ab0e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cf5b6196-63bc-49ff-8a6a-bfdfb8a7ab0e=
%40isocpp.org</a>.<br />

------=_Part_7821_2000410389.1470226307785--

------=_Part_7820_96124510.1470226307785--

.


Author: Viacheslav Usov <via.usov@gmail.com>
Date: Wed, 3 Aug 2016 14:37:14 +0200
Raw View
--001a113fb874df1aa605392a17ae
Content-Type: text/plain; charset=UTF-8

On Wed, Aug 3, 2016 at 2:11 PM, <gmisocpp@gmail.com> wrote:

> What is it your proposal doing for me that I still want/need if I had
UFCS.

The proposal is not directly related to unified call syntax. Nor do I think
there is any overlap, even though both blur the distinction between member
and non-member functions.

My proposal is solely about making the implicit "this->" available to
non-member functions, so that a function like

void foo(A *this) { x = 1; }

is equivalent to

void foo(A *ptr) { ptr->x = 1; }

Cheers,
V.

--
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/CAA7YVg2BQaVD2MyLyyEWuzWUnqjGrNUUi9eZwy7skjq8%3DourvA%40mail.gmail.com.

--001a113fb874df1aa605392a17ae
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Aug 3, 2016 at 2:11 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:gmisoc=
pp@gmail.com" target=3D"_blank">gmisocpp@gmail.com</a>&gt;</span> wrote:<br=
><div><br></div><div>&gt; What is it=C2=A0your proposal doing for me that I=
 still want/need if I had UFCS.</div><div><br></div><div>The proposal is no=
t directly related to unified call syntax. Nor do I think there is any over=
lap, even though both blur the distinction between member and non-member fu=
nctions.</div><div><br></div><div>My proposal is solely about making the im=
plicit &quot;this-&gt;&quot; available to non-member functions, so that a f=
unction like</div><div><br></div><div>void foo(A *this) { x =3D 1; }</div><=
div><br></div><div>is equivalent to=C2=A0</div><div><br></div><div>void foo=
(A *ptr) { ptr-&gt;x =3D 1; }<br></div><div><br></div><div>Cheers,<br></div=
><div>V.</div></div></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/CAA7YVg2BQaVD2MyLyyEWuzWUnqjGrNUUi9eZ=
wy7skjq8%3DourvA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2BQaVD2M=
yLyyEWuzWUnqjGrNUUi9eZwy7skjq8%3DourvA%40mail.gmail.com</a>.<br />

--001a113fb874df1aa605392a17ae--

.


Author: "'Johannes Schaub' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Wed, 3 Aug 2016 20:03:58 +0200
Raw View
I would propose an "expression reinterpret cast", which reinterprets
any expression that matches a passed pattern within its body. "[rule]"
refers to a grammar rule and "<n>" to a captured grammar rule. So,
this would be

    reinterpret_cast([unqualified-id], this-><1>) {
      m = 1; // equivalent: this->m = 1;
    }


2016-08-03 11:58 GMT+02:00 Viacheslav Usov <via.usov@gmail.com>:
> Something like this may have been proposed or discussed earlier, please
> point me to prior work.
>
> Today the 'this' pointer is available only in member functions and lambda
> expressions where it is captured, explicitly or implicitly.
>
> I propose generalising this further and making it available in non-member
> functions, where it must be introduced via a regular declaration, either as
> a parameter or a local variable.
>
> In a non-member function where 'this' is declared, name lookup should work
> as if the function were a member of the class of 'this'. A non-member
> function with a declared this can still access only the public members of
> the class.
>
> Examples:
>
> struct A { int x; };
>
> void foo(A *this) { x = 1; } // equivalent to this->x = 1
>
> void bar(A *ptr) { A *this = ptr; x = 2; } // equivalent to ptr->x = 2
>
> Open questions.
>
> A. Should we allow this to be an lvalue, i.e., after it was declared, can it
> be assigned a different value?
>
> A'. Note today 'this' is specified as a prvalue, which is probably the way
> it should stay in member functions (essentially as if it were declared via X
> * const this).
>
> B. Should we allow only one declaration of this per non-member function,
> i.e., disallow its re-declaration in nested scopes?
>
> B'. If the answer to B is no, what about member functions? Should they still
> not allow such re-declarations?
>
> In principle, as seen in the open questions, a more radical proposal can be
> made, where this could be coupled with an object per scope rather than per
> function, and the only distinction between member and non-member is that the
> former have 'this' implicitly declared as a const pointer.
>
> Cheers,
> V.
>
>
>
> --
> 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/CAA7YVg3ObHqk-rfGRqgCqw3D-%3Du2pOwz%3Dp8NHtC6n9tpBLq-Aw%40mail.gmail.com.

--
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/CANu6V4X6jDVVuuvyN8P47ojxds%3DkpORey23i%2BKzhrWh3%3DG1L1w%40mail.gmail.com.

.


Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 03 Aug 2016 14:04:19 -0700
Raw View
On quarta-feira, 3 de agosto de 2016 14:37:14 PDT Viacheslav Usov wrote:
> void foo(A *this) { x = 1; }
>
> is equivalent to
>
> void foo(A *ptr) { ptr->x = 1; }

Understood, but is this the only benefit? Is it worth the hassle for saving a
few keystrokes?

Also note that it's not a member function, so it can't access protecteds and
privates of the object.

I'm not opposed to it, but if the gain is that small...

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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/2351486.cE391vEbrj%40tjmaciei-mobl1.

.


Author: gmisocpp@gmail.com
Date: Wed, 3 Aug 2016 16:57:47 -0700 (PDT)
Raw View
------=_Part_58_1887455408.1470268667949
Content-Type: multipart/alternative;
 boundary="----=_Part_59_1300184817.1470268667950"

------=_Part_59_1300184817.1470268667950
Content-Type: text/plain; charset=UTF-8



On Thursday, August 4, 2016 at 12:37:17 AM UTC+12, Viacheslav Usov wrote:
>
>
> The proposal is not directly related to unified call syntax. Nor do I
> think there is any overlap, even though both blur the distinction between
> member and non-member functions.
>
> My proposal is solely about making the implicit "this->" available to
> non-member functions, so that a function like
>
> void foo(A *this) { x = 1; }
>
> is equivalent to
>
> void foo(A *ptr) { ptr->x = 1; }
>
> Cheers,
> V.
>

I think I understand the idea now and it would seem to add consistency so I
kind of like it but I feel it pulls at an issue I've never quite comes to
terms with in C++, which is:

I often find myself unsure in code bases at times like this:
some_class::foo_member()
{
//<page of code here>
something = x; // hmmm is something a member of not - i forget.
}

Your proposal would seem to encourage creation of more of that code by
allowing non member functions to engage in the practice.

Of course this is why people do this->something = x; or something_ = x;
But at times I find that objectionable too and you're proposal would allow
me to dispense with that so suddenly I like your proposal again.

So your proposal seems to give me the chance/choice to indulge more in both
activities for more bouts of conflict but also peace.  shrug. On balance I
think there's something empowering to give me that choice so I'm somewhat
in favour of the proposal.

But I can't help but tangle or want to mangle your proposal up with UFCS
though, I need to think more about why that is and if I really want or
don't want to do that. That may mean I want your proposal to go further.
I'm not sure yet.

On that note I wonder if when I want to use your feature it means my non
member function wants to access a lot of member variables
which *might* imply my non member has a tight association with the
class. If so, I wonder that don't then i want this feature to enable some
kind of extension method type relationship of the non member to the class
and suddenly I'm all blurred with UFCS.

I don't know if this makes sense but hopefully someone can untangle my
feelings to something more tangible.

--
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/bbe7ed89-5bd2-4ddf-ae88-6d2e67e8e81b%40isocpp.org.

------=_Part_59_1300184817.1470268667950
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, August 4, 2016 at 12:37:17 AM UTC+12,=
 Viacheslav Usov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204);=
 border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div><=
div class=3D"gmail_quote"><div><br></div><div>The proposal is not directly =
related to unified call syntax. Nor do I think there is any overlap, even t=
hough both blur the distinction between member and non-member functions.</d=
iv><div><br></div><div>My proposal is solely about making the implicit &quo=
t;this-&gt;&quot; available to non-member functions, so that a function lik=
e</div><div><br></div><div>void foo(A *this) { x =3D 1; }</div><div><br></d=
iv><div>is equivalent to=C2=A0</div><div><br></div><div>void foo(A *ptr) { =
ptr-&gt;x =3D 1; }<br></div><div><br></div><div>Cheers,<br></div><div>V.</d=
iv></div></div></div></blockquote><div><br></div><div>I think I understand =
the idea now and it would seem to add=C2=A0consistency so I kind of like it=
 but I feel it=C2=A0pulls at an issue I&#39;ve never quite comes to terms w=
ith in C++, which is:</div><div><br></div><div>I=C2=A0often find myself uns=
ure in code bases=C2=A0at times like this:</div><div>some_class::foo_member=
()</div><div>{</div><div>//&lt;page of code here&gt;</div><div>something =
=3D x; // hmmm is something a member of not -=C2=A0i forget.<br>}</div><div=
><br></div><div>Your=C2=A0proposal would seem to encourage creation of more=
 of that=C2=A0code=C2=A0by allowing non member functions to engage in the p=
ractice.</div><div><br></div><div>Of course this is why people do this-&gt;=
something =3D x; or something_ =3D x;</div><div>But at times I=C2=A0find th=
at objectionable=C2=A0too and you&#39;re proposal would allow me to dispens=
e with that=C2=A0so suddenly I like=C2=A0your proposal=C2=A0again.</div><di=
v><br></div><div>So your proposal=C2=A0seems to give me the chance/choice t=
o indulge=C2=A0more in both activities for more bouts of conflict=C2=A0but =
also=C2=A0peace.=C2=A0 shrug. On balance I think there&#39;s something empo=
wering to give me that choice=C2=A0so I&#39;m=C2=A0somewhat in favour of th=
e proposal.</div><div><br></div><div>But I can&#39;t help but tangle=C2=A0o=
r want to=C2=A0mangle=C2=A0your proposal=C2=A0up with UFCS though, I need t=
o think more=C2=A0about why that is and if=C2=A0I really want or don&#39;t =
want=C2=A0to do that.=C2=A0That may=C2=A0mean I want=C2=A0your proposal to =
go further. I&#39;m not sure yet.</div><div><br></div><div>On that note I w=
onder if when=C2=A0I want to use your feature=C2=A0it means my non member f=
unction=C2=A0wants to access a lot of member variables which=C2=A0*might*=
=C2=A0imply=C2=A0my non member has a tight association with the class.=C2=
=A0If=C2=A0so, I wonder that don&#39;t then i want this feature to enable s=
ome kind of extension method type=C2=A0relationship=C2=A0of the non member =
to the=C2=A0class and suddenly I&#39;m all=C2=A0blurred with=C2=A0UFCS.</di=
v><div><br></div><div>I don&#39;t know if this makes sense but hopefully so=
meone can untangle=C2=A0my feelings to something more tangible.</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/bbe7ed89-5bd2-4ddf-ae88-6d2e67e8e81b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/bbe7ed89-5bd2-4ddf-ae88-6d2e67e8e81b=
%40isocpp.org</a>.<br />

------=_Part_59_1300184817.1470268667950--

------=_Part_58_1887455408.1470268667949--

.


Author: "D. B." <db0451@gmail.com>
Date: Thu, 4 Aug 2016 09:49:30 +0100
Raw View
--001a1142c65643df5505393b07d1
Content-Type: text/plain; charset=UTF-8

On Wed, Aug 3, 2016 at 10:04 PM, Thiago Macieira <thiago@macieira.org>
wrote:

> On quarta-feira, 3 de agosto de 2016 14:37:14 PDT Viacheslav Usov wrote:
> > void foo(A *this) { x = 1; }
> >
> > is equivalent to
> >
> > void foo(A *ptr) { ptr->x = 1; }
>
> Understood, but is this the only benefit? Is it worth the hassle for
> saving a
> few keystrokes?
>
> Also note that it's not a member function, so it can't access protecteds
> and
> privates of the object.
>

Agreed on both counts. Especially the latter, which hadn't occurred to me
yet - but I think is just another of the inconsistencies/ambiguities I
alluded to between 'this as object' and 'this as shortcut'. Whether or not
other refinements were made to resolve all of those, I think it's
guaranteed that a lot of people would end up confused...

--
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/CACGiwhEAN4R2xE9g84xk6KKDB76%2BPpLFUt_Af6aKhDpAMf8Lqw%40mail.gmail.com.

--001a1142c65643df5505393b07d1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Aug 3, 2016 at 10:04 PM, Thiago Macieira <span dir=3D"ltr">&lt;<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On quar=
ta-feira, 3 de agosto de 2016 14:37:14 PDT Viacheslav Usov wrote:<br>
&gt; void foo(A *this) { x =3D 1; }<br>
&gt;<br>
&gt; is equivalent to<br>
&gt;<br>
&gt; void foo(A *ptr) { ptr-&gt;x =3D 1; }<br>
<br>
</span>Understood, but is this the only benefit? Is it worth the hassle for=
 saving a<br>
few keystrokes?<br>
<br>
Also note that it&#39;s not a member function, so it can&#39;t access prote=
cteds and<br>
privates of the object.<br></blockquote><div><br></div><div>Agreed on both =
counts. Especially the latter, which hadn&#39;t occurred to me yet - but I =
think is just another of the inconsistencies/ambiguities I alluded to betwe=
en &#39;this as object&#39; and &#39;this as shortcut&#39;. Whether or not =
other refinements were made to resolve all of those, I think it&#39;s guara=
nteed that a lot of people would end up confused...<br><br></div></div></di=
v></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/CACGiwhEAN4R2xE9g84xk6KKDB76%2BPpLFUt=
_Af6aKhDpAMf8Lqw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhEAN4R2xE=
9g84xk6KKDB76%2BPpLFUt_Af6aKhDpAMf8Lqw%40mail.gmail.com</a>.<br />

--001a1142c65643df5505393b07d1--

.


Author: Bo Persson <bop@gmb.dk>
Date: Thu, 4 Aug 2016 11:14:50 +0200
Raw View
On 2016-08-04 10:49, D. B. wrote:
> On Wed, Aug 3, 2016 at 10:04 PM, Thiago Macieira <thiago@macieira.org
> <mailto:thiago@macieira.org>> wrote:
>
>     On quarta-feira, 3 de agosto de 2016 14:37:14 PDT Viacheslav Usov wrote:
>     > void foo(A *this) { x = 1; }
>     >
>     > is equivalent to
>     >
>     > void foo(A *ptr) { ptr->x = 1; }
>
>     Understood, but is this the only benefit? Is it worth the hassle for
>     saving a
>     few keystrokes?
>
>     Also note that it's not a member function, so it can't access
>     protecteds and
>     privates of the object.
>
>
> Agreed on both counts. Especially the latter, which hadn't occurred to
> me yet - but I think is just another of the inconsistencies/ambiguities
> I alluded to between 'this as object' and 'this as shortcut'. Whether or
> not other refinements were made to resolve all of those, I think it's
> guaranteed that a lot of people would end up confused...
>

Yes, I would definitely be confused by the sublety of the parameter name.

int   x;

void foo(A* this) { x = 1; }   // x is A::x

void foo(B* that) { x = 1; }   // which x is it now?

void foo(C* htis) { x = 1; }   // typo or intentional?



     Bo Persson



--
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/nnv12b%24okq%241%40blaine.gmane.org.

.


Author: Viacheslav Usov <via.usov@gmail.com>
Date: Thu, 4 Aug 2016 12:26:33 +0200
Raw View
--001a114102425961d705393c6255
Content-Type: text/plain; charset=UTF-8

On Thu, Aug 4, 2016 at 11:14 AM, Bo Persson <bop@gmb.dk> wrote:

> Yes, I would definitely be confused by the sublety of the parameter name.

I hope everybody has read the original message in the thread.

As a reminder, this is not only about parameters, and the public-only
binding was mentioned there. The confusion that can arise because of the
public-only binding ("first kind") and because of misspelled identifiers
("second kind") is not something new that this proposal would introduce.
The first kind is present, for example, in this:

struct A
{
    int x;
private:
    int y;
};

struct B: A
{
    void foo()
    {
        x = 1; // OK
        y = 2; // error
    }
};

The second kind is always just around the corner in any C++ program.

int she;
struct foo
{
    int he;
    void bar() { she = 1; } // really?
];

Cheers,
V.

--
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/CAA7YVg3jtYJ8JdLqqvN1eGx0L21Bef2J-atc0_ufUwKxtsiVSQ%40mail.gmail.com.

--001a114102425961d705393c6255
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Aug 4, 2016 at 11:14 AM, Bo Persson <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:bop@gmb.dk" target=3D"_blank">bop@gmb.dk</a>&gt;</span> wrote:</div><d=
iv class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">&gt; Yes, I w=
ould definitely be confused by the sublety of the parameter name.</div><div=
 class=3D"gmail_quote"><div><br></div><div>I hope everybody has read the or=
iginal message in the thread.</div><div><br></div><div>As a reminder, this =
is not only about parameters, and the public-only binding was mentioned the=
re. The confusion that can arise because of the public-only binding (&quot;=
first kind&quot;) and because of misspelled identifiers (&quot;second kind&=
quot;) is not something new that this proposal would introduce. The first k=
ind is present, for example, in this:</div><div><br></div><div>struct A</di=
v><div>{</div><div>=C2=A0 =C2=A0 int x;</div><div>private:</div><div>=C2=A0=
 =C2=A0 int y;</div><div>};</div><div><br></div><div>struct B: A</div><div>=
{</div><div>=C2=A0 =C2=A0 void foo()</div><div>=C2=A0 =C2=A0 {</div><div>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 x =3D 1; // OK</div><div>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 y =3D 2; // error</div><div>=C2=A0 =C2=A0 }</div><div>};</div><div><=
br></div><div>The second kind is always just around the corner in any C++ p=
rogram.<br></div><div><br></div><div>int she;<br></div><div>struct foo<br><=
/div><div>{</div><div>=C2=A0 =C2=A0 int he;</div><div>=C2=A0 =C2=A0 void ba=
r() { she =3D 1; } // really?</div><div>];</div><div><br></div><div>Cheers,=
<br></div><div>V.</div><div><br></div></div></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/CAA7YVg3jtYJ8JdLqqvN1eGx0L21Bef2J-atc=
0_ufUwKxtsiVSQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3jtYJ8JdLq=
qvN1eGx0L21Bef2J-atc0_ufUwKxtsiVSQ%40mail.gmail.com</a>.<br />

--001a114102425961d705393c6255--

.


Author: Viacheslav Usov <via.usov@gmail.com>
Date: Thu, 4 Aug 2016 12:49:38 +0200
Raw View
--001a114187e8e62e2405393cb42a
Content-Type: text/plain; charset=UTF-8

On Wed, Aug 3, 2016 at 11:04 PM, Thiago Macieira <thiago@macieira.org>
wrote:

> Understood, but is this the only benefit? Is it worth the hassle for
saving a few keystrokes?

Well, given that -> in C is just a way to save TWO keystrokes, always
saving at least THREE might be worth it :)

Another benefit of that would be better compatibility with C, where this is
not a keyword. In some way, this could be seen as a demotion of 'this' from
its current keyword status.

In principle, we could generalise this even further.

1. Specify that any non-static member-function has an implicitly declared
const pointer named this. So 'this' is no longer a keyword.

2. Specify that any scope can have an implicit binding pointer, which
defaults to 'this' (when it is available), and provide a way to override
the choice of the name for it, for example with a 'bind' attribute.

For example::

struct A {int x} *ptr;
[[bind(ptr)]] { x = 1; } // means ptr->x = 1

Cheers,
V.

P.S. The attribute's name could also be 'with', for you VB lovers :) Even
though, I think, it really originated in Pascal.

--
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/CAA7YVg1P-mg_pmGwLEpGopuzuDBmcdQ4wv4jYOKo7xyGdxW81g%40mail.gmail.com.

--001a114187e8e62e2405393cb42a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Aug 3, 2016 at 11:04 PM, Thiago Macieira <span dir=3D"ltr">&lt;<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span> wrote:<br><div><br></div><div>&gt; Understood, but is this the on=
ly benefit? Is it worth the hassle for saving a few keystrokes?</div><div><=
br></div><div>Well, given that -&gt; in C is just a way to save TWO keystro=
kes, always saving at least THREE might be worth it :)</div><div><br></div>=
<div>Another benefit of that would be better compatibility with C, where th=
is is not a keyword. In some way, this could be seen as a demotion of &#39;=
this&#39; from its current keyword status.</div><div><br></div><div>In prin=
ciple, we could generalise this even further.</div><div><br></div><div>1. S=
pecify that any non-static member-function has an implicitly declared const=
 pointer named this. So &#39;this&#39; is no longer a keyword.</div><div><b=
r></div><div>2. Specify that any scope can have an implicit binding pointer=
, which defaults to &#39;this&#39; (when it is available), and provide a wa=
y to override the choice of the name for it, for example with a &#39;bind&#=
39; attribute.</div><div><br></div><div>For example::</div><div><br></div><=
div>struct A {int x} *ptr;</div><div>[[bind(ptr)]] { x =3D 1; } // means pt=
r-&gt;x =3D 1</div><div><br></div><div>Cheers,</div><div>V.</div><div><br><=
/div><div>P.S. The attribute&#39;s name could also be &#39;with&#39;, for y=
ou VB lovers :) Even though, I think, it really originated in Pascal.</div>=
<div><br></div></div></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/CAA7YVg1P-mg_pmGwLEpGopuzuDBmcdQ4wv4j=
YOKo7xyGdxW81g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg1P-mg_pmGw=
LEpGopuzuDBmcdQ4wv4jYOKo7xyGdxW81g%40mail.gmail.com</a>.<br />

--001a114187e8e62e2405393cb42a--

.


Author: Viacheslav Usov <via.usov@gmail.com>
Date: Thu, 4 Aug 2016 12:53:55 +0200
Raw View
--001a114187e835f90905393cc410
Content-Type: text/plain; charset=UTF-8

On Thu, Aug 4, 2016 at 12:49 PM, Viacheslav Usov <via.usov@gmail.com> wrote:

> [[bind(ptr)]] { x = 1; } // means ptr->x = 1

We could also specify that [[bind()]] removes any implicit binding, so then
even the implicit this in member bodies would need to be spelled out.

As was stated in this thread, the implicit 'this' sometimes is confusing,
so inhibiting it might be useful.

Cheers,
V.

--
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/CAA7YVg2xL34rB8AgN7oLLM_y86XvOrtHue5tG_fZTOjo9doNRg%40mail.gmail.com.

--001a114187e835f90905393cc410
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Aug 4, 2016 at 12:49 PM, Viacheslav Usov <span dir=3D"ltr">&lt;<a href=
=3D"mailto:via.usov@gmail.com" target=3D"_blank">via.usov@gmail.com</a>&gt;=
</span> wrote:<br><div><br></div><div>&gt; [[bind(ptr)]] { x =3D 1; } // me=
ans ptr-&gt;x =3D 1</div><div><br></div><div>We could also specify that [[b=
ind()]] removes any implicit binding, so then even the implicit this in mem=
ber bodies would need to be spelled out.</div><div><br></div><div>As was st=
ated in this thread, the implicit &#39;this&#39; sometimes is confusing, so=
 inhibiting it might be useful.</div><div><br></div><div>Cheers,</div><div>=
V.</div></div></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/CAA7YVg2xL34rB8AgN7oLLM_y86XvOrtHue5t=
G_fZTOjo9doNRg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2xL34rB8Ag=
N7oLLM_y86XvOrtHue5tG_fZTOjo9doNRg%40mail.gmail.com</a>.<br />

--001a114187e835f90905393cc410--

.


Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 04 Aug 2016 11:27:35 -0700
Raw View
On quinta-feira, 4 de agosto de 2016 11:14:50 PDT Bo Persson wrote:
> int   x;
>
> void foo(A* this) { x = 1; }   // x is A::x
>
> void foo(B* that) { x = 1; }   // which x is it now?
>
> void foo(C* htis) { x = 1; }   // typo or intentional?

Well, that's not much different from:

struct S {
 void foo();
 int x;
};
int x;

void foo() { x = 1; }  // forgot "Foo::" ?

I've done this before.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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/1827570.ihu56iqjeZ%40tjmaciei-mobl1.

.


Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 04 Aug 2016 11:35:54 -0700
Raw View
On quinta-feira, 4 de agosto de 2016 12:49:38 PDT Viacheslav Usov wrote:
> On Wed, Aug 3, 2016 at 11:04 PM, Thiago Macieira <thiago@macieira.org>
>
> wrote:
> > Understood, but is this the only benefit? Is it worth the hassle for
>
> saving a few keystrokes?
>
> Well, given that -> in C is just a way to save TWO keystrokes, always
> saving at least THREE might be worth it :)

Sorry, I don't buy it. It's not about a few keystrokes, but about the whole
readability of the statement. With it:

 foo->bar->baz->value = 1;

without it:

 (*(*(*(*foo).bar).baz).value = 1;

In Pascal, it would have been:

 foo^.bar^.baz^.value = 1;

> Another benefit of that would be better compatibility with C, where this is
> not a keyword. In some way, this could be seen as a demotion of 'this' from
> its current keyword status.

That's an interesting concept, but unless we also allow class, new and delete
as identifiers, you're not restoring much compatiblity. In particular, "class"
and "new" are used far more often, because of "new" / "old" pair and the term
"class" appearing in many a specification, like USB.

> In principle, we could generalise this even further.
>
> 1. Specify that any non-static member-function has an implicitly declared
> const pointer named this. So 'this' is no longer a keyword.
>
> 2. Specify that any scope can have an implicit binding pointer, which
> defaults to 'this' (when it is available), and provide a way to override
> the choice of the name for it, for example with a 'bind' attribute.
>
> For example::
>
> struct A {int x} *ptr;
> [[bind(ptr)]] { x = 1; } // means ptr->x = 1

Attributes are not allowed to change the syntax of the program. If you drop
them, the code must be as well-formed as it was before. So this is suggestion
above is definitely a no-go.

If you want that, we have to have a new keyword.

PS: anyone noticed that there's the parentheses aren't balanced in my "without
it" example?

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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/4866840.PQO7Sghe0W%40tjmaciei-mobl1.

.


Author: szollosi.lorand@gmail.com
Date: Thu, 4 Aug 2016 11:42:34 -0700 (PDT)
Raw View
------=_Part_1232_269352374.1470336154338
Content-Type: multipart/alternative;
 boundary="----=_Part_1233_1712236459.1470336154338"

------=_Part_1233_1712236459.1470336154338
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

If you're sure you want this, I'd suggest an alternative syntax:

void foo(S* s)
{
    using class S *s; // similarly to using namespace, using fn, but=20
passing object
    x =3D 1; // same as s->x;
}

This allows you wonderful ambiguities (using two classes).

Thanks,
-lorro

2016. augusztus 4., cs=C3=BCt=C3=B6rt=C3=B6k 20:27:39 UTC+2 id=C5=91pontban=
 Thiago Macieira a=20
k=C3=B6vetkez=C5=91t =C3=ADrta:
>
> On quinta-feira, 4 de agosto de 2016 11:14:50 PDT Bo Persson wrote:=20
> > int   x;=20
> >=20
> > void foo(A* this) { x =3D 1; }   // x is A::x=20
> >=20
> > void foo(B* that) { x =3D 1; }   // which x is it now?=20
> >=20
> > void foo(C* htis) { x =3D 1; }   // typo or intentional?=20
>
> Well, that's not much different from:=20
>
> struct S {=20
>         void foo();=20
>         int x;=20
> };=20
> int x;=20
>
> void foo() { x =3D 1; }                // forgot "Foo::" ?=20
>
> I've done this before.=20
>
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
>    Software Architect - Intel Open Source Technology Center=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/433a30d7-f5e5-4183-a7b7-089f5e72fa80%40isocpp.or=
g.

------=_Part_1233_1712236459.1470336154338
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<br><br>If you&#39;re sure you want this, I&#39;d sugge=
st an alternative syntax:<br><br>void foo(S* s)<br>{<br>=C2=A0=C2=A0=C2=A0 =
using class S *s; // similarly to using namespace, using fn, but passing ob=
ject<br>=C2=A0=C2=A0=C2=A0 x =3D 1; // same as s-&gt;x;<br>}<br><br>This al=
lows you wonderful ambiguities (using two classes).<br><br>Thanks,<br>-lorr=
o<br><br>2016. augusztus 4., cs=C3=BCt=C3=B6rt=C3=B6k 20:27:39 UTC+2 id=C5=
=91pontban Thiago Macieira a k=C3=B6vetkez=C5=91t =C3=ADrta:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;">On quinta-feira, 4 de agosto de 2016 11:14:50=
 PDT Bo Persson wrote:
<br>&gt; int =C2=A0 x;
<br>&gt;=20
<br>&gt; void foo(A* this) { x =3D 1; } =C2=A0 // x is A::x
<br>&gt;=20
<br>&gt; void foo(B* that) { x =3D 1; } =C2=A0 // which x is it now?
<br>&gt;=20
<br>&gt; void foo(C* htis) { x =3D 1; } =C2=A0 // typo or intentional?
<br>
<br>Well, that&#39;s not much different from:
<br>
<br>struct S {
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0void foo();
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0int x;
<br>};
<br>int x;
<br>
<br>void foo() { x =3D 1; }=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0// forgot &quot;Foo::&quot;=
 ?
<br>
<br>I&#39;ve done this before.
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return t=
rue;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
GRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;" onclick=3D"this.href=3D&#39;=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;">kde.org</a=
>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br></blockquote></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/433a30d7-f5e5-4183-a7b7-089f5e72fa80%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/433a30d7-f5e5-4183-a7b7-089f5e72fa80=
%40isocpp.org</a>.<br />

------=_Part_1233_1712236459.1470336154338--

------=_Part_1232_269352374.1470336154338--

.


Author: "D. B." <db0451@gmail.com>
Date: Thu, 4 Aug 2016 20:05:08 +0100
Raw View
--001a1142c656f5d8b5053943a08a
Content-Type: text/plain; charset=UTF-8

On Thu, Aug 4, 2016 at 7:42 PM, <szollosi.lorand@gmail.com> wrote:

> Hi,
>
> If you're sure you want this, I'd suggest an alternative syntax:
>
> void foo(S* s)
> {
>     using class S *s; // similarly to using namespace, using fn, but
> passing object
>     x = 1; // same as s->x;
> }
>
> This allows you wonderful ambiguities (using two classes).
>
> Thanks,
> -lorro
>
>
Interesting. It seems this could be done with *using auto s;* or some other
keyword to indicate you want a variable (not a namespace or func), rather
than always having to specify the class. Nor does it seem to depend on
scope or function signature. It could be totally generalised.

This seems most like the *With* keyword I mentioned, but I dunno why I
didn't think of using *using* for that, as it's so obvious now :)

It would lead to lots of hilarious ambiguities, but then do did *With*, so
it fills that role nicely ;) and would be strictly opt-in and statically
checkable I think, so while having potential for confusion, I don't think
would hurt much.

I like this far more than the idea of hijacking *this*

--
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/CACGiwhEpw8ANU%3D-2bW%2BRB7oGC%2BT2dMFJwTwMW9ODG_RqTb0rVw%40mail.gmail.com.

--001a1142c656f5d8b5053943a08a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Thu, Aug 4, 2016 at 7:42 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:szollosi.lorand@gmail.com" target=3D"_blank">szollosi.lorand@gmail.com</a=
>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><d=
iv dir=3D"ltr">Hi,<br><br>If you&#39;re sure you want this, I&#39;d suggest=
 an alternative syntax:<br><br>void foo(S* s)<br>{<br>=C2=A0=C2=A0=C2=A0 us=
ing class S *s; // similarly to using namespace, using fn, but passing obje=
ct<br>=C2=A0=C2=A0=C2=A0 x =3D 1; // same as s-&gt;x;<br>}<br><br>This allo=
ws you wonderful ambiguities (using two classes).<br><br>Thanks,<br>-lorro<=
br><span class=3D""></span><br></div></blockquote><div><br></div><div>Inter=
esting. It seems this could be done with <i>using auto s;</i> or some other=
 keyword to indicate you want a variable (not a namespace or func), rather =
than always having to specify the class. Nor does it seem to depend on scop=
e or function signature. It could be totally generalised.<br><br></div><div=
>This seems most like the <i>With</i> keyword I mentioned, but I dunno why =
I didn&#39;t think of using <i>using</i> for that, as it&#39;s so obvious n=
ow :)<br><br></div><div>It would lead to lots of hilarious ambiguities, but=
 then do did <i>With</i>, so it fills that role nicely ;) and would be stri=
ctly opt-in and statically checkable I think, so while having potential for=
 confusion, I don&#39;t think would hurt much.<br><br></div><div>I like thi=
s far more than the idea of hijacking <i>this</i><br></div><div>=C2=A0<br><=
/div></div></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/CACGiwhEpw8ANU%3D-2bW%2BRB7oGC%2BT2dM=
FJwTwMW9ODG_RqTb0rVw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhEpw8=
ANU%3D-2bW%2BRB7oGC%2BT2dMFJwTwMW9ODG_RqTb0rVw%40mail.gmail.com</a>.<br />

--001a1142c656f5d8b5053943a08a--

.


Author: Viacheslav Usov <via.usov@gmail.com>
Date: Fri, 5 Aug 2016 12:14:07 +0200
Raw View
--001a11401266bb0eb2053950532c
Content-Type: text/plain; charset=UTF-8

On Thu, Aug 4, 2016 at 8:35 PM, Thiago Macieira <thiago@macieira.org> wrote:


> Sorry, I don't buy it. It's not about a few keystrokes, but about the whole
> readability of the statement. With it:
>
>         foo->bar->baz->value = 1;
>
> without it:
>
>         (*(*(*(*foo).bar).baz).value = 1;
>

I was not entirely serious when I wrote that part of the message, but since
you took that seriously, then I will say that I do not buy your explanation
either.

First, the verbose syntax looks weird only because it is not commonly used.
If it were the norm, it would not look so weird.

Second, how frequently does one have an expression with FOUR levels of
indirection? Even two levels are quite rare.

Grepping through a bunch of libraries that I use in a particular project, I
find 714 lines that use double and higher-order indirection with ->, of
which about one half comes from the test code in a C++ MongoDB driver, in a
form very remarkably relevant for this discussion:

this->c->insert(TEST_NS, BSON("a" << 1));

Another big chunk comes from the Paho MQTT library, and there is much less
in OpenSSL and Lua. Boost has none at all.

Grepping for triple indirection with ->, I get no matches at all in that
set of libraries.

So, in most practical cases, we would just have to write (*foo).bar instead
of foo->bar.

> Attributes are not allowed to change the syntax of the program.

Right. Thinking more about it, and taking the cue from another message in
this thread, 'using' seems to be a natural choice to introduce implicit
binding, so I propose the following:

1. "using this = expr" makes the specified expression the this pointer for
the rest of the enclosing scope.

2. "using this = explicit" or perhaps "using explicit this" disallows the
implicit this-> substitution for the rest of enclosing block.

These two forms can override each other. I further suggest that at least
the second form should be specifiable in any scope, including the file
scope, even if there is no this pointer in that scope, so that such
policies could be easily set globally.

Cheers,
V.

--
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/CAA7YVg3U_WUMmQP%3DjfH-KOdLZB0ALoXUmKcCmw35xWnn59m97g%40mail.gmail.com.

--001a11401266bb0eb2053950532c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Aug 4, 2016 at 8:35 PM, Thiago Macieira <span dir=3D"ltr">&lt;<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span> wrote:<br><div>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid=
;border-left-color:rgb(204,204,204);padding-left:1ex">Sorry, I don&#39;t bu=
y it. It&#39;s not about a few keystrokes, but about the whole<br>
readability of the statement. With it:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 foo-&gt;bar-&gt;baz-&gt;value =3D 1;<br>
<br>
without it:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (*(*(*(*foo).bar).baz).value =3D 1;<br></blockq=
uote><div><br></div><div>I was not entirely serious when I wrote that part =
of the message, but since you took that seriously, then I will say that I d=
o not buy your explanation either.</div><div><br></div><div>First, the verb=
ose syntax looks weird only because it is not commonly used. If it were the=
 norm, it would not look so weird.</div><div><br></div><div>Second, how fre=
quently does one have an expression with FOUR levels of indirection? Even t=
wo levels are quite rare.</div><div><br></div><div>Grepping through a bunch=
 of libraries that I use in a particular project, I find 714 lines that use=
 double and higher-order indirection with -&gt;, of which about one half co=
mes from the test code in a C++ MongoDB driver, in a form very remarkably r=
elevant for this discussion:</div><div><br></div><div>this-&gt;c-&gt;insert=
(TEST_NS, BSON(&quot;a&quot; &lt;&lt; 1));<br></div><div><br></div><div>Ano=
ther big chunk comes from the Paho MQTT library, and there is much less in =
OpenSSL and Lua. Boost has none at all.</div><div><br></div><div>Grepping f=
or triple indirection with -&gt;, I get no matches at all in that set of li=
braries.</div><div><br></div><div>So, in most practical cases, we would jus=
t have to write (*foo).bar instead of foo-&gt;bar.</div><div><br></div><div=
>&gt; Attributes are not allowed to change the syntax of the program.</div>=
<div><br></div><div>Right. Thinking more about it, and taking the cue from =
another message in this thread, &#39;using&#39; seems to be a natural choic=
e to introduce implicit binding, so I propose the following:</div><div><br>=
</div><div>1. &quot;using this =3D expr&quot; makes the specified expressio=
n the this pointer for the rest of the enclosing scope.</div><div><br></div=
><div>2. &quot;using this =3D explicit&quot; or perhaps &quot;using explici=
t this&quot; disallows the implicit this-&gt; substitution for the rest of =
enclosing block.</div><div><br></div><div>These two forms can override each=
 other. I further suggest that at least the second form should be specifiab=
le in any scope, including the file scope, even if there is no this pointer=
 in that scope, so that such policies could be easily set globally.</div><d=
iv><br></div><div>Cheers,</div><div>V.</div></div></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/CAA7YVg3U_WUMmQP%3DjfH-KOdLZB0ALoXUmK=
cCmw35xWnn59m97g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3U_WUMmQ=
P%3DjfH-KOdLZB0ALoXUmKcCmw35xWnn59m97g%40mail.gmail.com</a>.<br />

--001a11401266bb0eb2053950532c--

.


Author: "D. B." <db0451@gmail.com>
Date: Fri, 5 Aug 2016 11:18:47 +0100
Raw View
--001a11443eac6588b505395064b0
Content-Type: text/plain; charset=UTF-8

On Fri, Aug 5, 2016 at 11:14 AM, Viacheslav Usov <via.usov@gmail.com> wrote:

> Thinking more about it, and taking the cue from another message in this
> thread, 'using' seems to be a natural choice to introduce implicit binding,
> so I propose the following:
>
> 1. "using this = expr" makes the specified expression the this pointer for
> the rest of the enclosing scope.
>
> 2. "using this = explicit" or perhaps "using explicit this" disallows the
> implicit this-> substitution for the rest of enclosing block.
>

fwiw I'll reiterate that I really dislike the idea of hijacking *this*.

But also, *using* seems to make it redundant anyway. Just as one would
write *using namespace std;*, it would seem that we could also write *using
auto someObj;*, where *auto* means 'I want a variable, not a namespace or
anything else', and this would mean that *someObj*'s class would be added
to implicit name resolution. A la *With someObj* from VB.

That would mean we could get the same name lookup behaviour as *this*,
without muddying the waters of its actual meaning, which is 'give me the
object upon which this method/lambda is being invoked'.

It also doesn't seem to depend on being in scope of a function where the
*someObj* was passed as a pointer parameter, which can only be an
improvement.

--
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/CACGiwhHWtr1b-_atUGHk1_MVSzimbJotFWc9iVJn%3D2pUQs8Ztw%40mail.gmail.com.

--001a11443eac6588b505395064b0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Aug 5, 2016 at 11:14 AM, Viacheslav Usov <span dir=3D"ltr">&lt;<a href=
=3D"mailto:via.usov@gmail.com" target=3D"_blank">via.usov@gmail.com</a>&gt;=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div clas=
s=3D"gmail_extra">Thinking more about it, and taking the cue from another m=
essage in this thread, &#39;using&#39; seems to be a natural choice to intr=
oduce implicit binding, so I propose the following:<div class=3D"gmail_quot=
e"><div><br></div><div>1. &quot;using this =3D expr&quot; makes the specifi=
ed expression the this pointer for the rest of the enclosing scope.</div><d=
iv><br></div><div>2. &quot;using this =3D explicit&quot; or perhaps &quot;u=
sing explicit this&quot; disallows the implicit this-&gt; substitution for =
the rest of enclosing block.</div></div></div></div></blockquote><div><br><=
/div><div>fwiw I&#39;ll reiterate that I really dislike the idea of hijacki=
ng <i>this</i>.<br><br>But also, <i>using</i> seems to make it redundant an=
yway. Just as one would write <i>using namespace std;</i>, it would seem th=
at we could also write <i>using auto someObj;</i>, where <i>auto</i> means =
&#39;I want a variable, not a namespace or anything else&#39;, and this wou=
ld mean that <i>someObj</i>&#39;s class would be added to implicit name res=
olution. A la <i>With someObj</i> from VB.<br><br></div><div>That would mea=
n we could get the same name lookup behaviour as <i>this</i>, without muddy=
ing the waters of its actual meaning, which is &#39;give me the object upon=
 which this method/lambda is being invoked&#39;.<br><br></div><div>It also =
doesn&#39;t seem to depend on being in scope of a function where the <i>som=
eObj</i> was passed as a pointer parameter, which can only be an improvemen=
t.<br></div><div><br><br></div></div></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/CACGiwhHWtr1b-_atUGHk1_MVSzimbJotFWc9=
iVJn%3D2pUQs8Ztw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhHWtr1b-_=
atUGHk1_MVSzimbJotFWc9iVJn%3D2pUQs8Ztw%40mail.gmail.com</a>.<br />

--001a11443eac6588b505395064b0--

.


Author: Viacheslav Usov <via.usov@gmail.com>
Date: Fri, 5 Aug 2016 12:55:36 +0200
Raw View
--001a114187e820b735053950e8af
Content-Type: text/plain; charset=UTF-8

On Fri, Aug 5, 2016 at 12:18 PM, D. B. <db0451@gmail.com> wrote:

> But also, *using* seems to make it redundant anyway. Just as one would
write *using namespace std;*, it would seem that we could also write *using
auto someObj;*, where *auto* means 'I want a variable, not a namespace or
anything else', and this would mean that *someObj*'s class would be added
to implicit name resolution. A la *With someObj* from VB.

What you are really saying is that you prefer the syntax "using auto
someObj" over "using this = someObj".

However, I prefer the latter, and I proposed it after I considered the
former. Why I prefer the latter:

1. It is more general, because it can bind to an expression, not just a
variable.

2. It is less confusing, because at any given location in the code there
can be exactly ONE this pointer. What does "add" in the description above
really mean? Does that mean there can be multiple additional pointers used
for name resolution? That sounds like a great idea, but it has far more
nuances than in the "single this" paradigm, which are yet to be defined by
you (think ambiguous resolution and ways to deal with it). Note that "with"
in VB only works with one object, and nested "with" statements override the
current implicit object, rather than "add" more objects to name resolution.
If your "add" really means "override whatever is used implicitly now", then
it is strictly less powerful than my syntax, AND its form still suggests
"add" rather than "override", because that's how it works with namespaces.

3. You still need some other syntax to say "no implicit this", or, with a
true "add" semantics, "no implicit X"

Cheers,
V.

--
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/CAA7YVg2ogjB%2BQUxPaeNLWROpdJuc0Gy%3DEC10eNuA6Rs4NkieAA%40mail.gmail.com.

--001a114187e820b735053950e8af
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Aug 5, 2016 at 12:18 PM, D. B. <span dir=3D"ltr">&lt;<a href=3D"mailto:=
db0451@gmail.com" target=3D"_blank">db0451@gmail.com</a>&gt;</span> wrote:<=
br><div><br></div><div>&gt; But also, <i>using</i> seems to make it redunda=
nt anyway. Just as one would write <i>using namespace std;</i>, it would se=
em that we could also write <i>using auto someObj;</i>, where <i>auto</i> m=
eans &#39;I want a variable, not a namespace or anything else&#39;, and thi=
s would mean that <i>someObj</i>&#39;s class would be added to implicit nam=
e resolution. A la <i>With someObj</i> from VB.</div><div><br></div><div>Wh=
at you are really saying is that you prefer the syntax &quot;using auto som=
eObj&quot; over &quot;using this =3D someObj&quot;.</div><div><br></div><di=
v>However, I prefer the latter, and I proposed it after I considered the fo=
rmer. Why I prefer the latter:</div><div><br></div><div>1. It is more gener=
al, because it can bind to an expression, not just a variable.</div><div><b=
r></div><div>2. It is less confusing, because at any given location in the =
code there can be exactly ONE this pointer. What does &quot;add&quot; in th=
e description above really mean? Does that mean there can be multiple addit=
ional pointers used for name resolution? That sounds like a great idea, but=
 it has far more nuances than in the &quot;single this&quot; paradigm, whic=
h are yet to be defined by you (think ambiguous resolution and ways to deal=
 with it). Note that &quot;with&quot; in VB only works with one object, and=
 nested &quot;with&quot; statements override the current implicit object, r=
ather than &quot;add&quot; more objects to name resolution. If your &quot;a=
dd&quot; really means &quot;override whatever is used implicitly now&quot;,=
 then it is strictly less powerful than my syntax, AND its form still sugge=
sts &quot;add&quot; rather than &quot;override&quot;, because that&#39;s ho=
w it works with namespaces.</div><div><br></div><div>3. You still need some=
 other syntax to say &quot;no implicit this&quot;, or, with a true &quot;ad=
d&quot; semantics, &quot;no implicit X&quot;</div><div><br></div><div>Cheer=
s,</div><div>V.</div></div></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/CAA7YVg2ogjB%2BQUxPaeNLWROpdJuc0Gy%3D=
EC10eNuA6Rs4NkieAA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2ogjB%=
2BQUxPaeNLWROpdJuc0Gy%3DEC10eNuA6Rs4NkieAA%40mail.gmail.com</a>.<br />

--001a114187e820b735053950e8af--

.


Author: inkwizytoryankes@gmail.com
Date: Fri, 5 Aug 2016 10:17:09 -0700 (PDT)
Raw View
------=_Part_760_514272996.1470417429901
Content-Type: multipart/alternative;
 boundary="----=_Part_761_1231646959.1470417429902"

------=_Part_761_1231646959.1470417429902
Content-Type: text/plain; charset=UTF-8



On Thursday, August 4, 2016 at 12:26:36 PM UTC+2, Viacheslav Usov wrote:
>
> On Thu, Aug 4, 2016 at 11:14 AM, Bo Persson <b...@gmb.dk <javascript:>>
> wrote:
>
> > Yes, I would definitely be confused by the sublety of the parameter name.
>
> I hope everybody has read the original message in the thread.
>
> As a reminder, this is not only about parameters, and the public-only
> binding was mentioned there. The confusion that can arise because of the
> public-only binding ("first kind") and because of misspelled identifiers
> ("second kind") is not something new that this proposal would introduce.
> The first kind is present, for example, in this:
>
> struct A
> {
>     int x;
> private:
>     int y;
> };
>
> struct B: A
> {
>     void foo()
>     {
>         x = 1; // OK
>         y = 2; // error
>     }
> };
>
> The second kind is always just around the corner in any C++ program.
>
> int she;
> struct foo
> {
>     int he;
>     void bar() { she = 1; } // really?
> ];
>
> Cheers,
> V.
>
>

And what about templates?
template<typename T>
void f(T* this)
{
    a = 6;
};
What meaning have this code? `a` is member or global value?
Because member `a` is dependent name compiler need always ignore it and go
for global with same name.
This made this proposition unusable in template contexts.


--
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/814750ea-1ef8-4792-9b50-aec0bae4d841%40isocpp.org.

------=_Part_761_1231646959.1470417429902
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, August 4, 2016 at 12:26:36 PM UTC+2, =
Viacheslav Usov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote">On Thu, Aug 4, 2016 at 11:14 AM, B=
o Persson <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" g=
df-obfuscated-mailto=3D"Tr06WUaLBwAJ" rel=3D"nofollow" onmousedown=3D"this.=
href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;java=
script:&#39;;return true;">b...@gmb.dk</a>&gt;</span> wrote:</div><div clas=
s=3D"gmail_quote"><br></div><div class=3D"gmail_quote">&gt; Yes, I would de=
finitely be confused by the sublety of the parameter name.</div><div class=
=3D"gmail_quote"><div><br></div><div>I hope everybody has read the original=
 message in the thread.</div><div><br></div><div>As a reminder, this is not=
 only about parameters, and the public-only binding was mentioned there. Th=
e confusion that can arise because of the public-only binding (&quot;first =
kind&quot;) and because of misspelled identifiers (&quot;second kind&quot;)=
 is not something new that this proposal would introduce. The first kind is=
 present, for example, in this:</div><div><br></div><div>struct A</div><div=
>{</div><div>=C2=A0 =C2=A0 int x;</div><div>private:</div><div>=C2=A0 =C2=
=A0 int y;</div><div>};</div><div><br></div><div>struct B: A</div><div>{</d=
iv><div>=C2=A0 =C2=A0 void foo()</div><div>=C2=A0 =C2=A0 {</div><div>=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 x =3D 1; // OK</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
y =3D 2; // error</div><div>=C2=A0 =C2=A0 }</div><div>};</div><div><br></di=
v><div>The second kind is always just around the corner in any C++ program.=
<br></div><div><br></div><div>int she;<br></div><div>struct foo<br></div><d=
iv>{</div><div>=C2=A0 =C2=A0 int he;</div><div>=C2=A0 =C2=A0 void bar() { s=
he =3D 1; } // really?</div><div>];</div><div><br></div><div>Cheers,<br></d=
iv><div>V.</div><div><br></div></div></div></div></blockquote><div><br><br>=
And what about templates?<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 class=3D"prettypri=
nt"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">template</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">typename</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&=
gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> f</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"colo=
r: #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"> </span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">this</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
></span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =
a </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #066;" class=3D"styled-by-prettify">6</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">};</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br></span></div></code></div>What meaning have this cod=
e? `a` is member or global value?<br>Because member `a` is dependent name c=
ompiler need always ignore it and go for global with same name.<br>This mad=
e this proposition unusable in template contexts.<br>=C2=A0<br></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/814750ea-1ef8-4792-9b50-aec0bae4d841%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/814750ea-1ef8-4792-9b50-aec0bae4d841=
%40isocpp.org</a>.<br />

------=_Part_761_1231646959.1470417429902--

------=_Part_760_514272996.1470417429901--

.


Author: Viacheslav Usov <via.usov@gmail.com>
Date: Fri, 5 Aug 2016 19:51:32 +0200
Raw View
--001a114025cc9c7018053956b745
Content-Type: text/plain; charset=UTF-8

On Fri, Aug 5, 2016 at 7:17 PM, <inkwizytoryankes@gmail.com> wrote:

template<typename T>
> void f(T* this)
> {
>     a = 6;
> };
> What meaning have this code? `a` is member or global value?
> Because member `a` is dependent name compiler need always ignore it and go
> for global with same name.
> This made this proposition unusable in template contexts.
>

When this is instantiated for a particular type T, then, if there is a
member 'a' in that type, it will mean this->a = 6; if there is no such
member, it will refer to 'a' from an outer scope. Note that at this point I
no longer propose that 'this' could be declared as a regular variable.
Instead, I propose the following form:

using this = expression;

Cheers,
V.

--
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/CAA7YVg3HCFXrd-f%2BDuq2nyM4oHkOwWPuXFp4dZUDUB3ocor3gQ%40mail.gmail.com.

--001a114025cc9c7018053956b745
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Aug 5, 2016 at 7:17 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:inkwiz=
ytoryankes@gmail.com" target=3D"_blank">inkwizytoryankes@gmail.com</a>&gt;<=
/span> wrote:</div><div class=3D"gmail_quote"><br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><div><div 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><div><span style=3D"color:#008">template</span><span st=
yle=3D"color:#660">&lt;</span><span style=3D"color:#008">typename</span><sp=
an style=3D"color:#000"> T</span><span style=3D"color:#660">&gt;</span><spa=
n style=3D"color:#000"><br></span><span style=3D"color:#008">void</span><sp=
an style=3D"color:#000"> f</span><span style=3D"color:#660">(</span><span s=
tyle=3D"color:#000">T</span><span style=3D"color:#660">*</span><span style=
=3D"color:#000"> </span><span style=3D"color:#008">this</span><span style=
=3D"color:#660">)</span><span style=3D"color:#000"><br></span><span style=
=3D"color:#660">{</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 a </sp=
an><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </span>=
<span style=3D"color:#066">6</span><span style=3D"color:#660">;</span><span=
 style=3D"color:#000"><br></span><span style=3D"color:#660">};</span><span =
style=3D"color:#000"><br></span></div></code></div>What meaning have this c=
ode? `a` is member or global value?<br>Because member `a` is dependent name=
 compiler need always ignore it and go for global with same name.<br>This m=
ade this proposition unusable in template contexts.</div></div></blockquote=
><div><br></div><div>When this is instantiated for a particular type T, the=
n, if there is a member &#39;a&#39; in that type, it will mean this-&gt;a =
=3D 6; if there is no such member, it will refer to &#39;a&#39; from an out=
er scope. Note that at this point I no longer propose that &#39;this&#39; c=
ould be declared as a regular variable. Instead, I propose the following fo=
rm:</div><div><br></div><div>using this =3D expression;<br></div><div><br><=
/div><div>Cheers,</div><div>V.</div></div></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/CAA7YVg3HCFXrd-f%2BDuq2nyM4oHkOwWPuXF=
p4dZUDUB3ocor3gQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3HCFXrd-=
f%2BDuq2nyM4oHkOwWPuXFp4dZUDUB3ocor3gQ%40mail.gmail.com</a>.<br />

--001a114025cc9c7018053956b745--

.


Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 5 Aug 2016 10:53:16 -0700 (PDT)
Raw View
------=_Part_2280_1148085141.1470419596371
Content-Type: multipart/alternative;
 boundary="----=_Part_2281_1596674207.1470419596371"

------=_Part_2281_1596674207.1470419596371
Content-Type: text/plain; charset=UTF-8

On Friday, August 5, 2016 at 1:17:10 PM UTC-4, inkwizyt...@gmail.com wrote:
>
> On Thursday, August 4, 2016 at 12:26:36 PM UTC+2, Viacheslav Usov wrote:
>>
>> On Thu, Aug 4, 2016 at 11:14 AM, Bo Persson <b...@gmb.dk> wrote:
>>
>> > Yes, I would definitely be confused by the sublety of the parameter
>> name.
>>
>> I hope everybody has read the original message in the thread.
>>
>> As a reminder, this is not only about parameters, and the public-only
>> binding was mentioned there. The confusion that can arise because of the
>> public-only binding ("first kind") and because of misspelled identifiers
>> ("second kind") is not something new that this proposal would introduce.
>> The first kind is present, for example, in this:
>>
>> struct A
>> {
>>     int x;
>> private:
>>     int y;
>> };
>>
>> struct B: A
>> {
>>     void foo()
>>     {
>>         x = 1; // OK
>>         y = 2; // error
>>     }
>> };
>>
>> The second kind is always just around the corner in any C++ program.
>>
>> int she;
>> struct foo
>> {
>>     int he;
>>     void bar() { she = 1; } // really?
>> ];
>>
>> Cheers,
>> V.
>>
>>
>
> And what about templates?
> template<typename T>
> void f(T* this)
> {
>     a = 6;
> };
> What meaning have this code? `a` is member or global value?
>

It would be whatever it would be if `f` were actually a non-static member
of `T`. God only knows how you'd actually define that in the standard
though.

--
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/77b65a95-52c4-4191-8b65-764591aa6b2c%40isocpp.org.

------=_Part_2281_1596674207.1470419596371
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, August 5, 2016 at 1:17:10 PM UTC-4, inkwizyt...=
@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">On Thursday, August 4, 2016 at 12:26:36 PM UTC+2, Viacheslav Usov wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote">On Thu, Aug 4, 2016 at 11:14 AM, Bo Persson <span dir=3D"l=
tr">&lt;<a rel=3D"nofollow">b...@gmb.dk</a>&gt;</span> wrote:</div><div cla=
ss=3D"gmail_quote"><br></div><div class=3D"gmail_quote">&gt; Yes, I would d=
efinitely be confused by the sublety of the parameter name.</div><div class=
=3D"gmail_quote"><div><br></div><div>I hope everybody has read the original=
 message in the thread.</div><div><br></div><div>As a reminder, this is not=
 only about parameters, and the public-only binding was mentioned there. Th=
e confusion that can arise because of the public-only binding (&quot;first =
kind&quot;) and because of misspelled identifiers (&quot;second kind&quot;)=
 is not something new that this proposal would introduce. The first kind is=
 present, for example, in this:</div><div><br></div><div>struct A</div><div=
>{</div><div>=C2=A0 =C2=A0 int x;</div><div>private:</div><div>=C2=A0 =C2=
=A0 int y;</div><div>};</div><div><br></div><div>struct B: A</div><div>{</d=
iv><div>=C2=A0 =C2=A0 void foo()</div><div>=C2=A0 =C2=A0 {</div><div>=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 x =3D 1; // OK</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
y =3D 2; // error</div><div>=C2=A0 =C2=A0 }</div><div>};</div><div><br></di=
v><div>The second kind is always just around the corner in any C++ program.=
<br></div><div><br></div><div>int she;<br></div><div>struct foo<br></div><d=
iv>{</div><div>=C2=A0 =C2=A0 int he;</div><div>=C2=A0 =C2=A0 void bar() { s=
he =3D 1; } // really?</div><div>];</div><div><br></div><div>Cheers,<br></d=
iv><div>V.</div><div><br></div></div></div></div></blockquote><div><br><br>=
And what about templates?<br><div style=3D"background-color:rgb(250,250,250=
);border-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wr=
ap:break-word"><code><div><span style=3D"color:#008">template</span><span s=
tyle=3D"color:#660">&lt;</span><span style=3D"color:#008">typename</span><s=
pan style=3D"color:#000"> T</span><span style=3D"color:#660">&gt;</span><sp=
an style=3D"color:#000"><br></span><span style=3D"color:#008">void</span><s=
pan style=3D"color:#000"> f</span><span style=3D"color:#660">(</span><span =
style=3D"color:#000">T</span><span style=3D"color:#660">*</span><span style=
=3D"color:#000"> </span><span style=3D"color:#008">this</span><span style=
=3D"color:#660">)</span><span style=3D"color:#000"><br></span><span style=
=3D"color:#660">{</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 a </sp=
an><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </span>=
<span style=3D"color:#066">6</span><span style=3D"color:#660">;</span><span=
 style=3D"color:#000"><br></span><span style=3D"color:#660">};</span><span =
style=3D"color:#000"><br></span></div></code></div>What meaning have this c=
ode? `a` is member or global value?<br></div></div></blockquote><div><br>It=
 would be whatever it would be if `f` were actually a non-static member of =
`T`. God only knows how you&#39;d actually define that in the standard thou=
gh.<br></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/77b65a95-52c4-4191-8b65-764591aa6b2c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/77b65a95-52c4-4191-8b65-764591aa6b2c=
%40isocpp.org</a>.<br />

------=_Part_2281_1596674207.1470419596371--

------=_Part_2280_1148085141.1470419596371--

.


Author: inkwizytoryankes@gmail.com
Date: Fri, 5 Aug 2016 11:54:07 -0700 (PDT)
Raw View
------=_Part_2239_1579967262.1470423247672
Content-Type: multipart/alternative;
 boundary="----=_Part_2240_1672624294.1470423247672"

------=_Part_2240_1672624294.1470423247672
Content-Type: text/plain; charset=UTF-8



On Friday, August 5, 2016 at 7:51:37 PM UTC+2, Viacheslav Usov wrote:
>
> On Fri, Aug 5, 2016 at 7:17 PM, <inkwizyt...@gmail.com <javascript:>>
> wrote:
>
> template<typename T>
>> void f(T* this)
>> {
>>     a = 6;
>> };
>> What meaning have this code? `a` is member or global value?
>> Because member `a` is dependent name compiler need always ignore it and
>> go for global with same name.
>> This made this proposition unusable in template contexts.
>>
>
> When this is instantiated for a particular type T, then, if there is a
> member 'a' in that type, it will mean this->a = 6; if there is no such
> member, it will refer to 'a' from an outer scope. Note that at this point I
> no longer propose that 'this' could be declared as a regular variable.
> Instead, I propose the following form:
>
> using this = expression;
>
> Cheers,
> V.
>

But then this will be first time when C++ template quietly change syntax of
code when you instantiating different templates, consider this case:

class a{};
struct t1
{
  void f()
  {
    a* test;
    ++test;
  }
};
struct t2
{
  int a;
  int test;
  void f()
  {
    a* test;
    ++test;
  }
};
`t1::f` and `t2::f` look similar but work completely different. How
compilers will handle cases when every symbol in function can be member
variable?
JavaScript had same problems with `with` and solution was to ban it:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/with


--
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/7938962d-5e90-4e0f-b3f2-4f979d314a70%40isocpp.org.

------=_Part_2240_1672624294.1470423247672
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Friday, August 5, 2016 at 7:51:37 PM UTC+2, Via=
cheslav Usov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div><div class=3D"gmail_quote">On Fri, Aug 5, 2016 at 7:17 PM,  <spa=
n dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-=
mailto=3D"m3_X1SPyBwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;ja=
vascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;r=
eturn true;">inkwizyt...@gmail.com</a>&gt;</span> wrote:</div><div class=3D=
"gmail_quote"><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div=
 style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);b=
order-style:solid;border-width:1px;word-wrap:break-word"><code><div><span s=
tyle=3D"color:#008">template</span><span style=3D"color:#660">&lt;</span><s=
pan style=3D"color:#008">typename</span><span style=3D"color:#000"> T</span=
><span style=3D"color:#660">&gt;</span><span style=3D"color:#000"><br></spa=
n><span style=3D"color:#008">void</span><span style=3D"color:#000"> f</span=
><span style=3D"color:#660">(</span><span style=3D"color:#000">T</span><spa=
n style=3D"color:#660">*</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#008">this</span><span style=3D"color:#660">)</span><span style=
=3D"color:#000"><br></span><span style=3D"color:#660">{</span><span style=
=3D"color:#000"><br>=C2=A0 =C2=A0 a </span><span style=3D"color:#660">=3D</=
span><span style=3D"color:#000"> </span><span style=3D"color:#066">6</span>=
<span style=3D"color:#660">;</span><span style=3D"color:#000"><br></span><s=
pan style=3D"color:#660">};</span><span style=3D"color:#000"><br></span></d=
iv></code></div>What meaning have this code? `a` is member or global value?=
<br>Because member `a` is dependent name compiler need always ignore it and=
 go for global with same name.<br>This made this proposition unusable in te=
mplate contexts.</div></div></blockquote><div><br></div><div>When this is i=
nstantiated for a particular type T, then, if there is a member &#39;a&#39;=
 in that type, it will mean this-&gt;a =3D 6; if there is no such member, i=
t will refer to &#39;a&#39; from an outer scope. Note that at this point I =
no longer propose that &#39;this&#39; could be declared as a regular variab=
le. Instead, I propose the following form:</div><div><br></div><div>using t=
his =3D expression;<br></div><div><br></div><div>Cheers,</div><div>V.</div>=
</div></div></div></blockquote><div><br>But then this will be first time wh=
en C++ template quietly change syntax of code when you instantiating differ=
ent templates, consider this case:<br><div class=3D"prettyprint" style=3D"b=
ackground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bord=
er-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"=
prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">class</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> a</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">{};</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br></span><code class=3D"prettyprint"><span style=3D"color: #008;" class=
=3D"styled-by-prettify">struct</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"></span></code><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">t1<br></span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">voi=
d</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> f</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 a</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">*</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> test</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">++</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">test</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>=C2=A0 </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>};</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">struct</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> t2<br></span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> a</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> test</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br>=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">void</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
f</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 a</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">*</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> test</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">++</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">test</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">};</span></div></code></div>`t1::f` and `t2::f` look similar but =
work completely different. How compilers will handle cases when every symbo=
l in function can be member variable?<br>JavaScript had same problems with =
`with` and solution was to ban it: https://developer.mozilla.org/en-US/docs=
/Web/JavaScript/Reference/Statements/with<br><br><br></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/7938962d-5e90-4e0f-b3f2-4f979d314a70%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7938962d-5e90-4e0f-b3f2-4f979d314a70=
%40isocpp.org</a>.<br />

------=_Part_2240_1672624294.1470423247672--

------=_Part_2239_1579967262.1470423247672--

.


Author: "D. B." <db0451@gmail.com>
Date: Fri, 5 Aug 2016 19:59:06 +0100
Raw View
--001a114b3dac3e7e3c053957a91c
Content-Type: text/plain; charset=UTF-8

A-ha, I hadn't realised JS already went through this. The resulting
confusion and decision to forbid it are probably highly illustrative...

Although (excluding debates over which syntax to use) this initially sounds
like a nice concept, I really don't think it's worth all the hassle. I
still maintain that situations where qualifying a name is viewed as
unbearably tedious (key word:) usually indicate questionable design and a
prime opportunity to refactor... such as by making the code into an
instance method and using the real *this*. ;-)

--
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/CACGiwhFgahqkOpqhEtSwQUqz-kSkybTsYBjbXG4-FKoY28LpHw%40mail.gmail.com.

--001a114b3dac3e7e3c053957a91c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>A-ha, I hadn&#39;t realised JS already went through t=
his. The resulting confusion and decision to forbid it are probably highly =
illustrative...<br><br></div>Although (excluding debates over which syntax =
to use) this initially sounds like a nice concept, I really don&#39;t think=
 it&#39;s worth all the hassle. I still maintain that situations where qual=
ifying a name is viewed as unbearably tedious (key word:) usually indicate =
questionable design and a prime opportunity to refactor... such as by makin=
g the code into an instance method and using the real <i>this</i>. ;-)<br><=
br></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/CACGiwhFgahqkOpqhEtSwQUqz-kSkybTsYBjb=
XG4-FKoY28LpHw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhFgahqkOpqh=
EtSwQUqz-kSkybTsYBjbXG4-FKoY28LpHw%40mail.gmail.com</a>.<br />

--001a114b3dac3e7e3c053957a91c--

.


Author: Viacheslav Usov <via.usov@gmail.com>
Date: Sat, 6 Aug 2016 10:36:14 +0200
Raw View
--001a1142b94081727005396313c8
Content-Type: text/plain; charset=UTF-8

On Fri, Aug 5, 2016 at 8:54 PM, <inkwizytoryankes@gmail.com> wrote:

But then this will be first time when C++ template quietly change syntax of
> code when you instantiating different templates, consider this case:
>
> class a{};
> struct t1
> {
>   void f()
>   {
>     a* test;
>     ++test;
>   }
> };
> struct t2
> {
>   int a;
>   int test;
>   void f()
>   {
>     a* test;
>     ++test;
>   }
> };
> `t1::f` and `t2::f` look similar but work completely different. How
> compilers will handle cases when every symbol in function can be member
> variable?
>


Your "first time" statement is false. Consider this code:

int a;
template<class A> struct B : public A
{
void foo() { a = 6; } // is this A::a or ::a?
};

struct C {};
struct D { int a; };

B<C>().foo();
B<D>().foo();

The technique exemplified above is standard in C++ metaprogramming, so
please rest assured that compilers know how to handle such cases.

> JavaScript had same problems with `with` and solution was to ban it:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/
Reference/Statements/with

This is also false. 'with' is not banned, and the problems are not "same".
The fundamental issue there is that JavaScript objects are not statically
typed. C++ is statically typed.

Cheers,
V.

--
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/CAA7YVg3C81%3DG91NDxchYbc7%3Db3ma_6C3Ef_d9hNhntVaaa63Yw%40mail.gmail.com.

--001a1142b94081727005396313c8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Aug 5, 2016 at 8:54 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:inkwiz=
ytoryankes@gmail.com" target=3D"_blank">inkwizytoryankes@gmail.com</a>&gt;<=
/span> wrote:<br><div><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;bord=
er-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>But =
then this will be first time when C++ template quietly change syntax of cod=
e when you instantiating different templates, consider this case:<br><div s=
tyle=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;background-c=
olor:rgb(250,250,250)"><code><div><span style=3D"color:rgb(0,0,0)"><br></sp=
an><span style=3D"color:rgb(0,0,136)">class</span><span style=3D"color:rgb(=
0,0,0)"> a</span><span style=3D"color:rgb(102,102,0)">{};</span><span style=
=3D"color:rgb(0,0,0)"><br></span><code><span style=3D"color:rgb(0,0,136)">s=
truct</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:r=
gb(0,0,0)"></span></code><span style=3D"color:rgb(0,0,0)">t1<br></span><spa=
n style=3D"color:rgb(102,102,0)">{</span><span style=3D"color:rgb(0,0,0)"><=
br>=C2=A0 </span><span style=3D"color:rgb(0,0,136)">void</span><span style=
=3D"color:rgb(0,0,0)"> f</span><span style=3D"color:rgb(102,102,0)">()</spa=
n><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 </span><span style=3D"color:r=
gb(102,102,0)">{</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 a=
</span><span style=3D"color:rgb(102,102,0)">*</span><span style=3D"color:rg=
b(0,0,0)"> test</span><span style=3D"color:rgb(102,102,0)">;</span><span st=
yle=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 </span><span style=3D"color:rgb(=
102,102,0)">++</span><span style=3D"color:rgb(0,0,0)">test</span><span styl=
e=3D"color:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)"><br>=C2=
=A0 </span><span style=3D"color:rgb(102,102,0)">}</span><span style=3D"colo=
r:rgb(0,0,0)"><br></span><span style=3D"color:rgb(102,102,0)">};</span><spa=
n style=3D"color:rgb(0,0,0)"><br></span><span style=3D"color:rgb(0,0,136)">=
struct</span><span style=3D"color:rgb(0,0,0)"> t2<br></span><span style=3D"=
color:rgb(102,102,0)">{</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 <=
/span><span style=3D"color:rgb(0,0,136)">int</span><span style=3D"color:rgb=
(0,0,0)"> a</span><span style=3D"color:rgb(102,102,0)">;</span><span style=
=3D"color:rgb(0,0,0)"><br>=C2=A0 </span><span style=3D"color:rgb(0,0,136)">=
int</span><span style=3D"color:rgb(0,0,0)"> test</span><span style=3D"color=
:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 </span=
><span style=3D"color:rgb(0,0,136)">void</span><span style=3D"color:rgb(0,0=
,0)"> f</span><span style=3D"color:rgb(102,102,0)">()</span><span style=3D"=
color:rgb(0,0,0)"><br>=C2=A0 </span><span style=3D"color:rgb(102,102,0)">{<=
/span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 a</span><span styl=
e=3D"color:rgb(102,102,0)">*</span><span style=3D"color:rgb(0,0,0)"> test</=
span><span style=3D"color:rgb(102,102,0)">;</span><span style=3D"color:rgb(=
0,0,0)"><br>=C2=A0 =C2=A0 </span><span style=3D"color:rgb(102,102,0)">++</s=
pan><span style=3D"color:rgb(0,0,0)">test</span><span style=3D"color:rgb(10=
2,102,0)">;</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 </span><span =
style=3D"color:rgb(102,102,0)">}</span><span style=3D"color:rgb(0,0,0)"><br=
></span><span style=3D"color:rgb(102,102,0)">};</span></div></code></div>`t=
1::f` and `t2::f` look similar but work completely different. How compilers=
 will handle cases when every symbol in function can be member variable?<br=
></div></div></blockquote><div><br></div><div><br></div><div>Your &quot;fir=
st time&quot; statement is false. Consider this code:</div><div><br></div><=
div><div>int a;</div><div>template&lt;class A&gt; struct B : public A</div>=
<div>{</div><div><span class=3D"gmail-Apple-tab-span" style=3D"white-space:=
pre"> </span>void foo() { a =3D 6; } // is this A::a or ::a?</div><div>};</=
div><div><br></div><div>struct C {};</div><div>struct D { int a; };</div><d=
iv><br></div><div>B&lt;C&gt;().foo();</div><div>B&lt;D&gt;().foo();</div></=
div><div><br></div><div>The technique exemplified above is standard in C++ =
metaprogramming, so please rest assured that compilers know how to handle s=
uch cases.</div><div><br></div><div>&gt; JavaScript had same problems with =
`with` and solution was to ban it: <a href=3D"https://developer.mozilla.org=
/en-US/docs/Web/JavaScript/Reference/Statements/with" target=3D"_blank">htt=
ps://developer.mozilla.org/<wbr>en-US/docs/Web/JavaScript/<wbr>Reference/St=
atements/with</a></div><div><br></div><div>This is also false. &#39;with&#3=
9; is not banned, and the problems are not &quot;same&quot;. The fundamenta=
l issue there is that JavaScript objects are not statically typed. C++ is s=
tatically typed.</div><div><br></div><div>Cheers,</div><div>V.</div><div><b=
r></div></div></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/CAA7YVg3C81%3DG91NDxchYbc7%3Db3ma_6C3=
Ef_d9hNhntVaaa63Yw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3C81%3=
DG91NDxchYbc7%3Db3ma_6C3Ef_d9hNhntVaaa63Yw%40mail.gmail.com</a>.<br />

--001a1142b94081727005396313c8--

.


Author: Viacheslav Usov <via.usov@gmail.com>
Date: Sat, 6 Aug 2016 10:42:00 +0200
Raw View
--001a1140126626c2f80539632821
Content-Type: text/plain; charset=UTF-8

On Fri, Aug 5, 2016 at 8:59 PM, D. B. <db0451@gmail.com> wrote:

> I still maintain that situations where qualifying a name is viewed as
unbearably tedious (key word:) usually indicate questionable design and a
prime opportunity to refactor... such as by making the code into an
instance method and using the real *this*. ;-)

If all you have is a hammer, everything looks like a nail.

Cheers,
V.

--
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/CAA7YVg2kLhid82Fvox_Fag8o1Tq5%3DwGiio4x5hrJEFJx7umTxA%40mail.gmail.com.

--001a1140126626c2f80539632821
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Aug 5, 2016 at 8:59 PM, D. B. <span dir=3D"ltr">&lt;<a href=3D"mailto:d=
b0451@gmail.com" target=3D"_blank">db0451@gmail.com</a>&gt;</span> wrote:</=
div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">&gt; I =
still maintain that situations where qualifying a name is viewed as unbeara=
bly tedious (key word:) usually indicate questionable design and a prime op=
portunity to refactor... such as by making the code into an instance method=
 and using the real <i>this</i>. ;-)</div><div class=3D"gmail_quote"><br></=
div><div class=3D"gmail_quote">If all you have is a hammer, everything look=
s like a nail.</div><div class=3D"gmail_quote"><br></div><div class=3D"gmai=
l_quote">Cheers,</div><div class=3D"gmail_quote">V.</div><div class=3D"gmai=
l_quote"><br></div></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/CAA7YVg2kLhid82Fvox_Fag8o1Tq5%3DwGiio=
4x5hrJEFJx7umTxA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2kLhid82=
Fvox_Fag8o1Tq5%3DwGiio4x5hrJEFJx7umTxA%40mail.gmail.com</a>.<br />

--001a1140126626c2f80539632821--

.


Author: inkwizytoryankes@gmail.com
Date: Sat, 6 Aug 2016 06:28:08 -0700 (PDT)
Raw View
------=_Part_186_1313709334.1470490088793
Content-Type: multipart/alternative;
 boundary="----=_Part_187_20487071.1470490088793"

------=_Part_187_20487071.1470490088793
Content-Type: text/plain; charset=UTF-8



On Saturday, August 6, 2016 at 10:36:17 AM UTC+2, Viacheslav Usov wrote:
>
> On Fri, Aug 5, 2016 at 8:54 PM, <inkwizyt...@gmail.com <javascript:>>
> wrote:
>
> Your "first time" statement is false. Consider this code:
>
> int a;
> template<class A> struct B : public A
> {
> void foo() { a = 6; } // is this A::a or ::a?
> };
>
> struct C {};
> struct D { int a; };
>
> B<C>().foo();
> B<D>().foo();
>
> The technique exemplified above is standard in C++ metaprogramming, so
> please rest assured that compilers know how to handle such cases.
>
>
Correct answer is: "error: 'a' was not declared in this scope" if you
remove `int a;` This do exactly what I said in first post, compiler will
ignore members of template and will look for global.
https://godbolt.org/g/1tn3t6



> > JavaScript had same problems with `with` and solution was to ban it:
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/with
> <https://www.google.com/url?q=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FJavaScript%2FReference%2FStatements%2Fwith&sa=D&sntz=1&usg=AFQjCNHAgbSVgE_V_8kyVyBb35DbbcTsZA>
>
> This is also false. 'with' is not banned, and the problems are not "same".
> The fundamental issue there is that JavaScript objects are not statically
> typed. C++ is statically typed.
>
>
Again: "Using with is not recommended, and is forbidden in ECMAScript 5
strict mode. The recommended alternative is to assign the object whose
properties you want to access to a temporary variable.".
In template contest C++ is dynamic typed langue too. But all test and
validation is done during compile time.

--
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/e6b86272-abd9-403e-ae26-8f747b2b6fae%40isocpp.org.

------=_Part_187_20487071.1470490088793
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Saturday, August 6, 2016 at 10:36:17 AM UTC+2, =
Viacheslav Usov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote">On Fri, Aug 5, 2016 at 8:54 PM,  <=
span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscat=
ed-mailto=3D"TmfBfmoiCAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39=
;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39=
;;return true;">inkwizyt...@gmail.com</a>&gt;</span> wrote:<br><br><div>You=
r &quot;first time&quot; statement is false. Consider this code:</div><div>=
<br></div><div><div>int a;</div><div>template&lt;class A&gt; struct B : pub=
lic A</div><div>{</div><div><span style=3D"white-space:pre"> </span>void fo=
o() { a =3D 6; } // is this A::a or ::a?</div><div>};</div><div><br></div><=
div>struct C {};</div><div>struct D { int a; };</div><div><br></div><div>B&=
lt;C&gt;().foo();</div><div>B&lt;D&gt;().foo();</div></div><div><br></div><=
div>The technique exemplified above is standard in C++ metaprogramming, so =
please rest assured that compilers know how to handle such cases.</div><div=
><br></div></div></div></div></blockquote><div>=C2=A0</div><div>Correct ans=
wer is: &quot;<span class=3D"msg">error: &#39;a&#39; was not declared in th=
is scope</span>&quot; if you remove `int a;` This do exactly what I said in=
 first post, compiler will ignore members of template and will look for glo=
bal.<br>https://godbolt.org/g/1tn3t6<br><br>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote=
"><div></div><div>&gt; JavaScript had same problems with `with` and solutio=
n was to ban it: <a href=3D"https://www.google.com/url?q=3Dhttps%3A%2F%2Fde=
veloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FJavaScript%2FReference%2FStateme=
nts%2Fwith&amp;sa=3DD&amp;sntz=3D1&amp;usg=3DAFQjCNHAgbSVgE_V_8kyVyBb35Dbbc=
TsZA" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;ht=
tps://www.google.com/url?q\x3dhttps%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2=
Fdocs%2FWeb%2FJavaScript%2FReference%2FStatements%2Fwith\x26sa\x3dD\x26sntz=
\x3d1\x26usg\x3dAFQjCNHAgbSVgE_V_8kyVyBb35DbbcTsZA&#39;;return true;" oncli=
ck=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdevelo=
per.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FJavaScript%2FReference%2FStatements%=
2Fwith\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHAgbSVgE_V_8kyVyBb35DbbcTsZA=
&#39;;return true;">https://developer.mozilla.org/<wbr>en-US/docs/Web/JavaS=
cript/<wbr>Reference/Statements/with</a></div><div><br></div><div>This is a=
lso false. &#39;with&#39; is not banned, and the problems are not &quot;sam=
e&quot;. The fundamental issue there is that JavaScript objects are not sta=
tically typed. C++ is statically typed.</div><div><br></div></div></div></d=
iv></blockquote><div>=C2=A0<br>Again: &quot;Using with is not recommended, =
and is forbidden in ECMAScript 5 strict mode. The recommended alternative i=
s to assign the object whose properties you want to access to a temporary v=
ariable.&quot;.<br>In template contest C++ is dynamic typed langue too. But=
 all test and validation is done during compile time.<br></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/e6b86272-abd9-403e-ae26-8f747b2b6fae%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e6b86272-abd9-403e-ae26-8f747b2b6fae=
%40isocpp.org</a>.<br />

------=_Part_187_20487071.1470490088793--

------=_Part_186_1313709334.1470490088793--

.


Author: "D. B." <db0451@gmail.com>
Date: Sat, 6 Aug 2016 15:10:40 +0100
Raw View
--047d7bacb18e82d426053967bf7d
Content-Type: text/plain; charset=UTF-8

On Sat, Aug 6, 2016 at 9:42 AM, Viacheslav Usov <via.usov@gmail.com> wrote:

> On Fri, Aug 5, 2016 at 8:59 PM, D. B. <db0451@gmail.com> wrote:
>
> > I still maintain that situations where qualifying a name is viewed as
> unbearably tedious (key word:) usually indicate questionable design and a
> prime opportunity to refactor... such as by making the code into an
> instance method and using the real *this*. ;-)
>
> If all you have is a hammer, everything looks like a nail.
>

Do you think this analogy works for you? I'd say it's better suited to you
and this thread. Giving an orthogonal meaning to *this* is a huge new
hammer with which to confuse coders or tempt them to overuse - and one for
which I don't see a real need. So I've not got a hammer in this debate. Or
did you mean something else?

We can agree to disagree, but read naively (which I might well be doing),
this is an ill-fitting analogy that implies I'm some unsophisticated coder
who just waves around a hammer, instead of seeing the genius of your
proposed scalpel, or whatever you think this is.

--
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/CACGiwhEeRid5vBJt8Vmz8eAe5W6vxc%2BcJ5wt%2BMDfYs0D_7QORw%40mail.gmail.com.

--047d7bacb18e82d426053967bf7d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Aug 6, 2016 at 9:42 AM, Viacheslav Usov <span dir=3D"ltr">&lt;<a href=
=3D"mailto:via.usov@gmail.com" target=3D"_blank">via.usov@gmail.com</a>&gt;=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div clas=
s=3D"gmail_extra"><span class=3D""><div class=3D"gmail_quote">On Fri, Aug 5=
, 2016 at 8:59 PM, D. B. <span dir=3D"ltr">&lt;<a href=3D"mailto:db0451@gma=
il.com" target=3D"_blank">db0451@gmail.com</a>&gt;</span> wrote:</div><div =
class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">&gt; I still mai=
ntain that situations where qualifying a name is viewed as unbearably tedio=
us (key word:) usually indicate questionable design and a prime opportunity=
 to refactor... such as by making the code into an instance method and usin=
g the real <i>this</i>. ;-)</div><div class=3D"gmail_quote"><br></div></spa=
n><div class=3D"gmail_quote">If all you have is a hammer, everything looks =
like a nail.</div></div></div></blockquote><div><br></div><div>Do you think=
 this analogy works for you? I&#39;d say it&#39;s better suited to you and =
this thread. Giving an orthogonal meaning to <i>this</i> is a huge new hamm=
er with which to confuse coders or tempt them to overuse - and one for whic=
h I don&#39;t see a real need. So I&#39;ve not got a hammer in this debate.=
 Or did you mean something else?<br><br>We can agree to disagree, but read =
naively (which I might well be doing), this is an ill-fitting analogy that =
implies I&#39;m some unsophisticated coder who just waves around a hammer, =
instead of seeing the genius of your proposed scalpel, or whatever you thin=
k this is.<br><br></div></div></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/CACGiwhEeRid5vBJt8Vmz8eAe5W6vxc%2BcJ5=
wt%2BMDfYs0D_7QORw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhEeRid5=
vBJt8Vmz8eAe5W6vxc%2BcJ5wt%2BMDfYs0D_7QORw%40mail.gmail.com</a>.<br />

--047d7bacb18e82d426053967bf7d--

.


Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 6 Aug 2016 07:18:48 -0700 (PDT)
Raw View
------=_Part_2647_92334386.1470493128681
Content-Type: multipart/alternative;
 boundary="----=_Part_2648_1537904992.1470493128687"

------=_Part_2648_1537904992.1470493128687
Content-Type: text/plain; charset=UTF-8

On Saturday, August 6, 2016 at 9:28:09 AM UTC-4, inkwizyt...@gmail.com
wrote:
>
> On Saturday, August 6, 2016 at 10:36:17 AM UTC+2, Viacheslav Usov wrote:
>>
>> On Fri, Aug 5, 2016 at 8:54 PM, <inkwizyt...@gmail.com> wrote:
>>
>> Your "first time" statement is false. Consider this code:
>>
>> int a;
>> template<class A> struct B : public A
>> {
>> void foo() { a = 6; } // is this A::a or ::a?
>> };
>>
>> struct C {};
>> struct D { int a; };
>>
>> B<C>().foo();
>> B<D>().foo();
>>
>> The technique exemplified above is standard in C++ metaprogramming, so
>> please rest assured that compilers know how to handle such cases.
>>
>>
> Correct answer is: "error: 'a' was not declared in this scope" if you
> remove `int a;` This do exactly what I said in first post, compiler will
> ignore members of template and will look for global.
> https://godbolt.org/g/1tn3t6
>

Good old two-phase lookup. If a name is not obviously a dependent name,
then it is bound at the time the template is declared. And if it can't be,
then it's a compile error.

--
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/12100b03-da20-44bd-8367-8756fadd9594%40isocpp.org.

------=_Part_2648_1537904992.1470493128687
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, August 6, 2016 at 9:28:09 AM UTC-4, inkwizyt.=
...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr">On Saturday, August 6, 2016 at 10:36:17 AM UTC+2, Viacheslav Usov wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote">On Fri, Aug 5, 2016 at 8:54 PM,  <span dir=3D"ltr">&lt;<a =
rel=3D"nofollow">inkwizyt...@gmail.com</a>&gt;</span> wrote:<br><br><div>Yo=
ur &quot;first time&quot; statement is false. Consider this code:</div><div=
><br></div><div><div>int a;</div><div>template&lt;class A&gt; struct B : pu=
blic A</div><div>{</div><div><span style=3D"white-space:pre"> </span>void f=
oo() { a =3D 6; } // is this A::a or ::a?</div><div>};</div><div><br></div>=
<div>struct C {};</div><div>struct D { int a; };</div><div><br></div><div>B=
&lt;C&gt;().foo();</div><div>B&lt;D&gt;().foo();</div></div><div><br></div>=
<div>The technique exemplified above is standard in C++ metaprogramming, so=
 please rest assured that compilers know how to handle such cases.</div><di=
v><br></div></div></div></div></blockquote><div>=C2=A0</div><div>Correct an=
swer is: &quot;<span>error: &#39;a&#39; was not declared in this scope</spa=
n>&quot; if you remove `int a;` This do exactly what I said in first post, =
compiler will ignore members of template and will look for global.<br><a hr=
ef=3D"https://godbolt.org/g/1tn3t6" target=3D"_blank" rel=3D"nofollow" onmo=
usedown=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fg=
odbolt.org%2Fg%2F1tn3t6\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGb5vI2OxRBB=
C7mgoTwrCm4jt2zmA&#39;;return true;" onclick=3D"this.href=3D&#39;https://ww=
w.google.com/url?q\x3dhttps%3A%2F%2Fgodbolt.org%2Fg%2F1tn3t6\x26sa\x3dD\x26=
sntz\x3d1\x26usg\x3dAFQjCNGb5vI2OxRBBC7mgoTwrCm4jt2zmA&#39;;return true;">h=
ttps://godbolt.org/g/1tn3t6</a></div></div></blockquote><div><br>Good old t=
wo-phase lookup. If a name is not obviously a dependent name, then it is bo=
und at the time the template is declared. And if it can&#39;t be, then it&#=
39;s a compile error.</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/12100b03-da20-44bd-8367-8756fadd9594%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/12100b03-da20-44bd-8367-8756fadd9594=
%40isocpp.org</a>.<br />

------=_Part_2648_1537904992.1470493128687--

------=_Part_2647_92334386.1470493128681--

.


Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 07 Aug 2016 09:24:55 -0700
Raw View
On s=C3=A1bado, 6 de agosto de 2016 10:36:14 PDT Viacheslav Usov wrote:
> int a;
> template<class A> struct B : public A
> {
> void foo() { a =3D 6; } // is this A::a or ::a?
> };

That's easy: it's ::a.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=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/1923806.x3VNPmjubb%40tjmaciei-mobl1.

.


Author: szollosi.lorand@gmail.com
Date: Sun, 7 Aug 2016 10:23:42 -0700 (PDT)
Raw View
------=_Part_307_583304616.1470590622905
Content-Type: multipart/alternative;
 boundary="----=_Part_308_1811263987.1470590622906"

------=_Part_308_1811263987.1470590622906
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

1., 2., why the restriction? why couldn't I write two using autos e.g. in a=
=20
visitor?

2016. augusztus 5., p=C3=A9ntek 12:55:40 UTC+2 id=C5=91pontban Viacheslav U=
sov a=20
k=C3=B6vetkez=C5=91t =C3=ADrta:
>
> On Fri, Aug 5, 2016 at 12:18 PM, D. B. <db0...@gmail.com <javascript:>>=
=20
> wrote:
>
> > But also, *using* seems to make it redundant anyway. Just as one would=
=20
> write *using namespace std;*, it would seem that we could also write *usi=
ng=20
> auto someObj;*, where *auto* means 'I want a variable, not a namespace or=
=20
> anything else', and this would mean that *someObj*'s class would be added=
=20
> to implicit name resolution. A la *With someObj* from VB.
>
> What you are really saying is that you prefer the syntax "using auto=20
> someObj" over "using this =3D someObj".
>
> However, I prefer the latter, and I proposed it after I considered the=20
> former. Why I prefer the latter:
>
> 1. It is more general, because it can bind to an expression, not just a=
=20
> variable.
>
> 2. It is less confusing, because at any given location in the code there=
=20
> can be exactly ONE this pointer. What does "add" in the description above=
=20
> really mean? Does that mean there can be multiple additional pointers use=
d=20
> for name resolution? That sounds like a great idea, but it has far more=
=20
> nuances than in the "single this" paradigm, which are yet to be defined b=
y=20
> you (think ambiguous resolution and ways to deal with it). Note that "wit=
h"=20
> in VB only works with one object, and nested "with" statements override t=
he=20
> current implicit object, rather than "add" more objects to name resolutio=
n.=20
> If your "add" really means "override whatever is used implicitly now", th=
en=20
> it is strictly less powerful than my syntax, AND its form still suggests=
=20
> "add" rather than "override", because that's how it works with namespaces=
..
>
> 3. You still need some other syntax to say "no implicit this", or, with a=
=20
> true "add" semantics, "no implicit X"
>
> Cheers,
> V.
>

--=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/7a0df764-0736-4262-a58e-a977a6acc8f4%40isocpp.or=
g.

------=_Part_308_1811263987.1470590622906
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">1., 2., why the restriction? why couldn&#39;t I write two =
using autos e.g. in a visitor?<br><br>2016. augusztus 5., p=C3=A9ntek 12:55=
:40 UTC+2 id=C5=91pontban Viacheslav Usov a k=C3=B6vetkez=C5=91t =C3=ADrta:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div cla=
ss=3D"gmail_quote">On Fri, Aug 5, 2016 at 12:18 PM, D. B. <span dir=3D"ltr"=
>&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"h-k=
aXnHbBwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39=
;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">=
db0...@gmail.com</a>&gt;</span> wrote:<br><div><br></div><div>&gt; But also=
, <i>using</i> seems to make it redundant anyway. Just as one would write <=
i>using namespace std;</i>, it would seem that we could also write <i>using=
 auto someObj;</i>, where <i>auto</i> means &#39;I want a variable, not a n=
amespace or anything else&#39;, and this would mean that <i>someObj</i>&#39=
;s class would be added to implicit name resolution. A la <i>With someObj</=
i> from VB.</div><div><br></div><div>What you are really saying is that you=
 prefer the syntax &quot;using auto someObj&quot; over &quot;using this =3D=
 someObj&quot;.</div><div><br></div><div>However, I prefer the latter, and =
I proposed it after I considered the former. Why I prefer the latter:</div>=
<div><br></div><div>1. It is more general, because it can bind to an expres=
sion, not just a variable.</div><div><br></div><div>2. It is less confusing=
, because at any given location in the code there can be exactly ONE this p=
ointer. What does &quot;add&quot; in the description above really mean? Doe=
s that mean there can be multiple additional pointers used for name resolut=
ion? That sounds like a great idea, but it has far more nuances than in the=
 &quot;single this&quot; paradigm, which are yet to be defined by you (thin=
k ambiguous resolution and ways to deal with it). Note that &quot;with&quot=
; in VB only works with one object, and nested &quot;with&quot; statements =
override the current implicit object, rather than &quot;add&quot; more obje=
cts to name resolution. If your &quot;add&quot; really means &quot;override=
 whatever is used implicitly now&quot;, then it is strictly less powerful t=
han my syntax, AND its form still suggests &quot;add&quot; rather than &quo=
t;override&quot;, because that&#39;s how it works with namespaces.</div><di=
v><br></div><div>3. You still need some other syntax to say &quot;no implic=
it this&quot;, or, with a true &quot;add&quot; semantics, &quot;no implicit=
 X&quot;</div><div><br></div><div>Cheers,</div><div>V.</div></div></div></d=
iv>
</blockquote></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/7a0df764-0736-4262-a58e-a977a6acc8f4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7a0df764-0736-4262-a58e-a977a6acc8f4=
%40isocpp.org</a>.<br />

------=_Part_308_1811263987.1470590622906--

------=_Part_307_583304616.1470590622905--

.


Author: Viacheslav Usov <via.usov@gmail.com>
Date: Mon, 8 Aug 2016 10:07:19 +0200
Raw View
--001a1142beaec7231705398ae77f
Content-Type: text/plain; charset=UTF-8

Thanks to all the contributors to this thread. I will have another
iteration of the proposal in a few days, hopefully with all the feedback
taken into account.

Cheers,
V.

--
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/CAA7YVg2vHbYBGttUx6mq02PqWhW9g9qD-mnZh93%3D%2BcEdCaxaNQ%40mail.gmail.com.

--001a1142beaec7231705398ae77f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra">Thanks to all the contributors =
to this thread. I will have another iteration of the proposal in a few days=
, hopefully with all the feedback taken into account.</div><div class=3D"gm=
ail_extra"><br></div><div class=3D"gmail_extra">Cheers,</div><div class=3D"=
gmail_extra">V.</div><div class=3D"gmail_extra"><br></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/CAA7YVg2vHbYBGttUx6mq02PqWhW9g9qD-mnZ=
h93%3D%2BcEdCaxaNQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2vHbYB=
GttUx6mq02PqWhW9g9qD-mnZh93%3D%2BcEdCaxaNQ%40mail.gmail.com</a>.<br />

--001a1142beaec7231705398ae77f--

.


Author: Viacheslav Usov <via.usov@gmail.com>
Date: Mon, 8 Aug 2016 10:11:13 +0200
Raw View
--001a114025ccc3ac0505398af52c
Content-Type: text/plain; charset=UTF-8

On Sat, Aug 6, 2016 at 4:10 PM, D. B. <db0451@gmail.com> wrote:

> We can agree to disagree, but read naively (which I might well be doing),
this is an ill-fitting analogy that implies I'm some unsophisticated coder
who just waves around a hammer, instead of seeing the genius of your
proposed scalpel, or whatever you think this is.

I did not mean that to be taken personally. The particular hammer I had in
mind was "make everything an object with member functions". I'll probably
address this specifically in a follow-up thread.

Cheers,
V.

--
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/CAA7YVg1fa8ufLLwTWeP8PS%2BsEth10%2BzMtYcHPzTSfn3NbeoKaQ%40mail.gmail.com.

--001a114025ccc3ac0505398af52c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Aug 6, 2016 at 4:10 PM, D. B. <span dir=3D"ltr">&lt;<a href=3D"mailto:d=
b0451@gmail.com" target=3D"_blank">db0451@gmail.com</a>&gt;</span> wrote:</=
div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">&gt; We=
 can agree to disagree, but read naively (which I might well be doing), thi=
s is an ill-fitting analogy that implies I&#39;m some unsophisticated coder=
 who just waves around a hammer, instead of seeing the genius of your propo=
sed scalpel, or whatever you think this is.</div><div class=3D"gmail_quote"=
><br></div><div class=3D"gmail_quote">I did not mean that to be taken perso=
nally. The particular hammer I had in mind was &quot;make everything an obj=
ect with member functions&quot;. I&#39;ll probably address this specificall=
y in a follow-up thread.</div><div class=3D"gmail_quote"><br></div><div cla=
ss=3D"gmail_quote">Cheers,</div><div class=3D"gmail_quote">V.</div></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/CAA7YVg1fa8ufLLwTWeP8PS%2BsEth10%2BzM=
tYcHPzTSfn3NbeoKaQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg1fa8uf=
LLwTWeP8PS%2BsEth10%2BzMtYcHPzTSfn3NbeoKaQ%40mail.gmail.com</a>.<br />

--001a114025ccc3ac0505398af52c--

.


Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Mon, 8 Aug 2016 12:59:06 -0400
Raw View
On 2016-08-05 06:14, Viacheslav Usov wrote:
> Second, how frequently does one have an expression with FOUR levels of
> indirection? Even two levels are quite rare.

Not in VTK code :-). Or Qt code. Qt code is full of stuff like:

  d->UI.widget->method();

....and VTK code often contains stuff like:

  ren->GetRenderWindow()->GetInteractor()->AddObserver(...)
  slice->GetPointData()->GetScalars()->GetNumberOfComponents()
  Path->GetFirstNode()->GetViewProp()->Pick()
  trackInfoPtr->Track->GetPoints()->GetPoint(...)
  StackSelectionWidget->GetInteractor()->GetRenderWindow()->
    GetRenderers()->GetFirstRenderer() // yes, that's two lines!

(Above are real examples from https://github.com/kitware/vivia/. And
don't take into account that vivia code style is to always use `this->`...)

> Grepping through a bunch of libraries that I use in a particular=20
> project, I find 714 lines that use double and higher-order=20
> indirection with -> [...] Grepping for triple indirection with ->, I=20
> get no matches at all in that set of libraries.

Well, you are obviously not looking in the "right" places :-), so your
numbers should be taken with a large grain of salt.

In the aforementioned repo, I found 11,391 instances of double
indirection, 1,805 of which are (at least) triple indirection, and 139
of which are (at least) quadruple indirection. That's using a regex=C2=B9
that can't find instances that were split onto more than one line (which
I know exist, but there are only about a dozen or so of them). Some of
those have an "extra" level `this->`, but not all of them (see above
four-level example). To put that into perspective, there are about 35k
lines containing `->` in total, so *at least* 5% of all code lines
containing an indirection contain an indirection of two or more levels.

In VTK itself=C2=B2, I found 11,457 triple indirections, 2,277 of which are
quadruple indirections (again, no effort made to find any split on
multiple lines). If I only count *double* indirections, I get 98,886,
more than *two orders of magnitude* higher than your numbers, and in
only *one library*. (Admittedly it's a *large* library, but still...)
The numbers for Paraview are probably also quite large.

Claiming that two or more levels is "quite rare" is... highly dependent
on your selection set.

(=C2=B9 The regex I'm using includes stuff like `a->b.c->d`, which I'm
counting as only a double indirection. If I did it right, it excludes
false positives like `a->b(c->d)`.)

(=C2=B2 e25c83daff62223e3cb5cdca15eeef727716bdd2)

--=20
Matthew

--=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/57A8BA5A.4050408%40gmail.com.

.


Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Mon, 8 Aug 2016 13:01:26 -0400
Raw View
On 2016-08-05 06:55, Viacheslav Usov wrote:
> What you are really saying is that you prefer the syntax "using auto
> someObj" over "using this = someObj".
>
> However, I prefer the latter, and I proposed it after I considered the
> former. Why I prefer the latter:
>
> 1. It is more general, because it can bind to an expression, not just a
> variable.

To ask the obvious question... if the RHS is an expression, is it
evaluated at the point where the `using` appears, or every time?

--
Matthew

--
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/57A8BAE6.3090102%40gmail.com.

.


Author: Viacheslav Usov <via.usov@gmail.com>
Date: Mon, 8 Aug 2016 19:50:26 +0200
Raw View
--001a114035163231c70539930df0
Content-Type: text/plain; charset=UTF-8

On Mon, Aug 8, 2016 at 6:59 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> Not in VTK code :-). Or Qt code. Qt code is full of stuff like:

Frankly, that's the first time I hear about VTK. Qt, well, let's put it
this way, I gave up on it a long time ago, and I take this as a
confirmation that my conclusion was reasonable  :)

But, yeah, it does not matter and multiple indirection is not as rare as I
thought. Thanks!

Cheers,
V.

--
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/CAA7YVg1T538J18fZdwiBjy9Wy1T88%3DiW7EgunFaakXhevHOuwQ%40mail.gmail.com.

--001a114035163231c70539930df0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Aug 8, 2016 at 6:59 PM, Matthew Woehlke <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail=
..com</a>&gt;</span> wrote:<br><div><br></div><div>&gt; Not in VTK code :-).=
 Or Qt code. Qt code is full of stuff like:</div><div><br></div><div>Frankl=
y, that&#39;s the first time I hear about VTK. Qt, well, let&#39;s put it t=
his way, I gave up on it a long time ago, and I take this as a confirmation=
 that my conclusion was reasonable =C2=A0:)</div><div><br></div><div>But, y=
eah, it does not matter and multiple indirection is not as rare as I though=
t. Thanks!</div><div><br></div><div>Cheers,</div><div>V.</div></div></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/CAA7YVg1T538J18fZdwiBjy9Wy1T88%3DiW7E=
gunFaakXhevHOuwQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg1T538J18=
fZdwiBjy9Wy1T88%3DiW7EgunFaakXhevHOuwQ%40mail.gmail.com</a>.<br />

--001a114035163231c70539930df0--

.


Author: Viacheslav Usov <via.usov@gmail.com>
Date: Mon, 8 Aug 2016 19:54:48 +0200
Raw View
--001a11410242c6c2140539931ce5
Content-Type: text/plain; charset=UTF-8

On Mon, Aug 8, 2016 at 7:01 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> To ask the obvious question... if the RHS is an expression, is it
evaluated at the point where the `using` appears, or every time?

I knew somebody would come up with that question, so I left it open-ended.
I think it is much easier to specify the behaviour when that is only
evaluated once, and this is very probably much less confusing. Otherwise,
it would be something unique and weird, but, of course, more powerful.

Cheers,
V.

--
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/CAA7YVg17ZOTkjVDzVY1gOjutU3Y%2Br%3DFoxCmRpyE-CjzdckFxnQ%40mail.gmail.com.

--001a11410242c6c2140539931ce5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Aug 8, 2016 at 7:01 PM, Matthew Woehlke <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail=
..com</a>&gt;</span> wrote:<br><div><br></div><div>&gt; To ask the obvious q=
uestion... if the RHS is an expression, is it evaluated at the point where =
the `using` appears, or every time?</div><div><br></div><div>I knew somebod=
y would come up with that question, so I left it open-ended. I think it is =
much easier to specify the behaviour when that is only evaluated once, and =
this is very probably much less confusing. Otherwise, it would be something=
 unique and weird, but, of course, more powerful.</div><div><br></div><div>=
Cheers,</div><div>V.</div></div></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/CAA7YVg17ZOTkjVDzVY1gOjutU3Y%2Br%3DFo=
xCmRpyE-CjzdckFxnQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg17ZOTk=
jVDzVY1gOjutU3Y%2Br%3DFoxCmRpyE-CjzdckFxnQ%40mail.gmail.com</a>.<br />

--001a11410242c6c2140539931ce5--

.