I have some comments on N4165/N4174.

1. weird code
It's my understanding that under this proposal, following code is well-form=
ed.

4.0.sqrt() ;
"hello".puts() ;

Is this correct?


If so and If we allow N4165's "Additionally allow =E2=80=9Cthis=E2=80=9D in=
 not only
the first parameter location",
It does allow this:

fp->fputs("hello") ;

as well as this:

"hello"->fputs(fp) ;


2. Tool support
The papers wrote about better tool support.
Although I agree with the idea, there are so many too generic function
templates in the standard library that bloat up the auto completion
candidates.
Like move, swap, addressof.

Without some constrained template features like concept or some hard
coded/heuristic restriction on tool implementation,
a set of auto completion name candidates are indeed smaller than free
functions, but not that small enough.

Consider FILE from <stdio.h>.
The paper said it can auto complete fseek.

FILE * fp ;
fp->fseek

It looks nice.

But, Annex D.5 said C headers are deprecated and we should use C++
header(<cstdio>) instead.
So we should write like this:

std::FILE * fp =3D ... ;

This add std namespace to fp's associated namespace so all standard
library names are on the candidate list.

Suppose we also #included <algorithm> and wrote:

fp->

Tool suggest all <algorithm> function templates because fp is a pointer.

fp->for_each

Even if without ADL, id-expression allows qualified-id so a tool just
list up all viable functions:

fp->std::for_each


This is only considering the standard library, I think users also
wrote many too generic functions like this.
Combining those, auto completion candidates will bloat up with
completely unrelated generic function names user don't expect it to be
suggested.


I don't think tool support situation will be any better with this proposal.
It may be worse because candidate bloat up also affect existing class
types and overwhelm the result.

Very common types(like const char *, long double etc) and class types
which has user defined conversion to common types now shows all sort
of common functions as well as user defined literals!

long double ld ;
ld.operator "" il() ; // std::complex<long double>


What do you think?

--=20
Ryou Ezoe

Occupation: DWANGO Co., Ltd.

Blog:     http://cpplover.blogspot.com/
Twitter: https://twitter.com/EzoeRyou
GitHub: https://github.com/EzoeRyou

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

------=_Part_3974_100266043.1414431942061
Content-Type: text/plain; charset=UTF-8

On Monday, October 27, 2014 3:24:31 AM UTC-5, Ryou Ezoe wrote:
>
> I have some comments on N4165/N4174.
>
> 1. weird code
> It's my understanding that under this proposal, following code is
> well-formed.
>
> 4.0.sqrt() ;
> "hello".puts() ;
>

I have similar concerns, largely around the number of applicable free
functions for common types such as int, and whether literals or only named
values will participate in unified call syntax. Assuming literals of plain
types participate, it would be good to specifically address calling free
functions on integers, as Python has some initially surprising parsing in
this area:

http://stackoverflow.com/questions/10955703/accessing-a-python-int-literals-methods

--
Michael Urman

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Monday, October 27, 2014 3:24:31 AM UTC-5, Ryou Ezoe wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">I have some comments on N4=
165/N4174.
<br>
<br>1. weird code
<br>It's my understanding that under this proposal, following code is well-=
formed.
<br>
<br>4.0.sqrt() ;
<br>"hello".puts() ;
<br></blockquote><div><br></div><div>I have similar concerns, largely aroun=
d the number of applicable free functions for common types such as int, and=
 whether literals or only named values will participate in unified call syn=
tax. Assuming literals of plain types participate, it would be good to spec=
ifically address calling free functions on integers, as Python has some ini=
tially surprising parsing in this area:</div><div><br></div><div>http://sta=
ckoverflow.com/questions/10955703/accessing-a-python-int-literals-methods</=
div><div><br></div><div>--&nbsp;</div><div>Michael Urman</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_3974_100266043.1414431942061--

.

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

On Mon, Oct 27, 2014 at 1:24 AM, Ryou Ezoe <boostcpp@gmail.com> wrote:

> I have some comments on N4165/N4174.
>
> 1. weird code
> It's my understanding that under this proposal, following code is
> well-formed.
>
> 4.0.sqrt() ;
> "hello".puts() ;
>
> Is this correct?
>

Well, you'd need to write

4.0 .sqrt();

.... or the second period is part of an ill-formed "4.0." literal.

If so and If we allow N4165's "Additionally allow =E2=80=9Cthis=E2=80=9D in=
 not only
> the first parameter location",
> It does allow this:
>
> fp->fputs("hello") ;
>
> as well as this:
>
> "hello"->fputs(fp) ;
>
>
> 2. Tool support
> The papers wrote about better tool support.
> Although I agree with the idea, there are so many too generic function
> templates in the standard library that bloat up the auto completion
> candidates.
> Like move, swap, addressof.
>
> Without some constrained template features like concept or some hard
> coded/heuristic restriction on tool implementation,
> a set of auto completion name candidates are indeed smaller than free
> functions, but not that small enough.
>
> Consider FILE from <stdio.h>.
> The paper said it can auto complete fseek.
>
> FILE * fp ;
> fp->fseek
>
> It looks nice.
>
> But, Annex D.5 said C headers are deprecated and we should use C++
> header(<cstdio>) instead.
> So we should write like this:
>
> std::FILE * fp =3D ... ;
>
> This add std namespace to fp's associated namespace so all standard
> library names are on the candidate list.
>
> Suppose we also #included <algorithm> and wrote:
>
> fp->
>
> Tool suggest all <algorithm> function templates because fp is a pointer.
>
> fp->for_each
>
> Even if without ADL, id-expression allows qualified-id so a tool just
> list up all viable functions:
>
> fp->std::for_each
>
>
> This is only considering the standard library, I think users also
> wrote many too generic functions like this.
> Combining those, auto completion candidates will bloat up with
> completely unrelated generic function names user don't expect it to be
> suggested.
>
>
> I don't think tool support situation will be any better with this proposa=
l.
> It may be worse because candidate bloat up also affect existing class
> types and overwhelm the result.
>
> Very common types(like const char *, long double etc) and class types
> which has user defined conversion to common types now shows all sort
> of common functions as well as user defined literals!
>
> long double ld ;
> ld.operator "" il() ; // std::complex<long double>
>
>
> What do you think?


I agree, the argument that this would improve tool support falls *very*
flat for me. Even if it were true, I (speaking in part as a tool vendor)
don't think we should convolute the language to support such things.
Instead, if you want tool support for the above, get your tools to complete

  fp->fs|

.... to ...

  fseek(fp, |

I don't see why any language changes are needed for this.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--bcaec52d50fb6d1dae05066c56bf
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, Oct 27, 2014 at 1:24 AM, Ryou Ezoe <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:boostcpp@gmail.com" target=3D"_blank">boostcpp@gmail.com</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">I have some comments on N4165/N41=
74.<br>
<br>
1. weird code<br>
It&#39;s my understanding that under this proposal, following code is well-=
formed.<br>
<br>
4.0.sqrt() ;<br>
&quot;hello&quot;.puts() ;<br>
<br>
Is this correct?<br></blockquote><div><br></div><div>Well, you&#39;d need t=
o write</div><div><br></div><div>4.0 .sqrt();</div><div><br></div><div>... =
or the second period is part of an ill-formed &quot;4.0.&quot; literal.</di=
v><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">
If so and If we allow N4165&#39;s &quot;Additionally allow =E2=80=9Cthis=E2=
=80=9D in not only<br>
the first parameter location&quot;,<br>
It does allow this:<br>
<br>
fp-&gt;fputs(&quot;hello&quot;) ;<br>
<br>
as well as this:<br>
<br>
&quot;hello&quot;-&gt;fputs(fp) ;<br>
<br>
<br>
2. Tool support<br>
The papers wrote about better tool support.<br>
Although I agree with the idea, there are so many too generic function<br>
templates in the standard library that bloat up the auto completion<br>
candidates.<br>
Like move, swap, addressof.<br>
<br>
Without some constrained template features like concept or some hard<br>
coded/heuristic restriction on tool implementation,<br>
a set of auto completion name candidates are indeed smaller than free<br>
functions, but not that small enough.<br>
<br>
Consider FILE from &lt;stdio.h&gt;.<br>
The paper said it can auto complete fseek.<br>
<br>
FILE * fp ;<br>
fp-&gt;fseek<br>
<br>
It looks nice.<br>
<br>
But, Annex D.5 said C headers are deprecated and we should use C++<br>
header(&lt;cstdio&gt;) instead.<br>
So we should write like this:<br>
<br>
std::FILE * fp =3D ... ;<br>
<br>
This add std namespace to fp&#39;s associated namespace so all standard<br>
library names are on the candidate list.<br>
<br>
Suppose we also #included &lt;algorithm&gt; and wrote:<br>
<br>
fp-&gt;<br>
<br>
Tool suggest all &lt;algorithm&gt; function templates because fp is a point=
er.<br>
<br>
fp-&gt;for_each<br>
<br>
Even if without ADL, id-expression allows qualified-id so a tool just<br>
list up all viable functions:<br>
<br>
fp-&gt;std::for_each<br>
<br>
<br>
This is only considering the standard library, I think users also<br>
wrote many too generic functions like this.<br>
Combining those, auto completion candidates will bloat up with<br>
completely unrelated generic function names user don&#39;t expect it to be<=
br>
suggested.<br>
<br>
<br>
I don&#39;t think tool support situation will be any better with this propo=
sal.<br>
It may be worse because candidate bloat up also affect existing class<br>
types and overwhelm the result.<br>
<br>
Very common types(like const char *, long double etc) and class types<br>
which has user defined conversion to common types now shows all sort<br>
of common functions as well as user defined literals!<br>
<br>
long double ld ;<br>
ld.operator &quot;&quot; il() ; // std::complex&lt;long double&gt;<br>
<br>
<br>
What do you think?</blockquote><div><br></div><div>I agree, the argument th=
at this would improve tool support falls *very* flat for me. Even if it wer=
e true, I (speaking in part as a tool vendor) don&#39;t think we should con=
volute the language to support such things. Instead, if you want tool suppo=
rt for the above, get your tools to complete</div><div><br></div><div>=C2=
=A0 fp-&gt;fs|</div><div><br></div><div>... to ...</div><div><br></div><div=
>=C2=A0 fseek(fp, |</div><div><br></div><div>I don&#39;t see why any langua=
ge changes are needed for this.</div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--bcaec52d50fb6d1dae05066c56bf--

.

------=_Part_1028_1376346382.1414701272278
Content-Type: text/plain; charset=UTF-8

This proposal is AMAZING.
its' my single biggest complaint with C++ (r.e. magnitude of pain , vs cost
of adding this fix)

C++ has a big draw to member functions , precisely for autocomplete &
convenient chaining a.foo().bar()...
whilst free functions are vastly superior for encapsulation.
headers would be easier to generate. (don't have to adjust the signatures)

I've seen entire source bases thrown away needlessly over this sort of
thing, and am personally so sick to death of the useless choice between
them.

I've been looking into Rust, driven mostly by this single issue (in Rust ,
you have struct{} , imp{}.. and bolt more impls' on, getting a.foo() syntax
everywhere.)

r.e. bloating the autocomplete drop box, thats not a problem -surely you
should just list the members first, free functions second.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">This proposal is AMAZING.<br><div>its' my single biggest c=
omplaint with C++ (r.e. magnitude of pain , vs cost of adding this fix)</di=
v><div><br></div><div>C++ has a big draw to member functions , precisely fo=
r autocomplete &amp; convenient chaining a.foo().bar()...</div><div>whilst =
free functions are vastly superior for encapsulation.</div><div>headers wou=
ld be easier to generate. (don't have to adjust the signatures)</div><div><=
br></div><div>I've seen entire source bases thrown away needlessly over thi=
s sort of thing, and am personally so sick to death of the useless choice b=
etween them.</div><div><br></div><div>I've been looking into Rust, driven m=
ostly by this single issue (in Rust , you have struct{} , imp{}.. and bolt =
more impls' on, getting a.foo() syntax everywhere.)</div><div><br></div><di=
v>r.e. bloating the autocomplete drop box, thats not a problem -surely you =
should just list the members first, free functions second.</div><div><br></=
div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1028_1376346382.1414701272278--

.

------=_Part_1131_19634979.1425227640356
Content-Type: multipart/alternative;
 boundary="----=_Part_1132_1440094062.1425227640356"

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



Dne pond=C4=9Bl=C3=AD 27. =C5=99=C3=ADjna 2014 9:24:31 UTC+1 Ryou Ezoe naps=
al(a):
>
> 4.0.sqrt() ;=20
> "hello".puts() ;=20
>
=20
These seem to me quite unconventional too. But every new thing=20
is unconventional at first. If we can't name any rational reason why it's=
=20
not safe, then why not to allow it, if it helps at many other places.


The real goal of these papers seems to me very similar to the intent of=20
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1742.pdf. I'm not=
=20
sure why that proposal was rejected (forgotten?). I personally like it more=
 *(except=20
the keywords been used)*, because in my opinion it is even more useful as=
=20
not only public members could be accessed, if the caller of the extension=
=20
method had protected/private rights to the class/struct *(possible to=20
create an internal implementation extension with all private methods just=
=20
inside the .cpp file)*.

The only problem I can think of *(and probably could be fixed by some kind=
=20
of additional attribute keyword)* is inheritance and related stuff.
This reminds me of the fact that I didn't find any comment on inheritance=
=20
in the N4165 (I might just overlooked it though). Let's consider this=20
example:

struct X {
   void f() { std::cout << "X::f called"; }
};

struct Y : X {};

void f(Y y) { std::cout << "f(Y) called"; }


void main() {
   Y y;
   y.f();
};
.... what's going to be the output of this program? Due to backward=20
compatibility of the language it has to be X::f called. Similar cases could=
=20
bring more complexity into the language *(at least to me this doesn't seem=
=20
that obvious)*, but that's just my personal opinion, nothing serious :)

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr"><br><br>Dne pond=C4=9Bl=C3=AD 27. =C5=99=C3=ADjna 2014 9:2=
4:31 UTC+1 Ryou Ezoe napsal(a):<blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
>4.0.sqrt() ;
<br>"hello".puts() ;&nbsp;<br></blockquote><div>&nbsp;</div><div>These seem=
 to me quite unconventional too. But every new thing is&nbsp;unconventional=
 at first. If we can't name any rational reason why it's not safe, then why=
 not to allow it, if it helps at many other places.</div><div><br></div><di=
v><br></div><div>The real goal of these papers seems to me very similar to =
the intent of&nbsp;<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/p=
apers/2004/n1742.pdf" target=3D"_blank" rel=3D"nofollow" style=3D"cursor: p=
ointer;">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2004/<wbr>=
n1742.pdf</a>. I'm not sure why that proposal was rejected (forgotten?). I =
personally like it more <i>(except the keywords been used)</i>, because in =
my opinion it is even more useful as not only public members could be acces=
sed, if the caller of the extension method had protected/private rights to =
the class/struct <i>(possible to create an internal implementation extensio=
n with all private methods just inside the .cpp file)</i>.</div><div><br></=
div><div>The only problem I can think of <i>(and probably could be fixed by=
 some kind of additional attribute keyword)</i>&nbsp;is inheritance and rel=
ated stuff.</div><div>This reminds me of the fact that I didn't find any co=
mment on inheritance in the N4165 (I might just overlooked it though). Let'=
s consider this example:</div><div><br></div><div><div class=3D"prettyprint=
" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; bac=
kground-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><font color=3D"#660066"><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">struct</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> X </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br>&nbsp; &nbsp;</span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">void</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> f</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify">cout </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">&lt;&lt;</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #080;" class=3D"=
styled-by-prettify">"X::f called"</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #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><br></span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">struct</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> Y </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> X </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">{};</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=3D"st=
yled-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"=
>Y y</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</spa=
n></font><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">cout </span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">&lt;&lt;</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #080;" class=3D"s=
tyled-by-prettify">"f(Y) called"</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">}</span><font color=3D"#660066"><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br><br><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> main</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &n=
bsp;Y y</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &=
nbsp;y</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</s=
pan><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></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">};</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span></font></div></code></div></div=
><div>... what's going to be the output of this program? Due to backward co=
mpatibility of the language it has to be&nbsp;<span style=3D"color: rgb(0, =
136, 0); font-family: monospace; background-color: rgb(250, 250, 250);">X::=
f called</span>. Similar cases could bring more complexity into the languag=
e <i>(at least to me this doesn't seem that obvious)</i>, but that's just m=
y personal opinion, nothing serious :)</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1132_1440094062.1425227640356--
------=_Part_1131_19634979.1425227640356--

.

------=_Part_986_1642085308.1425330783904
Content-Type: multipart/alternative;
 boundary="----=_Part_987_1215423959.1425330783904"

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

I'm very keen on Bjarne's variant of the proposal.
As Walter says, I think it'll be amazingly useful.

I would like to see some more talk explaining what it initially recommend=
=20
regarding access to private members and the pros/cons of it but I'm keen=20
for this proposal to progress and look out for it's progress in each=20
mailing. I'm interested in what other people think of the proposal. I'm=20
particular interested to know if any compiler has speculatively implemented=
=20
it so I could play with it but that's probably wishful thinking.

On Monday, October 27, 2014 at 9:24:31 PM UTC+13, Ryou Ezoe wrote:

> I have some comments on N4165/N4174.=20
>
> 1. weird code=20
> It's my understanding that under this proposal, following code is=20
> well-formed.=20
>
> 4.0.sqrt() ;=20
> "hello".puts() ;=20
>
> Is this correct?=20
>
>
> If so and If we allow N4165's "Additionally allow =E2=80=9Cthis=E2=80=9D =
in not only=20
> the first parameter location",=20
> It does allow this:=20
>
> fp->fputs("hello") ;=20
>
> as well as this:=20
>
> "hello"->fputs(fp) ;=20
>
>
> 2. Tool support=20
> The papers wrote about better tool support.=20
> Although I agree with the idea, there are so many too generic function=20
> templates in the standard library that bloat up the auto completion=20
> candidates.=20
> Like move, swap, addressof.=20
>
> Without some constrained template features like concept or some hard=20
> coded/heuristic restriction on tool implementation,=20
> a set of auto completion name candidates are indeed smaller than free=20
> functions, but not that small enough.=20
>
> Consider FILE from <stdio.h>.=20
> The paper said it can auto complete fseek.=20
>
> FILE * fp ;=20
> fp->fseek=20
>
> It looks nice.=20
>
> But, Annex D.5 said C headers are deprecated and we should use C++=20
> header(<cstdio>) instead.=20
> So we should write like this:=20
>
> std::FILE * fp =3D ... ;=20
>
> This add std namespace to fp's associated namespace so all standard=20
> library names are on the candidate list.=20
>
> Suppose we also #included <algorithm> and wrote:=20
>
> fp->=20
>
> Tool suggest all <algorithm> function templates because fp is a pointer.=
=20
>
> fp->for_each=20
>
> Even if without ADL, id-expression allows qualified-id so a tool just=20
> list up all viable functions:=20
>
> fp->std::for_each=20
>
>
> This is only considering the standard library, I think users also=20
> wrote many too generic functions like this.=20
> Combining those, auto completion candidates will bloat up with=20
> completely unrelated generic function names user don't expect it to be=20
> suggested.=20
>
>
> I don't think tool support situation will be any better with this=20
> proposal.=20
> It may be worse because candidate bloat up also affect existing class=20
> types and overwhelm the result.=20
>
> Very common types(like const char *, long double etc) and class types=20
> which has user defined conversion to common types now shows all sort=20
> of common functions as well as user defined literals!=20
>
> long double ld ;=20
> ld.operator "" il() ; // std::complex<long double>=20
>
>
> What do you think?=20
>
> --=20
> Ryou Ezoe=20
>
> Occupation: DWANGO Co., Ltd.=20
>
> Blog:     http://cpplover.blogspot.com/=20
> Twitter: https://twitter.com/EzoeRyou=20
> GitHub: https://github.com/EzoeRyou=20
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr"><div>I'm very keen on Bjarne's variant of the proposal.</d=
iv><div>As Walter says, I think it'll be&nbsp;amazingly useful.</div><div><=
br></div><div>I would like to see some more talk&nbsp;explaining&nbsp;what =
it&nbsp;initially recommend regarding access to private members and&nbsp;th=
e pros/cons of it&nbsp;but I'm keen for this proposal to progress and look =
out for it's progress in each mailing.&nbsp;I'm&nbsp;interested in what oth=
er people think of the proposal. I'm particular interested to know if any c=
ompiler has speculatively implemented it so I could play with it but that's=
 probably wishful thinking.</div><div><br>On Monday, October 27, 2014 at 9:=
24:31 PM UTC+13, Ryou Ezoe wrote:</div><blockquote class=3D"gmail_quote" st=
yle=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;">I have =
some comments on N4165/N4174.
<br>
<br>1. weird code
<br>It's my understanding that under this proposal, following code is well-=
formed.
<br>
<br>4.0.sqrt() ;
<br>"hello".puts() ;
<br>
<br>Is this correct?
<br>
<br>
<br>If so and If we allow N4165's "Additionally allow =E2=80=9Cthis=E2=80=
=9D in not only
<br>the first parameter location",
<br>It does allow this:
<br>
<br>fp-&gt;fputs("hello") ;
<br>
<br>as well as this:
<br>
<br>"hello"-&gt;fputs(fp) ;
<br>
<br>
<br>2. Tool support
<br>The papers wrote about better tool support.
<br>Although I agree with the idea, there are so many too generic function
<br>templates in the standard library that bloat up the auto completion
<br>candidates.
<br>Like move, swap, addressof.
<br>
<br>Without some constrained template features like concept or some hard
<br>coded/heuristic restriction on tool implementation,
<br>a set of auto completion name candidates are indeed smaller than free
<br>functions, but not that small enough.
<br>
<br>Consider FILE from &lt;stdio.h&gt;.
<br>The paper said it can auto complete fseek.
<br>
<br>FILE * fp ;
<br>fp-&gt;fseek
<br>
<br>It looks nice.
<br>
<br>But, Annex D.5 said C headers are deprecated and we should use C++
<br>header(&lt;cstdio&gt;) instead.
<br>So we should write like this:
<br>
<br>std::FILE * fp =3D ... ;
<br>
<br>This add std namespace to fp's associated namespace so all standard
<br>library names are on the candidate list.
<br>
<br>Suppose we also #included &lt;algorithm&gt; and wrote:
<br>
<br>fp-&gt;
<br>
<br>Tool suggest all &lt;algorithm&gt; function templates because fp is a p=
ointer.
<br>
<br>fp-&gt;for_each
<br>
<br>Even if without ADL, id-expression allows qualified-id so a tool just
<br>list up all viable functions:
<br>
<br>fp-&gt;std::for_each
<br>
<br>
<br>This is only considering the standard library, I think users also
<br>wrote many too generic functions like this.
<br>Combining those, auto completion candidates will bloat up with
<br>completely unrelated generic function names user don't expect it to be
<br>suggested.
<br>
<br>
<br>I don't think tool support situation will be any better with this propo=
sal.
<br>It may be worse because candidate bloat up also affect existing class
<br>types and overwhelm the result.
<br>
<br>Very common types(like const char *, long double etc) and class types
<br>which has user defined conversion to common types now shows all sort
<br>of common functions as well as user defined literals!
<br>
<br>long double ld ;
<br>ld.operator "" il() ; // std::complex&lt;long double&gt;
<br>
<br>
<br>What do you think?
<br>
<br>--=20
<br>Ryou Ezoe
<br>
<br>Occupation: DWANGO Co., Ltd.
<br>
<br>Blog: &nbsp; &nbsp; <a onmousedown=3D"this.href=3D'http://www.google.co=
m/url?q\75http%3A%2F%2Fcpplover.blogspot.com%2F\46sa\75D\46sntz\0751\46usg\=
75AFQjCNFB9njSrdJmdDtzuKxuJVRjkMk6cQ';return true;" onclick=3D"this.href=3D=
'http://www.google.com/url?q\75http%3A%2F%2Fcpplover.blogspot.com%2F\46sa\7=
5D\46sntz\0751\46usg\75AFQjCNFB9njSrdJmdDtzuKxuJVRjkMk6cQ';return true;" hr=
ef=3D"http://cpplover.blogspot.com/" target=3D"_blank" rel=3D"nofollow">htt=
p://cpplover.blogspot.com/</a>
<br>Twitter: <a onmousedown=3D"this.href=3D'https://www.google.com/url?q\75=
https%3A%2F%2Ftwitter.com%2FEzoeRyou\46sa\75D\46sntz\0751\46usg\75AFQjCNELT=
FVRb6q-vfMMeNdx0ngU0b9vog';return true;" onclick=3D"this.href=3D'https://ww=
w.google.com/url?q\75https%3A%2F%2Ftwitter.com%2FEzoeRyou\46sa\75D\46sntz\0=
751\46usg\75AFQjCNELTFVRb6q-vfMMeNdx0ngU0b9vog';return true;" href=3D"https=
://twitter.com/EzoeRyou" target=3D"_blank" rel=3D"nofollow">https://twitter=
..com/EzoeRyou</a>
<br>GitHub: <a onmousedown=3D"this.href=3D'https://www.google.com/url?q\75h=
ttps%3A%2F%2Fgithub.com%2FEzoeRyou\46sa\75D\46sntz\0751\46usg\75AFQjCNGW0Le=
vPYeWQJpnehARuyNuugly6w';return true;" onclick=3D"this.href=3D'https://www.=
google.com/url?q\75https%3A%2F%2Fgithub.com%2FEzoeRyou\46sa\75D\46sntz\0751=
\46usg\75AFQjCNGW0LevPYeWQJpnehARuyNuugly6w';return true;" href=3D"https://=
github.com/EzoeRyou" target=3D"_blank" rel=3D"nofollow">https://github.com/=
EzoeRyou</a>
<br></blockquote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_987_1215423959.1425330783904--
------=_Part_986_1642085308.1425330783904--

.

------=_Part_3693_576688624.1425341266670
Content-Type: multipart/alternative;
 boundary="----=_Part_3694_812004657.1425341266670"

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

Personally I really like the idea of N4174, though several serious concerns=
,
1. f(x,y) means 1. First try x.f(y) =E2=80=93 does x=E2=80=99s class have a=
 member f? If so=20
try to use it 2. First try f(x,y) =E2=80=93 is there a function f? If so, t=
ry to=20
use it 3. otherwise error
This is totally wrong. We can have both f(x, y) and x.f(y) in the code, but=
=20
this new syntax blocks f(x, y) been called if x.f(y) exists.

2. The doc does not mention the scenario when an inheritance or implicit=20
conversion happened. i.e.

class B { public: void f() { } };
class D : B { };
void f(D&) { }

Which function will be called in the following scenarios?
a. B* i =3D new D(); i->f();
b. D i; i.f();

class B { public: virtual void f() =3D 0 };
class D : B { };
void f(D&) { }

Will the void f(D&) be considered as the override of B::f?

class B { };
class D : B { public: void f() { } };
void f(B&) { }

Which function will be called?
B* i =3D new D(); i->f();

class A { };
class B { public: operator A() { ... }; public: void f() { }; };
void f(A&) { }

Which function will be called when
B i; f(i);

3. c, v, cv, c&, v&, cv&, r-value reference ?
void f(const C&) { }
void f(C&) { }
void f(C) { }
void f(volatile const& C) { }
....

When
C i; i.f();
Which function should be called, should it be consistent with f(i)?

4. Will f(C*) be supported?

class C { };
void f(C*) { }
void f(C&) { }

Which function should be called?
C c; c.f(); (&c)->f();
C* c =3D new C(); c->f(); (*c).f();
It would be really funky, if the behavior of c.f() and (&c)->f() are=20
different.

5. nullptr?

class A { public: void f() { } };
class B { };
void f(B&) { }

Will the following calls crash?
A* a =3D nullptr;
f(a);
B* b =3D nullptr;
b->f();

And, how about
class A { };
void f(A*) { }
A* i =3D nullptr;
i->f();

Let's define all the cases we may have, and make this doc become the=20
standard. So involve the original authors of both 4165 and 4174.


On Tuesday, March 3, 2015 at 5:13:04 AM UTC+8, gmis...@gmail.com wrote:
>
> I'm very keen on Bjarne's variant of the proposal.
> As Walter says, I think it'll be amazingly useful.
>
> I would like to see some more talk explaining what it initially recommend=
=20
> regarding access to private members and the pros/cons of it but I'm keen=
=20
> for this proposal to progress and look out for it's progress in each=20
> mailing. I'm interested in what other people think of the proposal. I'm=
=20
> particular interested to know if any compiler has speculatively implement=
ed=20
> it so I could play with it but that's probably wishful thinking.
>
> On Monday, October 27, 2014 at 9:24:31 PM UTC+13, Ryou Ezoe wrote:
>
>> I have some comments on N4165/N4174.=20
>>
>> 1. weird code=20
>> It's my understanding that under this proposal, following code is=20
>> well-formed.=20
>>
>> 4.0.sqrt() ;=20
>> "hello".puts() ;=20
>>
>> Is this correct?=20
>>
>>
>> If so and If we allow N4165's "Additionally allow =E2=80=9Cthis=E2=80=9D=
 in not only=20
>> the first parameter location",=20
>> It does allow this:=20
>>
>> fp->fputs("hello") ;=20
>>
>> as well as this:=20
>>
>> "hello"->fputs(fp) ;=20
>>
>>
>> 2. Tool support=20
>> The papers wrote about better tool support.=20
>> Although I agree with the idea, there are so many too generic function=
=20
>> templates in the standard library that bloat up the auto completion=20
>> candidates.=20
>> Like move, swap, addressof.=20
>>
>> Without some constrained template features like concept or some hard=20
>> coded/heuristic restriction on tool implementation,=20
>> a set of auto completion name candidates are indeed smaller than free=20
>> functions, but not that small enough.=20
>>
>> Consider FILE from <stdio.h>.=20
>> The paper said it can auto complete fseek.=20
>>
>> FILE * fp ;=20
>> fp->fseek=20
>>
>> It looks nice.=20
>>
>> But, Annex D.5 said C headers are deprecated and we should use C++=20
>> header(<cstdio>) instead.=20
>> So we should write like this:=20
>>
>> std::FILE * fp =3D ... ;=20
>>
>> This add std namespace to fp's associated namespace so all standard=20
>> library names are on the candidate list.=20
>>
>> Suppose we also #included <algorithm> and wrote:=20
>>
>> fp->=20
>>
>> Tool suggest all <algorithm> function templates because fp is a pointer.=
=20
>>
>> fp->for_each=20
>>
>> Even if without ADL, id-expression allows qualified-id so a tool just=20
>> list up all viable functions:=20
>>
>> fp->std::for_each=20
>>
>>
>> This is only considering the standard library, I think users also=20
>> wrote many too generic functions like this.=20
>> Combining those, auto completion candidates will bloat up with=20
>> completely unrelated generic function names user don't expect it to be=
=20
>> suggested.=20
>>
>>
>> I don't think tool support situation will be any better with this=20
>> proposal.=20
>> It may be worse because candidate bloat up also affect existing class=20
>> types and overwhelm the result.=20
>>
>> Very common types(like const char *, long double etc) and class types=20
>> which has user defined conversion to common types now shows all sort=20
>> of common functions as well as user defined literals!=20
>>
>> long double ld ;=20
>> ld.operator "" il() ; // std::complex<long double>=20
>>
>>
>> What do you think?=20
>>
>> --=20
>> Ryou Ezoe=20
>>
>> Occupation: DWANGO Co., Ltd.=20
>>
>> Blog:     http://cpplover.blogspot.com/=20
>> Twitter: https://twitter.com/EzoeRyou=20
>> GitHub: https://github.com/EzoeRyou=20
>>
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr">Personally I really like the idea of N4174, though several=
 serious concerns,<div>1.&nbsp;f(x,y) means 1. First try x.f(y) =E2=80=93 d=
oes x=E2=80=99s class have a member f? If so try to use it 2. First try f(x=
,y) =E2=80=93 is there a function f? If so, try to use it 3. otherwise erro=
r</div><div>This is totally wrong. We can have both f(x, y) and x.f(y) in t=
he code, but this new syntax blocks f(x, y) been called if x.f(y) exists.</=
div><div><br></div><div>2. The doc does not mention the scenario when an in=
heritance or implicit conversion happened. i.e.</div><div><br></div><div>cl=
ass B { public: void f() { } };</div><div>class D : B { };</div><div>void f=
(D&amp;) { }</div><div><br></div><div>Which function will be called in the =
following scenarios?</div><div>a. B* i =3D new D(); i-&gt;f();</div><div>b.=
 D i; i.f();</div><div><br></div><div>class B { public: virtual void f() =
=3D 0 };</div><div>class D : B { };</div><div>void f(D&amp;) { }</div><div>=
<br></div><div>Will the void f(D&amp;) be considered as the override of B::=
f?</div><div><br></div><div>class B { };</div><div>class D : B { public: vo=
id f() { } };</div><div>void f(B&amp;) { }</div><div><br></div><div>Which f=
unction will be called?</div><div>B* i =3D new D(); i-&gt;f();</div><div><b=
r></div><div>class A { };</div><div>class B { public: operator A() { ... };=
 public: void f() { }; };</div><div>void f(A&amp;) { }</div><div><br></div>=
<div>Which function will be called when</div><div>B i; f(i);</div><div><br>=
</div><div>3. c, v, cv, c&amp;, v&amp;, cv&amp;, r-value reference ?</div><=
div>void f(const C&amp;) { }</div><div>void f(C&amp;) { }</div><div>void f(=
C) { }</div><div>void f(volatile const&amp; C) { }</div><div>...</div><div>=
<br></div><div>When</div><div>C i; i.f();</div><div>Which function should b=
e called, should it be consistent with f(i)?</div><div><br></div><div>4. Wi=
ll f(C*) be supported?</div><div><br></div><div>class C { };</div><div>void=
 f(C*) { }</div><div>void f(C&amp;) { }</div><div><br></div><div>Which func=
tion should be called?</div><div>C c; c.f(); (&amp;c)-&gt;f();</div><div>C*=
 c =3D new C(); c-&gt;f(); (*c).f();</div><div>It would be really funky, if=
 the behavior of c.f() and (&amp;c)-&gt;f() are different.</div><div><br></=
div><div>5. nullptr?</div><div><br></div><div>class A { public: void f() { =
} };</div><div>class B { };</div><div>void f(B&amp;) { }</div><div><br></di=
v><div>Will the following calls crash?</div><div>A* a =3D nullptr;</div><di=
v>f(a);</div><div>B* b =3D nullptr;</div><div>b-&gt;f();</div><div><br></di=
v><div>And, how about</div><div>class A { };</div><div>void f(A*) { }</div>=
<div>A* i =3D nullptr;</div><div>i-&gt;f();</div><div><br></div><div>Let's =
define all the cases we may have, and make this doc become the standard. So=
 involve the original authors of both 4165 and 4174.</div><div><br></div><b=
r>On Tuesday, March 3, 2015 at 5:13:04 AM UTC+8, gmis...@gmail.com wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>I'm very k=
een on Bjarne's variant of the proposal.</div><div>As Walter says, I think =
it'll be&nbsp;amazingly useful.</div><div><br></div><div>I would like to se=
e some more talk&nbsp;explaining&nbsp;what it&nbsp;initially recommend rega=
rding access to private members and&nbsp;the pros/cons of it&nbsp;but I'm k=
een for this proposal to progress and look out for it's progress in each ma=
iling.&nbsp;I'm&nbsp;interested in what other people think of the proposal.=
 I'm particular interested to know if any compiler has speculatively implem=
ented it so I could play with it but that's probably wishful thinking.</div=
><div><br>On Monday, October 27, 2014 at 9:24:31 PM UTC+13, Ryou Ezoe wrote=
:</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;b=
order-left-style:solid">I have some comments on N4165/N4174.
<br>
<br>1. weird code
<br>It's my understanding that under this proposal, following code is well-=
formed.
<br>
<br>4.0.sqrt() ;
<br>"hello".puts() ;
<br>
<br>Is this correct?
<br>
<br>
<br>If so and If we allow N4165's "Additionally allow =E2=80=9Cthis=E2=80=
=9D in not only
<br>the first parameter location",
<br>It does allow this:
<br>
<br>fp-&gt;fputs("hello") ;
<br>
<br>as well as this:
<br>
<br>"hello"-&gt;fputs(fp) ;
<br>
<br>
<br>2. Tool support
<br>The papers wrote about better tool support.
<br>Although I agree with the idea, there are so many too generic function
<br>templates in the standard library that bloat up the auto completion
<br>candidates.
<br>Like move, swap, addressof.
<br>
<br>Without some constrained template features like concept or some hard
<br>coded/heuristic restriction on tool implementation,
<br>a set of auto completion name candidates are indeed smaller than free
<br>functions, but not that small enough.
<br>
<br>Consider FILE from &lt;stdio.h&gt;.
<br>The paper said it can auto complete fseek.
<br>
<br>FILE * fp ;
<br>fp-&gt;fseek
<br>
<br>It looks nice.
<br>
<br>But, Annex D.5 said C headers are deprecated and we should use C++
<br>header(&lt;cstdio&gt;) instead.
<br>So we should write like this:
<br>
<br>std::FILE * fp =3D ... ;
<br>
<br>This add std namespace to fp's associated namespace so all standard
<br>library names are on the candidate list.
<br>
<br>Suppose we also #included &lt;algorithm&gt; and wrote:
<br>
<br>fp-&gt;
<br>
<br>Tool suggest all &lt;algorithm&gt; function templates because fp is a p=
ointer.
<br>
<br>fp-&gt;for_each
<br>
<br>Even if without ADL, id-expression allows qualified-id so a tool just
<br>list up all viable functions:
<br>
<br>fp-&gt;std::for_each
<br>
<br>
<br>This is only considering the standard library, I think users also
<br>wrote many too generic functions like this.
<br>Combining those, auto completion candidates will bloat up with
<br>completely unrelated generic function names user don't expect it to be
<br>suggested.
<br>
<br>
<br>I don't think tool support situation will be any better with this propo=
sal.
<br>It may be worse because candidate bloat up also affect existing class
<br>types and overwhelm the result.
<br>
<br>Very common types(like const char *, long double etc) and class types
<br>which has user defined conversion to common types now shows all sort
<br>of common functions as well as user defined literals!
<br>
<br>long double ld ;
<br>ld.operator "" il() ; // std::complex&lt;long double&gt;
<br>
<br>
<br>What do you think?
<br>
<br>--=20
<br>Ryou Ezoe
<br>
<br>Occupation: DWANGO Co., Ltd.
<br>
<br>Blog: &nbsp; &nbsp; <a href=3D"http://cpplover.blogspot.com/" rel=3D"no=
follow" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com=
/url?q\75http%3A%2F%2Fcpplover.blogspot.com%2F\46sa\75D\46sntz\0751\46usg\7=
5AFQjCNFB9njSrdJmdDtzuKxuJVRjkMk6cQ';return true;" onclick=3D"this.href=3D'=
http://www.google.com/url?q\75http%3A%2F%2Fcpplover.blogspot.com%2F\46sa\75=
D\46sntz\0751\46usg\75AFQjCNFB9njSrdJmdDtzuKxuJVRjkMk6cQ';return true;">htt=
p://cpplover.blogspot.com/</a>
<br>Twitter: <a href=3D"https://twitter.com/EzoeRyou" rel=3D"nofollow" targ=
et=3D"_blank" onmousedown=3D"this.href=3D'https://www.google.com/url?q\75ht=
tps%3A%2F%2Ftwitter.com%2FEzoeRyou\46sa\75D\46sntz\0751\46usg\75AFQjCNELTFV=
Rb6q-vfMMeNdx0ngU0b9vog';return true;" onclick=3D"this.href=3D'https://www.=
google.com/url?q\75https%3A%2F%2Ftwitter.com%2FEzoeRyou\46sa\75D\46sntz\075=
1\46usg\75AFQjCNELTFVRb6q-vfMMeNdx0ngU0b9vog';return true;">https://twitter=
..com/EzoeRyou</a>
<br>GitHub: <a href=3D"https://github.com/EzoeRyou" rel=3D"nofollow" target=
=3D"_blank" onmousedown=3D"this.href=3D'https://www.google.com/url?q\75http=
s%3A%2F%2Fgithub.com%2FEzoeRyou\46sa\75D\46sntz\0751\46usg\75AFQjCNGW0LevPY=
eWQJpnehARuyNuugly6w';return true;" onclick=3D"this.href=3D'https://www.goo=
gle.com/url?q\75https%3A%2F%2Fgithub.com%2FEzoeRyou\46sa\75D\46sntz\0751\46=
usg\75AFQjCNGW0LevPYeWQJpnehARuyNuugly6w';return true;">https://github.com/=
EzoeRyou</a>
<br></blockquote></div></blockquote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_3694_812004657.1425341266670--
------=_Part_3693_576688624.1425341266670--

.

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



From: Zijie He [mailto:hzj_jie@hotmail.com]
Sent: Monday, March 02, 2015 7:08 PM
To: std-proposals@isocpp.org
Cc: gmisocpp@gmail.com; Stroustrup, Bjarne (ICT); hsutter@microsoft.com
Subject: Re: Comment on N4165, N4174

Personally I really like the idea of N4174, though several serious concerns=
,
1. f(x,y) means 1. First try x.f(y) =E2=80=93 does x=E2=80=99s class have a=
 member f? If so try to use it 2. First try f(x,y) =E2=80=93 is there a fun=
ction f? If so, try to use it 3. otherwise error
This is totally wrong. We can have both f(x, y) and x.f(y) in the code, but=
 this new syntax blocks f(x, y) been called if x.f(y) exists.


=C3=B0    =E2=80=9Ctotally wrong=E2=80=9D is not an argument. You are right=
 about the implication, and I conjecture that it is most often desirable. E=
xamples pro and con would be helpful. As it is, I might have to settle for =
what I consider an inferior solution because of compatibility concerns that=
 may be mistaken. Remember, a main motivator is to be able to write specifi=
cations/concepts that does not have to duplicate call syntaxes or chose bet=
ween them.

2. The doc does not mention the scenario when an inheritance or implicit co=
nversion happened. i.e.


=C3=B0    The proposal doesn=E2=80=99t go into that level of detail. Eventu=
ally it must, of course, but it looks to me like the resolutions of the exa=
mples you present (thanks) has straightforward unique technical answers.

class B { public: void f() { } };
class D : B { };
void f(D&) { }

Which function will be called in the following scenarios?
a. B* i =3D new D(); i->f();
b. D i; i.f();

class B { public: virtual void f() =3D 0 };
class D : B { };
void f(D&) { }

Will the void f(D&) be considered as the override of B::f?

class B { };
class D : B { public: void f() { } };
void f(B&) { }

Which function will be called?
B* i =3D new D(); i->f();

class A { };
class B { public: operator A() { ... }; public: void f() { }; };
void f(A&) { }

Which function will be called when
B i; f(i);

3. c, v, cv, c&, v&, cv&, r-value reference ?
void f(const C&) { }
void f(C&) { }
void f(C) { }
void f(volatile const& C) { }
....

When
C i; i.f();
Which function should be called, should it be consistent with f(i)?

4. Will f(C*) be supported?

class C { };
void f(C*) { }
void f(C&) { }

Which function should be called?
C c; c.f(); (&c)->f();
C* c =3D new C(); c->f(); (*c).f();
It would be really funky, if the behavior of c.f() and (&c)->f() are differ=
ent.

5. nullptr?

class A { public: void f() { } };
class B { };
void f(B&) { }

Will the following calls crash?
A* a =3D nullptr;
f(a);
B* b =3D nullptr;
b->f();

And, how about
class A { };
void f(A*) { }
A* i =3D nullptr;
i->f();

Let's define all the cases we may have, and make this doc become the standa=
rd. So involve the original authors of both 4165 and 4174.


On Tuesday, March 3, 2015 at 5:13:04 AM UTC+8, gmis...@gmail.com<mailto:gmi=
s...@gmail.com> wrote:
I'm very keen on Bjarne's variant of the proposal.
As Walter says, I think it'll be amazingly useful.

I would like to see some more talk explaining what it initially recommend r=
egarding access to private members and the pros/cons of it but I'm keen for=
 this proposal to progress and look out for it's progress in each mailing. =
I'm interested in what other people think of the proposal. I'm particular i=
nterested to know if any compiler has speculatively implemented it so I cou=
ld play with it but that's probably wishful thinking.

On Monday, October 27, 2014 at 9:24:31 PM UTC+13, Ryou Ezoe wrote:
I have some comments on N4165/N4174.

1. weird code
It's my understanding that under this proposal, following code is well-form=
ed.

4.0.sqrt() ;
"hello".puts() ;

Is this correct?


If so and If we allow N4165's "Additionally allow =E2=80=9Cthis=E2=80=9D in=
 not only
the first parameter location",
It does allow this:

fp->fputs("hello") ;

as well as this:

"hello"->fputs(fp) ;


2. Tool support
The papers wrote about better tool support.
Although I agree with the idea, there are so many too generic function
templates in the standard library that bloat up the auto completion
candidates.
Like move, swap, addressof.

Without some constrained template features like concept or some hard
coded/heuristic restriction on tool implementation,
a set of auto completion name candidates are indeed smaller than free
functions, but not that small enough.

Consider FILE from <stdio.h>.
The paper said it can auto complete fseek.

FILE * fp ;
fp->fseek

It looks nice.

But, Annex D.5 said C headers are deprecated and we should use C++
header(<cstdio>) instead.
So we should write like this:

std::FILE * fp =3D ... ;

This add std namespace to fp's associated namespace so all standard
library names are on the candidate list.

Suppose we also #included <algorithm> and wrote:

fp->

Tool suggest all <algorithm> function templates because fp is a pointer.

fp->for_each

Even if without ADL, id-expression allows qualified-id so a tool just
list up all viable functions:

fp->std::for_each


This is only considering the standard library, I think users also
wrote many too generic functions like this.
Combining those, auto completion candidates will bloat up with
completely unrelated generic function names user don't expect it to be
suggested.


I don't think tool support situation will be any better with this proposal.
It may be worse because candidate bloat up also affect existing class
types and overwhelm the result.

Very common types(like const char *, long double etc) and class types
which has user defined conversion to common types now shows all sort
of common functions as well as user defined literals!

long double ld ;
ld.operator "" il() ; // std::complex<long double>


What do you think?

--
Ryou Ezoe

Occupation: DWANGO Co., Ltd.

Blog:     http://cpplover.blogspot.com/
Twitter: https://twitter.com/EzoeRyou
GitHub: https://github.com/EzoeRyou


________________________________

NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinion=
s or views contained herein are not intended to be, and do not constitute, =
advice within the meaning of Section 975 of the Dodd-Frank Wall Street Refo=
rm and Consumer Protection Act. If you have received this communication in =
error, please destroy all electronic and paper copies; do not disclose, use=
 or act upon the information; and notify the sender immediately. Mistransmi=
ssion is not intended to waive confidentiality or privilege. Morgan Stanley=
 reserves the right, to the extent permitted under applicable law, to monit=
or electronic communications. This message is subject to terms available at=
 the following link: http://www.morganstanley.com/disclaimers If you cannot=
 access these links, please notify us by reply message and we will send the=
 contents to you. By messaging with Morgan Stanley you consent to the foreg=
oing.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<HTML xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<HEAD><!-- Template generated by Exclaimer Template Editor on 01:01:44 Tues=
day, 3 March 2015 -->
<STYLE type=3Dtext/css>P.400e3e3e-64a6-4ecc-8303-5846d8031cd9 {
 MARGIN: 0cm 0cm 0pt
}
LI.400e3e3e-64a6-4ecc-8303-5846d8031cd9 {
 MARGIN: 0cm 0cm 0pt
}
DIV.400e3e3e-64a6-4ecc-8303-5846d8031cd9 {
 MARGIN: 0cm 0cm 0pt
}
TABLE.400e3e3e-64a6-4ecc-8303-5846d8031cd9Table {
 MARGIN: 0cm 0cm 0pt
}
DIV.Section1 {
 page: Section1
}
</STYLE>

<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8" />
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)" />
<style><!--
/* Font Definitions */
@font-face
 {font-family:Wingdings;
 panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
 {font-family:Wingdings;
 panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
 {font-family:Calibri;
 panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
 {font-family:Tahoma;
 panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
 {margin:0in;
 margin-bottom:.0001pt;
 font-size:12.0pt;
 font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
 {mso-style-priority:99;
 color:blue;
 text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
 {mso-style-priority:99;
 color:purple;
 text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
 {mso-style-priority:34;
 margin-top:0in;
 margin-right:0in;
 margin-bottom:0in;
 margin-left:.5in;
 margin-bottom:.0001pt;
 font-size:12.0pt;
 font-family:"Times New Roman","serif";}
span.EmailStyle17
 {mso-style-type:personal-reply;
 font-family:"Calibri","sans-serif";
 color:#1F497D;}
..MsoChpDefault
 {mso-style-type:export-only;
 font-family:"Calibri","sans-serif";}
@page WordSection1
 {size:8.5in 11.0in;
 margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
 {page:WordSection1;}
/* List Definitions */
@list l0
 {mso-list-id:967468674;
 mso-list-type:hybrid;
 mso-list-template-ids:256257536 -466816562 67698691 67698693 67698689 6769=
8691 67698693 67698689 67698691 67698693;}
@list l0:level1
 {mso-level-number-format:bullet;
 mso-level-text:=EF=83=B0;
 mso-level-tab-stop:none;
 mso-level-number-position:left;
 text-indent:-.25in;
 font-family:Wingdings;
 mso-fareast-font-family:Calibri;
 mso-bidi-font-family:"Times New Roman";}
@list l0:level2
 {mso-level-number-format:bullet;
 mso-level-text:o;
 mso-level-tab-stop:none;
 mso-level-number-position:left;
 text-indent:-.25in;
 font-family:"Courier New";}
@list l0:level3
 {mso-level-number-format:bullet;
 mso-level-text:=EF=82=A7;
 mso-level-tab-stop:none;
 mso-level-number-position:left;
 text-indent:-.25in;
 font-family:Wingdings;}
@list l0:level4
 {mso-level-number-format:bullet;
 mso-level-text:=EF=82=B7;
 mso-level-tab-stop:none;
 mso-level-number-position:left;
 text-indent:-.25in;
 font-family:Symbol;}
@list l0:level5
 {mso-level-number-format:bullet;
 mso-level-text:o;
 mso-level-tab-stop:none;
 mso-level-number-position:left;
 text-indent:-.25in;
 font-family:"Courier New";}
@list l0:level6
 {mso-level-number-format:bullet;
 mso-level-text:=EF=82=A7;
 mso-level-tab-stop:none;
 mso-level-number-position:left;
 text-indent:-.25in;
 font-family:Wingdings;}
@list l0:level7
 {mso-level-number-format:bullet;
 mso-level-text:=EF=82=B7;
 mso-level-tab-stop:none;
 mso-level-number-position:left;
 text-indent:-.25in;
 font-family:Symbol;}
@list l0:level8
 {mso-level-number-format:bullet;
 mso-level-text:o;
 mso-level-tab-stop:none;
 mso-level-number-position:left;
 text-indent:-.25in;
 font-family:"Courier New";}
@list l0:level9
 {mso-level-number-format:bullet;
 mso-level-text:=EF=82=A7;
 mso-level-tab-stop:none;
 mso-level-number-position:left;
 text-indent:-.25in;
 font-family:Wingdings;}
ol
 {margin-bottom:0in;}
ul
 {margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</HEAD>

<BODY lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<P>
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3Dfont-size:11.0pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:#1F497D><o:p>&nbsp;</o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3Dfont-size:11.0pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:#1F497D><o:p>&nbsp;</o:p></span></p=
>
<p class=3D"MsoNormal"><b><span style=3Dfont-size:10.0pt;font-family:&quot;=
Tahoma&quot;,&quot;sans-serif&quot;>From:</span></b><span style=3Dfont-size=
:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;> Zijie He [ma=
ilto:hzj_jie@hotmail.com]
<br />
<b>Sent:</b> Monday, March 02, 2015 7:08 PM<br />
<b>To:</b> std-proposals@isocpp.org<br />
<b>Cc:</b> gmisocpp@gmail.com; Stroustrup, Bjarne (ICT); hsutter@microsoft.=
com<br />
<b>Subject:</b> Re: Comment on N4165, N4174<o:p></o:p></span></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<p class=3D"MsoNormal">Personally I really like the idea of N4174, though s=
everal serious concerns,<o:p></o:p></p>
<div>
<p class=3D"MsoNormal">1.&nbsp;f(x,y) means 1. First try x.f(y) =E2=80=93 d=
oes x=E2=80=99s class have a member f? If so try to use it 2. First try f(x=
,y) =E2=80=93 is there a function f? If so, try to use it 3. otherwise erro=
r<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">This is totally wrong. We can have both f(x, y) and =
x.f(y) in the code, but this new syntax blocks f(x, y) been called if x.f(y=
) exists.<o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3Dfont-size:11.0pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:#1F497D><o:p>&nbsp;</o:p></span></p=
>
<p class=3D"MsoListParagraph" style=3D"margin-left:0in;text-indent:0in;mso-=
list:l0 level1 lfo1">
<![if !supportLists]><span style=3Dfont-size:11.0pt;font-family:Wingdings;c=
olor:#1F497D><span style=3Dmso-list:Ignore>=C3=B0<span style=3D"font:7.0pt =
&quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style=3Dfont-size:11.0pt;font-family:&=
quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D>=E2=80=9Ctotally wr=
ong=E2=80=9D is not an argument. You are right about the implication, and I=
 conjecture that it is most often desirable. Examples pro and con would
 be helpful. As it is, I might have to settle for what I consider an inferi=
or solution because of compatibility concerns that may be mistaken. Remembe=
r, a main motivator is to be able to write specifications/concepts that doe=
s not have to duplicate call syntaxes
 or chose between them.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">2. The doc does not mention the scenario when an inh=
eritance or implicit conversion happened. i.e.<o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3Dfont-size:11.0pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:#1F497D><o:p>&nbsp;</o:p></span></p=
>
<p class=3D"MsoListParagraph" style=3D"margin-left:0in;text-indent:0in;mso-=
list:l0 level1 lfo1">
<![if !supportLists]><span style=3Dfont-size:11.0pt;font-family:Wingdings;c=
olor:#1F497D><span style=3Dmso-list:Ignore>=C3=B0<span style=3D"font:7.0pt =
&quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style=3Dfont-size:11.0pt;font-family:&=
quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D>The proposal doesn=
=E2=80=99t go into that level of detail. Eventually it must, of course, but=
 it looks to me like the resolutions of the examples you present
 (thanks) has straightforward unique technical answers.<o:p></o:p></span></=
p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">class B { public: void f() { } };<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">class D : B { };<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">void f(D&amp;) { }<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">Which function will be called in the following scena=
rios?<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">a. B* i =3D new D(); i-&gt;f();<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">b. D i; i.f();<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">class B { public: virtual void f() =3D 0 };<o:p></o:=
p></p>
</div>
<div>
<p class=3D"MsoNormal">class D : B { };<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">void f(D&amp;) { }<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">Will the void f(D&amp;) be considered as the overrid=
e of B::f?<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">class B { };<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">class D : B { public: void f() { } };<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">void f(B&amp;) { }<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">Which function will be called?<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">B* i =3D new D(); i-&gt;f();<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">class A { };<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">class B { public: operator A() { ... }; public: void=
 f() { }; };<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">void f(A&amp;) { }<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">Which function will be called when<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">B i; f(i);<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">3. c, v, cv, c&amp;, v&amp;, cv&amp;, r-value refere=
nce ?<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">void f(const C&amp;) { }<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">void f(C&amp;) { }<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">void f(C) { }<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">void f(volatile const&amp; C) { }<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">...<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">When<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">C i; i.f();<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">Which function should be called, should it be consis=
tent with f(i)?<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">4. Will f(C*) be supported?<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">class C { };<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">void f(C*) { }<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">void f(C&amp;) { }<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">Which function should be called?<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">C c; c.f(); (&amp;c)-&gt;f();<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">C* c =3D new C(); c-&gt;f(); (*c).f();<o:p></o:p></p=
>
</div>
<div>
<p class=3D"MsoNormal">It would be really funky, if the behavior of c.f() a=
nd (&amp;c)-&gt;f() are different.<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">5. nullptr?<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">class A { public: void f() { } };<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">class B { };<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">void f(B&amp;) { }<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">Will the following calls crash?<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">A* a =3D nullptr;<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">f(a);<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">B* b =3D nullptr;<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">b-&gt;f();<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">And, how about<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">class A { };<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">void f(A*) { }<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">A* i =3D nullptr;<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">i-&gt;f();<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">Let's define all the cases we may have, and make thi=
s doc become the standard. So involve the original authors of both 4165 and=
 4174.<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<p class=3D"MsoNormal"><br />
On Tuesday, March 3, 2015 at 5:13:04 AM UTC&#43;8, <a href=3D"mailto:gmis..=
..@gmail.com">
gmis...@gmail.com</a> wrote:<o:p></o:p></p>
<div>
<div>
<p class=3D"MsoNormal">I'm very keen on Bjarne's variant of the proposal.<o=
:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">As Walter says, I think it'll be&nbsp;amazingly usef=
ul.<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">I would like to see some more talk&nbsp;explaining&n=
bsp;what it&nbsp;initially recommend regarding access to private members an=
d&nbsp;the pros/cons of it&nbsp;but I'm keen for this proposal to progress =
and look out for it's progress in each mailing.&nbsp;I'm&nbsp;interested
 in what other people think of the proposal. I'm particular interested to k=
now if any compiler has speculatively implemented it so I could play with i=
t but that's probably wishful thinking.<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><br />
On Monday, October 27, 2014 at 9:24:31 PM UTC&#43;13, Ryou Ezoe wrote:<o:p>=
</o:p></p>
</div>
<blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i=
n 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class=3D"MsoNormal">I have some comments on N4165/N4174. <br />
<br />
1. weird code <br />
It's my understanding that under this proposal, following code is well-form=
ed. <br />
<br />
4.0.sqrt() ; <br />
&quot;hello&quot;.puts() ; <br />
<br />
Is this correct? <br />
<br />
<br />
If so and If we allow N4165's &quot;Additionally allow =E2=80=9Cthis=E2=80=
=9D in not only <br />
the first parameter location&quot;, <br />
It does allow this: <br />
<br />
fp-&gt;fputs(&quot;hello&quot;) ; <br />
<br />
as well as this: <br />
<br />
&quot;hello&quot;-&gt;fputs(fp) ; <br />
<br />
<br />
2. Tool support <br />
The papers wrote about better tool support. <br />
Although I agree with the idea, there are so many too generic function <br =
/>
templates in the standard library that bloat up the auto completion <br />
candidates. <br />
Like move, swap, addressof. <br />
<br />
Without some constrained template features like concept or some hard <br />
coded/heuristic restriction on tool implementation, <br />
a set of auto completion name candidates are indeed smaller than free <br /=
>
functions, but not that small enough. <br />
<br />
Consider FILE from &lt;stdio.h&gt;. <br />
The paper said it can auto complete fseek. <br />
<br />
FILE * fp ; <br />
fp-&gt;fseek <br />
<br />
It looks nice. <br />
<br />
But, Annex D.5 said C headers are deprecated and we should use C&#43;&#43; =
<br />
header(&lt;cstdio&gt;) instead. <br />
So we should write like this: <br />
<br />
std::FILE * fp =3D ... ; <br />
<br />
This add std namespace to fp's associated namespace so all standard <br />
library names are on the candidate list. <br />
<br />
Suppose we also #included &lt;algorithm&gt; and wrote: <br />
<br />
fp-&gt; <br />
<br />
Tool suggest all &lt;algorithm&gt; function templates because fp is a point=
er. <br />
<br />
fp-&gt;for_each <br />
<br />
Even if without ADL, id-expression allows qualified-id so a tool just <br /=
>
list up all viable functions: <br />
<br />
fp-&gt;std::for_each <br />
<br />
<br />
This is only considering the standard library, I think users also <br />
wrote many too generic functions like this. <br />
Combining those, auto completion candidates will bloat up with <br />
completely unrelated generic function names user don't expect it to be <br =
/>
suggested. <br />
<br />
<br />
I don't think tool support situation will be any better with this proposal.=
 <br />
It may be worse because candidate bloat up also affect existing class <br /=
>
types and overwhelm the result. <br />
<br />
Very common types(like const char *, long double etc) and class types <br /=
>
which has user defined conversion to common types now shows all sort <br />
of common functions as well as user defined literals! <br />
<br />
long double ld ; <br />
ld.operator &quot;&quot; il() ; // std::complex&lt;long double&gt; <br />
<br />
<br />
What do you think? <br />
<br />
-- <br />
Ryou Ezoe <br />
<br />
Occupation: DWANGO Co., Ltd. <br />
<br />
Blog: &nbsp; &nbsp; <a href=3D"http://cpplover.blogspot.com/" target=3D"_bl=
ank">http://cpplover.blogspot.com/</a>
<br />
Twitter: <a href=3D"https://twitter.com/EzoeRyou" target=3D"_blank">https:/=
/twitter.com/EzoeRyou</a>
<br />
GitHub: <a href=3D"https://github.com/EzoeRyou" target=3D"_blank">https://g=
ithub.com/EzoeRyou</a>
<o:p></o:p></p>
</blockquote>
</div>
</div>
</div>
<BR /><BR />
<HR id=3DHR1 />
<BR /><SPAN style=3D"FONT-FAMILY: Arial; COLOR: #808080; FONT-SIZE: 7.5pt">=
NOTICE:=20
Morgan Stanley is not acting as a municipal advisor and the opinions or vie=
ws=20
contained herein are not intended to be, and do not constitute, advice with=
in=20
the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consume=
r=20
Protection Act. If you have received this communication in error, please de=
stroy=20
all electronic and paper copies; do not disclose, use or act upon the=20
information; and notify the sender immediately. Mistransmission is not inte=
nded=20
to waive confidentiality or privilege. Morgan Stanley reserves the right, t=
o the=20
extent permitted under applicable law, to monitor electronic communications=
..=20
This message is subject to terms available at the following link: <A style=
=3D"FONT-FAMILY: Arial; COLOR: #808080; FONT-SIZE: 7.5pt" href=3D"http://ww=
w.morganstanley.com/disclaimers">http://www.morganstanley.com/disclaimers</=
A>=20
If you cannot access these links, please notify us by reply message and we =
will=20
send the contents to you. By messaging with Morgan Stanley you consent to t=
he=20
foregoing.</SPAN><BR />
<P></P>
<P></P>
<P></P></P></BODY>
</HTML>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--_000_B5B93905603D1043AB7FEC27AFEDD82408F8B44BRRWEX2006N2msad_--

.

------=_Part_5597_121893949.1425458719346
Content-Type: multipart/alternative;
 boundary="----=_Part_5598_2119685252.1425458719346"

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

To make sure there is no breaking change, this feature can only be enabled=
=20
if there is no other matches, the compiler has no other choice but only=20
throwing compiling error.
To the examples, if we are following 'no breaking change' principle, most=
=20
of cases should be straightforward. But I still believe both nullptr<5> and=
=20
C* / C& / C <4> are discussible.

On Wednesday, March 4, 2015 at 2:02:58 AM UTC+8, Stroustrup, Bjarne wrote:
>
>   =20
>
> =20
>
> *From:* Zijie He [mailto:hzj...@hotmail.com <javascript:>]=20
> *Sent:* Monday, March 02, 2015 7:08 PM
> *To:* std-pr...@isocpp.org <javascript:>
> *Cc:* gmis...@gmail.com <javascript:>; Stroustrup, Bjarne (ICT);=20
> hsu...@microsoft.com <javascript:>
> *Subject:* Re: Comment on N4165, N4174
>
> =20
> =20
> Personally I really like the idea of N4174, though several serious=20
> concerns,
> =20
> 1. f(x,y) means 1. First try x.f(y) =E2=80=93 does x=E2=80=99s class have=
 a member f? If=20
> so try to use it 2. First try f(x,y) =E2=80=93 is there a function f? If =
so, try to=20
> use it 3. otherwise error
> =20
> This is totally wrong. We can have both f(x, y) and x.f(y) in the code,=
=20
> but this new syntax blocks f(x, y) been called if x.f(y) exists.
>
> =20
>
> =C3=B0    =E2=80=9Ctotally wrong=E2=80=9D is not an argument. You are rig=
ht about the=20
> implication, and I conjecture that it is most often desirable. Examples p=
ro=20
> and con would be helpful. As it is, I might have to settle for what I=20
> consider an inferior solution because of compatibility concerns that may =
be=20
> mistaken. Remember, a main motivator is to be able to write=20
> specifications/concepts that does not have to duplicate call syntaxes or=
=20
> chose between them.
> =20
> =20
> =20
> 2. The doc does not mention the scenario when an inheritance or implicit=
=20
> conversion happened. i.e.
>
> =20
>
> =C3=B0    The proposal doesn=E2=80=99t go into that level of detail. Even=
tually it=20
> must, of course, but it looks to me like the resolutions of the examples=
=20
> you present (thanks) has straightforward unique technical answers.
> =20
> =20
> =20
> class B { public: void f() { } };
> =20
> class D : B { };
> =20
> void f(D&) { }
> =20
> =20
> =20
> Which function will be called in the following scenarios?
> =20
> a. B* i =3D new D(); i->f();
> =20
> b. D i; i.f();
> =20
> =20
> =20
> class B { public: virtual void f() =3D 0 };
> =20
> class D : B { };
> =20
> void f(D&) { }
> =20
> =20
> =20
> Will the void f(D&) be considered as the override of B::f?
> =20
> =20
> =20
> class B { };
> =20
> class D : B { public: void f() { } };
> =20
> void f(B&) { }
> =20
> =20
> =20
> Which function will be called?
> =20
> B* i =3D new D(); i->f();
> =20
> =20
> =20
> class A { };
> =20
> class B { public: operator A() { ... }; public: void f() { }; };
> =20
> void f(A&) { }
> =20
> =20
> =20
> Which function will be called when
> =20
> B i; f(i);
> =20
> =20
> =20
> 3. c, v, cv, c&, v&, cv&, r-value reference ?
> =20
> void f(const C&) { }
> =20
> void f(C&) { }
> =20
> void f(C) { }
> =20
> void f(volatile const& C) { }
> =20
> ...
> =20
> =20
> =20
> When
> =20
> C i; i.f();
> =20
> Which function should be called, should it be consistent with f(i)?
> =20
> =20
> =20
> 4. Will f(C*) be supported?
> =20
> =20
> =20
> class C { };
> =20
> void f(C*) { }
> =20
> void f(C&) { }
> =20
> =20
> =20
> Which function should be called?
> =20
> C c; c.f(); (&c)->f();
> =20
> C* c =3D new C(); c->f(); (*c).f();
> =20
> It would be really funky, if the behavior of c.f() and (&c)->f() are=20
> different.
> =20
> =20
> =20
> 5. nullptr?
> =20
> =20
> =20
> class A { public: void f() { } };
> =20
> class B { };
> =20
> void f(B&) { }
> =20
> =20
> =20
> Will the following calls crash?
> =20
> A* a =3D nullptr;
> =20
> f(a);
> =20
> B* b =3D nullptr;
> =20
> b->f();
> =20
> =20
> =20
> And, how about
> =20
> class A { };
> =20
> void f(A*) { }
> =20
> A* i =3D nullptr;
> =20
> i->f();
> =20
> =20
> =20
> Let's define all the cases we may have, and make this doc become the=20
> standard. So involve the original authors of both 4165 and 4174.
> =20
> =20
> =20
>
> On Tuesday, March 3, 2015 at 5:13:04 AM UTC+8, gmis...@gmail.com wrote:
> =20
> I'm very keen on Bjarne's variant of the proposal.
> =20
> As Walter says, I think it'll be amazingly useful.
> =20
> =20
> =20
> I would like to see some more talk explaining what it initially recommend=
=20
> regarding access to private members and the pros/cons of it but I'm keen=
=20
> for this proposal to progress and look out for it's progress in each=20
> mailing. I'm interested in what other people think of the proposal. I'm=
=20
> particular interested to know if any compiler has speculatively implement=
ed=20
> it so I could play with it but that's probably wishful thinking.
> =20
>
> On Monday, October 27, 2014 at 9:24:31 PM UTC+13, Ryou Ezoe wrote:
> =20
> I have some comments on N4165/N4174.=20
>
> 1. weird code=20
> It's my understanding that under this proposal, following code is=20
> well-formed.=20
>
> 4.0.sqrt() ;=20
> "hello".puts() ;=20
>
> Is this correct?=20
>
>
> If so and If we allow N4165's "Additionally allow =E2=80=9Cthis=E2=80=9D =
in not only=20
> the first parameter location",=20
> It does allow this:=20
>
> fp->fputs("hello") ;=20
>
> as well as this:=20
>
> "hello"->fputs(fp) ;=20
>
>
> 2. Tool support=20
> The papers wrote about better tool support.=20
> Although I agree with the idea, there are so many too generic function=20
> templates in the standard library that bloat up the auto completion=20
> candidates.=20
> Like move, swap, addressof.=20
>
> Without some constrained template features like concept or some hard=20
> coded/heuristic restriction on tool implementation,=20
> a set of auto completion name candidates are indeed smaller than free=20
> functions, but not that small enough.=20
>
> Consider FILE from <stdio.h>.=20
> The paper said it can auto complete fseek.=20
>
> FILE * fp ;=20
> fp->fseek=20
>
> It looks nice.=20
>
> But, Annex D.5 said C headers are deprecated and we should use C++=20
> header(<cstdio>) instead.=20
> So we should write like this:=20
>
> std::FILE * fp =3D ... ;=20
>
> This add std namespace to fp's associated namespace so all standard=20
> library names are on the candidate list.=20
>
> Suppose we also #included <algorithm> and wrote:=20
>
> fp->=20
>
> Tool suggest all <algorithm> function templates because fp is a pointer.=
=20
>
> fp->for_each=20
>
> Even if without ADL, id-expression allows qualified-id so a tool just=20
> list up all viable functions:=20
>
> fp->std::for_each=20
>
>
> This is only considering the standard library, I think users also=20
> wrote many too generic functions like this.=20
> Combining those, auto completion candidates will bloat up with=20
> completely unrelated generic function names user don't expect it to be=20
> suggested.=20
>
>
> I don't think tool support situation will be any better with this=20
> proposal.=20
> It may be worse because candidate bloat up also affect existing class=20
> types and overwhelm the result.=20
>
> Very common types(like const char *, long double etc) and class types=20
> which has user defined conversion to common types now shows all sort=20
> of common functions as well as user defined literals!=20
>
> long double ld ;=20
> ld.operator "" il() ; // std::complex<long double>=20
>
>
> What do you think?=20
>
> --=20
> Ryou Ezoe=20
>
> Occupation: DWANGO Co., Ltd.=20
>
> Blog:     http://cpplover.blogspot.com/=20
> Twitter: https://twitter.com/EzoeRyou=20
> GitHub: https://github.com/EzoeRyou=20
>
>  =20
>
> ------------------------------
>
> NOTICE: Morgan Stanley is not acting as a municipal advisor and the=20
> opinions or views contained herein are not intended to be, and do not=20
> constitute, advice within the meaning of Section 975 of the Dodd-Frank Wa=
ll=20
> Street Reform and Consumer Protection Act. If you have received this=20
> communication in error, please destroy all electronic and paper copies; d=
o=20
> not disclose, use or act upon the information; and notify the sender=20
> immediately. Mistransmission is not intended to waive confidentiality or=
=20
> privilege. Morgan Stanley reserves the right, to the extent permitted und=
er=20
> applicable law, to monitor electronic communications. This message is=20
> subject to terms available at the following link:=20
> http://www.morganstanley.com/disclaimers If you cannot access these=20
> links, please notify us by reply message and we will send the contents to=
=20
> you. By messaging with Morgan Stanley you consent to the foregoing.
>
>=20

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr">To make sure there is no breaking change, this feature can=
 only be enabled if there is no other matches, the compiler has no other ch=
oice but only throwing compiling error.<div>To the examples, if we are foll=
owing 'no breaking change' principle, most of cases should be straightforwa=
rd. But I still believe both nullptr&lt;5&gt; and C* / C&amp; / C &lt;4&gt;=
 are discussible.</div><div><br>On Wednesday, March 4, 2015 at 2:02:58 AM U=
TC+8, Stroustrup, Bjarne wrote:<blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
>








<div lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<p>
</p><div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">&nbsp;</span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">&nbsp;</span></p>
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Zijie He=
 [mailto:<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D=
"Y0XRrfjM7w0J" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';re=
turn true;" onclick=3D"this.href=3D'javascript:';return true;">hzj...@hotma=
il.com</a>]
<br>
<b>Sent:</b> Monday, March 02, 2015 7:08 PM<br>
<b>To:</b> <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"Y0XRrfjM7w0J" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:'=
;return true;" onclick=3D"this.href=3D'javascript:';return true;">std-pr...=
@isocpp.org</a><br>
<b>Cc:</b> <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"Y0XRrfjM7w0J" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:'=
;return true;" onclick=3D"this.href=3D'javascript:';return true;">gmis...@g=
mail.com</a>; Stroustrup, Bjarne (ICT); <a href=3D"javascript:" target=3D"_=
blank" gdf-obfuscated-mailto=3D"Y0XRrfjM7w0J" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascr=
ipt:';return true;">hsu...@microsoft.com</a><br>
<b>Subject:</b> Re: Comment on N4165, N4174</span></p>
<p class=3D"MsoNormal">&nbsp;</p>
<div>
<p class=3D"MsoNormal">Personally I really like the idea of N4174, though s=
everal serious concerns,</p>
<div>
<p class=3D"MsoNormal">1.&nbsp;f(x,y) means 1. First try x.f(y) =E2=80=93 d=
oes x=E2=80=99s class have a member f? If so try to use it 2. First try f(x=
,y) =E2=80=93 is there a function f? If so, try to use it 3. otherwise erro=
r</p>
</div>
<div>
<p class=3D"MsoNormal">This is totally wrong. We can have both f(x, y) and =
x.f(y) in the code, but this new syntax blocks f(x, y) been called if x.f(y=
) exists.</p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">&nbsp;</span></p>
<p style=3D"margin-left:0in;text-indent:0in">
<span style=3D"font-size:11.0pt;font-family:Wingdings;color:#1f497d"><span>=
=C3=B0<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&n=
bsp;
</span></span></span><span style=3D"font-size:11.0pt;font-family:&quot;Cali=
bri&quot;,&quot;sans-serif&quot;;color:#1f497d">=E2=80=9Ctotally wrong=E2=
=80=9D is not an argument. You are right about the implication, and I conje=
cture that it is most often desirable. Examples pro and con would
 be helpful. As it is, I might have to settle for what I consider an inferi=
or solution because of compatibility concerns that may be mistaken. Remembe=
r, a main motivator is to be able to write specifications/concepts that doe=
s not have to duplicate call syntaxes
 or chose between them.</span></p>
</div>
<div>
<p class=3D"MsoNormal">&nbsp;</p>
</div>
<div>
<p class=3D"MsoNormal">2. The doc does not mention the scenario when an inh=
eritance or implicit conversion happened. i.e.</p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">&nbsp;</span></p>
<p style=3D"margin-left:0in;text-indent:0in">
<span style=3D"font-size:11.0pt;font-family:Wingdings;color:#1f497d"><span>=
=C3=B0<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&n=
bsp;
</span></span></span><span style=3D"font-size:11.0pt;font-family:&quot;Cali=
bri&quot;,&quot;sans-serif&quot;;color:#1f497d">The proposal doesn=E2=80=99=
t go into that level of detail. Eventually it must, of course, but it looks=
 to me like the resolutions of the examples you present
 (thanks) has straightforward unique technical answers.</span></p>
</div>
<div>
<p class=3D"MsoNormal">&nbsp;</p>
</div>
<div>
<p class=3D"MsoNormal">class B { public: void f() { } };</p>
</div>
<div>
<p class=3D"MsoNormal">class D : B { };</p>
</div>
<div>
<p class=3D"MsoNormal">void f(D&amp;) { }</p>
</div>
<div>
<p class=3D"MsoNormal">&nbsp;</p>
</div>
<div>
<p class=3D"MsoNormal">Which function will be called in the following scena=
rios?</p>
</div>
<div>
<p class=3D"MsoNormal">a. B* i =3D new D(); i-&gt;f();</p>
</div>
<div>
<p class=3D"MsoNormal">b. D i; i.f();</p>
</div>
<div>
<p class=3D"MsoNormal">&nbsp;</p>
</div>
<div>
<p class=3D"MsoNormal">class B { public: virtual void f() =3D 0 };</p>
</div>
<div>
<p class=3D"MsoNormal">class D : B { };</p>
</div>
<div>
<p class=3D"MsoNormal">void f(D&amp;) { }</p>
</div>
<div>
<p class=3D"MsoNormal">&nbsp;</p>
</div>
<div>
<p class=3D"MsoNormal">Will the void f(D&amp;) be considered as the overrid=
e of B::f?</p>
</div>
<div>
<p class=3D"MsoNormal">&nbsp;</p>
</div>
<div>
<p class=3D"MsoNormal">class B { };</p>
</div>
<div>
<p class=3D"MsoNormal">class D : B { public: void f() { } };</p>
</div>
<div>
<p class=3D"MsoNormal">void f(B&amp;) { }</p>
</div>
<div>
<p class=3D"MsoNormal">&nbsp;</p>
</div>
<div>
<p class=3D"MsoNormal">Which function will be called?</p>
</div>
<div>
<p class=3D"MsoNormal">B* i =3D new D(); i-&gt;f();</p>
</div>
<div>
<p class=3D"MsoNormal">&nbsp;</p>
</div>
<div>
<p class=3D"MsoNormal">class A { };</p>
</div>
<div>
<p class=3D"MsoNormal">class B { public: operator A() { ... }; public: void=
 f() { }; };</p>
</div>
<div>
<p class=3D"MsoNormal">void f(A&amp;) { }</p>
</div>
<div>
<p class=3D"MsoNormal">&nbsp;</p>
</div>
<div>
<p class=3D"MsoNormal">Which function will be called when</p>
</div>
<div>
<p class=3D"MsoNormal">B i; f(i);</p>
</div>
<div>
<p class=3D"MsoNormal">&nbsp;</p>
</div>
<div>
<p class=3D"MsoNormal">3. c, v, cv, c&amp;, v&amp;, cv&amp;, r-value refere=
nce ?</p>
</div>
<div>
<p class=3D"MsoNormal">void f(const C&amp;) { }</p>
</div>
<div>
<p class=3D"MsoNormal">void f(C&amp;) { }</p>
</div>
<div>
<p class=3D"MsoNormal">void f(C) { }</p>
</div>
<div>
<p class=3D"MsoNormal">void f(volatile const&amp; C) { }</p>
</div>
<div>
<p class=3D"MsoNormal">...</p>
</div>
<div>
<p class=3D"MsoNormal">&nbsp;</p>
</div>
<div>
<p class=3D"MsoNormal">When</p>
</div>
<div>
<p class=3D"MsoNormal">C i; i.f();</p>
</div>
<div>
<p class=3D"MsoNormal">Which function should be called, should it be consis=
tent with f(i)?</p>
</div>
<div>
<p class=3D"MsoNormal">&nbsp;</p>
</div>
<div>
<p class=3D"MsoNormal">4. Will f(C*) be supported?</p>
</div>
<div>
<p class=3D"MsoNormal">&nbsp;</p>
</div>
<div>
<p class=3D"MsoNormal">class C { };</p>
</div>
<div>
<p class=3D"MsoNormal">void f(C*) { }</p>
</div>
<div>
<p class=3D"MsoNormal">void f(C&amp;) { }</p>
</div>
<div>
<p class=3D"MsoNormal">&nbsp;</p>
</div>
<div>
<p class=3D"MsoNormal">Which function should be called?</p>
</div>
<div>
<p class=3D"MsoNormal">C c; c.f(); (&amp;c)-&gt;f();</p>
</div>
<div>
<p class=3D"MsoNormal">C* c =3D new C(); c-&gt;f(); (*c).f();</p>
</div>
<div>
<p class=3D"MsoNormal">It would be really funky, if the behavior of c.f() a=
nd (&amp;c)-&gt;f() are different.</p>
</div>
<div>
<p class=3D"MsoNormal">&nbsp;</p>
</div>
<div>
<p class=3D"MsoNormal">5. nullptr?</p>
</div>
<div>
<p class=3D"MsoNormal">&nbsp;</p>
</div>
<div>
<p class=3D"MsoNormal">class A { public: void f() { } };</p>
</div>
<div>
<p class=3D"MsoNormal">class B { };</p>
</div>
<div>
<p class=3D"MsoNormal">void f(B&amp;) { }</p>
</div>
<div>
<p class=3D"MsoNormal">&nbsp;</p>
</div>
<div>
<p class=3D"MsoNormal">Will the following calls crash?</p>
</div>
<div>
<p class=3D"MsoNormal">A* a =3D nullptr;</p>
</div>
<div>
<p class=3D"MsoNormal">f(a);</p>
</div>
<div>
<p class=3D"MsoNormal">B* b =3D nullptr;</p>
</div>
<div>
<p class=3D"MsoNormal">b-&gt;f();</p>
</div>
<div>
<p class=3D"MsoNormal">&nbsp;</p>
</div>
<div>
<p class=3D"MsoNormal">And, how about</p>
</div>
<div>
<p class=3D"MsoNormal">class A { };</p>
</div>
<div>
<p class=3D"MsoNormal">void f(A*) { }</p>
</div>
<div>
<p class=3D"MsoNormal">A* i =3D nullptr;</p>
</div>
<div>
<p class=3D"MsoNormal">i-&gt;f();</p>
</div>
<div>
<p class=3D"MsoNormal">&nbsp;</p>
</div>
<div>
<p class=3D"MsoNormal">Let's define all the cases we may have, and make thi=
s doc become the standard. So involve the original authors of both 4165 and=
 4174.</p>
</div>
<div>
<p class=3D"MsoNormal">&nbsp;</p>
</div>
<p class=3D"MsoNormal"><br>
On Tuesday, March 3, 2015 at 5:13:04 AM UTC+8, <a>
gmis...@gmail.com</a> wrote:</p>
<div>
<div>
<p class=3D"MsoNormal">I'm very keen on Bjarne's variant of the proposal.</=
p>
</div>
<div>
<p class=3D"MsoNormal">As Walter says, I think it'll be&nbsp;amazingly usef=
ul.</p>
</div>
<div>
<p class=3D"MsoNormal">&nbsp;</p>
</div>
<div>
<p class=3D"MsoNormal">I would like to see some more talk&nbsp;explaining&n=
bsp;what it&nbsp;initially recommend regarding access to private members an=
d&nbsp;the pros/cons of it&nbsp;but I'm keen for this proposal to progress =
and look out for it's progress in each mailing.&nbsp;I'm&nbsp;interested
 in what other people think of the proposal. I'm particular interested to k=
now if any compiler has speculatively implemented it so I could play with i=
t but that's probably wishful thinking.</p>
</div>
<div>
<p class=3D"MsoNormal"><br>
On Monday, October 27, 2014 at 9:24:31 PM UTC+13, Ryou Ezoe wrote:</p>
</div>
<blockquote style=3D"border:none;border-left:solid #cccccc 1.0pt;padding:0i=
n 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class=3D"MsoNormal">I have some comments on N4165/N4174. <br>
<br>
1. weird code <br>
It's my understanding that under this proposal, following code is well-form=
ed. <br>
<br>
4.0.sqrt() ; <br>
"hello".puts() ; <br>
<br>
Is this correct? <br>
<br>
<br>
If so and If we allow N4165's "Additionally allow =E2=80=9Cthis=E2=80=9D in=
 not only <br>
the first parameter location", <br>
It does allow this: <br>
<br>
fp-&gt;fputs("hello") ; <br>
<br>
as well as this: <br>
<br>
"hello"-&gt;fputs(fp) ; <br>
<br>
<br>
2. Tool support <br>
The papers wrote about better tool support. <br>
Although I agree with the idea, there are so many too generic function <br>
templates in the standard library that bloat up the auto completion <br>
candidates. <br>
Like move, swap, addressof. <br>
<br>
Without some constrained template features like concept or some hard <br>
coded/heuristic restriction on tool implementation, <br>
a set of auto completion name candidates are indeed smaller than free <br>
functions, but not that small enough. <br>
<br>
Consider FILE from &lt;stdio.h&gt;. <br>
The paper said it can auto complete fseek. <br>
<br>
FILE * fp ; <br>
fp-&gt;fseek <br>
<br>
It looks nice. <br>
<br>
But, Annex D.5 said C headers are deprecated and we should use C++ <br>
header(&lt;cstdio&gt;) instead. <br>
So we should write like this: <br>
<br>
std::FILE * fp =3D ... ; <br>
<br>
This add std namespace to fp's associated namespace so all standard <br>
library names are on the candidate list. <br>
<br>
Suppose we also #included &lt;algorithm&gt; and wrote: <br>
<br>
fp-&gt; <br>
<br>
Tool suggest all &lt;algorithm&gt; function templates because fp is a point=
er. <br>
<br>
fp-&gt;for_each <br>
<br>
Even if without ADL, id-expression allows qualified-id so a tool just <br>
list up all viable functions: <br>
<br>
fp-&gt;std::for_each <br>
<br>
<br>
This is only considering the standard library, I think users also <br>
wrote many too generic functions like this. <br>
Combining those, auto completion candidates will bloat up with <br>
completely unrelated generic function names user don't expect it to be <br>
suggested. <br>
<br>
<br>
I don't think tool support situation will be any better with this proposal.=
 <br>
It may be worse because candidate bloat up also affect existing class <br>
types and overwhelm the result. <br>
<br>
Very common types(like const char *, long double etc) and class types <br>
which has user defined conversion to common types now shows all sort <br>
of common functions as well as user defined literals! <br>
<br>
long double ld ; <br>
ld.operator "" il() ; // std::complex&lt;long double&gt; <br>
<br>
<br>
What do you think? <br>
<br>
-- <br>
Ryou Ezoe <br>
<br>
Occupation: DWANGO Co., Ltd. <br>
<br>
Blog: &nbsp; &nbsp; <a href=3D"http://cpplover.blogspot.com/" target=3D"_bl=
ank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.com/url=
?q\75http%3A%2F%2Fcpplover.blogspot.com%2F\46sa\75D\46sntz\0751\46usg\75AFQ=
jCNFB9njSrdJmdDtzuKxuJVRjkMk6cQ';return true;" onclick=3D"this.href=3D'http=
://www.google.com/url?q\75http%3A%2F%2Fcpplover.blogspot.com%2F\46sa\75D\46=
sntz\0751\46usg\75AFQjCNFB9njSrdJmdDtzuKxuJVRjkMk6cQ';return true;">http://=
cpplover.blogspot.com/</a>
<br>
Twitter: <a href=3D"https://twitter.com/EzoeRyou" target=3D"_blank" rel=3D"=
nofollow" onmousedown=3D"this.href=3D'https://www.google.com/url?q\75https%=
3A%2F%2Ftwitter.com%2FEzoeRyou\46sa\75D\46sntz\0751\46usg\75AFQjCNELTFVRb6q=
-vfMMeNdx0ngU0b9vog';return true;" onclick=3D"this.href=3D'https://www.goog=
le.com/url?q\75https%3A%2F%2Ftwitter.com%2FEzoeRyou\46sa\75D\46sntz\0751\46=
usg\75AFQjCNELTFVRb6q-vfMMeNdx0ngU0b9vog';return true;">https://twitter.com=
/EzoeRyou</a>
<br>
GitHub: <a href=3D"https://github.com/EzoeRyou" target=3D"_blank" rel=3D"no=
follow" onmousedown=3D"this.href=3D'https://www.google.com/url?q\75https%3A=
%2F%2Fgithub.com%2FEzoeRyou\46sa\75D\46sntz\0751\46usg\75AFQjCNGW0LevPYeWQJ=
pnehARuyNuugly6w';return true;" onclick=3D"this.href=3D'https://www.google.=
com/url?q\75https%3A%2F%2Fgithub.com%2FEzoeRyou\46sa\75D\46sntz\0751\46usg\=
75AFQjCNGW0LevPYeWQJpnehARuyNuugly6w';return true;">https://github.com/Ezoe=
Ryou</a>
</p>
</blockquote>
</div>
</div>
</div>
<br><br>
<hr>
<br><span style=3D"FONT-FAMILY:Arial;COLOR:#808080;FONT-SIZE:7.5pt">NOTICE:=
=20
Morgan Stanley is not acting as a municipal advisor and the opinions or vie=
ws=20
contained herein are not intended to be, and do not constitute, advice with=
in=20
the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consume=
r=20
Protection Act. If you have received this communication in error, please de=
stroy=20
all electronic and paper copies; do not disclose, use or act upon the=20
information; and notify the sender immediately. Mistransmission is not inte=
nded=20
to waive confidentiality or privilege. Morgan Stanley reserves the right, t=
o the=20
extent permitted under applicable law, to monitor electronic communications=
..=20
This message is subject to terms available at the following link: <a style=
=3D"FONT-FAMILY:Arial;COLOR:#808080;FONT-SIZE:7.5pt" href=3D"http://www.mor=
ganstanley.com/disclaimers" target=3D"_blank" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.morganstanl=
ey.com%2Fdisclaimers\46sa\75D\46sntz\0751\46usg\75AFQjCNG2wW3m_NdJdI_5MI7JC=
8MWS70fSA';return true;" onclick=3D"this.href=3D'http://www.google.com/url?=
q\75http%3A%2F%2Fwww.morganstanley.com%2Fdisclaimers\46sa\75D\46sntz\0751\4=
6usg\75AFQjCNG2wW3m_NdJdI_5MI7JC8MWS70fSA';return true;">http://www.morgans=
tanley.com/<wbr>disclaimers</a>=20
If you cannot access these links, please notify us by reply message and we =
will=20
send the contents to you. By messaging with Morgan Stanley you consent to t=
he=20
foregoing.</span><br>
<p></p>
<p></p>
<p></p><p></p></div>


</blockquote></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_5598_2119685252.1425458719346--
------=_Part_5597_121893949.1425458719346--

.

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

You are making assumptions here. I accept the need for some minor breakage =
in the cause of a significant improvement. I don=E2=80=99t yet know if this=
 is an example of that. Don=E2=80=99t close your mind too early.

From: Zijie He [mailto:hzj_jie@hotmail.com]
Sent: Wednesday, March 04, 2015 3:45 AM
To: std-proposals@isocpp.org
Cc: hzj_jie@hotmail.com; gmisocpp@gmail.com; hsutter@microsoft.com; Stroust=
rup, Bjarne (ICT)
Subject: Re: Comment on N4165, N4174

To make sure there is no breaking change, this feature can only be enabled =
if there is no other matches, the compiler has no other choice but only thr=
owing compiling error.
To the examples, if we are following 'no breaking change' principle, most o=
f cases should be straightforward. But I still believe both nullptr<5> and =
C* / C& / C <4> are discussible.

On Wednesday, March 4, 2015 at 2:02:58 AM UTC+8, Stroustrup, Bjarne wrote:


From: Zijie He [mailto:hzj...@hotmail.com<javascript:>]
Sent: Monday, March 02, 2015 7:08 PM
To: std-pr...@isocpp.org<javascript:>
Cc: gmis...@gmail.com<javascript:>; Stroustrup, Bjarne (ICT); hsu...@micros=
oft.com<javascript:>
Subject: Re: Comment on N4165, N4174

Personally I really like the idea of N4174, though several serious concerns=
,
1. f(x,y) means 1. First try x.f(y) =E2=80=93 does x=E2=80=99s class have a=
 member f? If so try to use it 2. First try f(x,y) =E2=80=93 is there a fun=
ction f? If so, try to use it 3. otherwise error
This is totally wrong. We can have both f(x, y) and x.f(y) in the code, but=
 this new syntax blocks f(x, y) been called if x.f(y) exists.


=3D>    =E2=80=9Ctotally wrong=E2=80=9D is not an argument. You are right a=
bout the implication, and I conjecture that it is most often desirable. Exa=
mples pro and con would be helpful. As it is, I might have to settle for wh=
at I consider an inferior solution because of compatibility concerns that m=
ay be mistaken. Remember, a main motivator is to be able to write specifica=
tions/concepts that does not have to duplicate call syntaxes or chose betwe=
en them.

2. The doc does not mention the scenario when an inheritance or implicit co=
nversion happened. i.e.


=3D>    The proposal doesn=E2=80=99t go into that level of detail. Eventual=
ly it must, of course, but it looks to me like the resolutions of the examp=
les you present (thanks) has straightforward unique technical answers.

class B { public: void f() { } };
class D : B { };
void f(D&) { }

Which function will be called in the following scenarios?
a. B* i =3D new D(); i->f();
b. D i; i.f();

class B { public: virtual void f() =3D 0 };
class D : B { };
void f(D&) { }

Will the void f(D&) be considered as the override of B::f?

class B { };
class D : B { public: void f() { } };
void f(B&) { }

Which function will be called?
B* i =3D new D(); i->f();

class A { };
class B { public: operator A() { ... }; public: void f() { }; };
void f(A&) { }

Which function will be called when
B i; f(i);

3. c, v, cv, c&, v&, cv&, r-value reference ?
void f(const C&) { }
void f(C&) { }
void f(C) { }
void f(volatile const& C) { }
....

When
C i; i.f();
Which function should be called, should it be consistent with f(i)?

4. Will f(C*) be supported?

class C { };
void f(C*) { }
void f(C&) { }

Which function should be called?
C c; c.f(); (&c)->f();
C* c =3D new C(); c->f(); (*c).f();
It would be really funky, if the behavior of c.f() and (&c)->f() are differ=
ent.

5. nullptr?

class A { public: void f() { } };
class B { };
void f(B&) { }

Will the following calls crash?
A* a =3D nullptr;
f(a);
B* b =3D nullptr;
b->f();

And, how about
class A { };
void f(A*) { }
A* i =3D nullptr;
i->f();

Let's define all the cases we may have, and make this doc become the standa=
rd. So involve the original authors of both 4165 and 4174.


On Tuesday, March 3, 2015 at 5:13:04 AM UTC+8, gmis...@gmail.com<mailto:gmi=
s...@gmail.com> wrote:
I'm very keen on Bjarne's variant of the proposal.
As Walter says, I think it'll be amazingly useful.

I would like to see some more talk explaining what it initially recommend r=
egarding access to private members and the pros/cons of it but I'm keen for=
 this proposal to progress and look out for it's progress in each mailing. =
I'm interested in what other people think of the proposal. I'm particular i=
nterested to know if any compiler has speculatively implemented it so I cou=
ld play with it but that's probably wishful thinking.

On Monday, October 27, 2014 at 9:24:31 PM UTC+13, Ryou Ezoe wrote:
I have some comments on N4165/N4174.

1. weird code
It's my understanding that under this proposal, following code is well-form=
ed.

4.0.sqrt() ;
"hello".puts() ;

Is this correct?


If so and If we allow N4165's "Additionally allow =E2=80=9Cthis=E2=80=9D in=
 not only
the first parameter location",
It does allow this:

fp->fputs("hello") ;

as well as this:

"hello"->fputs(fp) ;


2. Tool support
The papers wrote about better tool support.
Although I agree with the idea, there are so many too generic function
templates in the standard library that bloat up the auto completion
candidates.
Like move, swap, addressof.

Without some constrained template features like concept or some hard
coded/heuristic restriction on tool implementation,
a set of auto completion name candidates are indeed smaller than free
functions, but not that small enough.

Consider FILE from <stdio.h>.
The paper said it can auto complete fseek.

FILE * fp ;
fp->fseek

It looks nice.

But, Annex D.5 said C headers are deprecated and we should use C++
header(<cstdio>) instead.
So we should write like this:

std::FILE * fp =3D ... ;

This add std namespace to fp's associated namespace so all standard
library names are on the candidate list.

Suppose we also #included <algorithm> and wrote:

fp->

Tool suggest all <algorithm> function templates because fp is a pointer.

fp->for_each

Even if without ADL, id-expression allows qualified-id so a tool just
list up all viable functions:

fp->std::for_each


This is only considering the standard library, I think users also
wrote many too generic functions like this.
Combining those, auto completion candidates will bloat up with
completely unrelated generic function names user don't expect it to be
suggested.


I don't think tool support situation will be any better with this proposal.
It may be worse because candidate bloat up also affect existing class
types and overwhelm the result.

Very common types(like const char *, long double etc) and class types
which has user defined conversion to common types now shows all sort
of common functions as well as user defined literals!

long double ld ;
ld.operator "" il() ; // std::complex<long double>


What do you think?

--
Ryou Ezoe

Occupation: DWANGO Co., Ltd.

Blog:     http://cpplover.blogspot.com/
Twitter: https://twitter.com/EzoeRyou
GitHub: https://github.com/EzoeRyou

________________________________

NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinion=
s or views contained herein are not intended to be, and do not constitute, =
advice within the meaning of Section 975 of the Dodd-Frank Wall Street Refo=
rm and Consumer Protection Act. If you have received this communication in =
error, please destroy all electronic and paper copies; do not disclose, use=
 or act upon the information; and notify the sender immediately. Mistransmi=
ssion is not intended to waive confidentiality or privilege. Morgan Stanley=
 reserves the right, to the extent permitted under applicable law, to monit=
or electronic communications. This message is subject to terms available at=
 the following link: http://www.morganstanley.com/disclaimers If you cannot=
 access these links, please notify us by reply message and we will send the=
 contents to you. By messaging with Morgan Stanley you consent to the foreg=
oing.


________________________________

NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinion=
s or views contained herein are not intended to be, and do not constitute, =
advice within the meaning of Section 975 of the Dodd-Frank Wall Street Refo=
rm and Consumer Protection Act. If you have received this communication in =
error, please destroy all electronic and paper copies; do not disclose, use=
 or act upon the information; and notify the sender immediately. Mistransmi=
ssion is not intended to waive confidentiality or privilege. Morgan Stanley=
 reserves the right, to the extent permitted under applicable law, to monit=
or electronic communications. This message is subject to terms available at=
 the following link: http://www.morganstanley.com/disclaimers If you cannot=
 access these links, please notify us by reply message and we will send the=
 contents to you. By messaging with Morgan Stanley you consent to the foreg=
oing.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<HTML xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<HEAD><!-- Template generated by Exclaimer Template Editor on 10:24:57 Wedn=
esday, 4 March 2015 -->
<STYLE type=3Dtext/css>P.1a39adfe-2d69-4bd9-9b41-b8a59f0904b0 {
 MARGIN: 0cm 0cm 0pt
}
LI.1a39adfe-2d69-4bd9-9b41-b8a59f0904b0 {
 MARGIN: 0cm 0cm 0pt
}
DIV.1a39adfe-2d69-4bd9-9b41-b8a59f0904b0 {
 MARGIN: 0cm 0cm 0pt
}
TABLE.1a39adfe-2d69-4bd9-9b41-b8a59f0904b0Table {
 MARGIN: 0cm 0cm 0pt
}
DIV.Section1 {
 page: Section1
}
</STYLE>

<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8" />
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)" />
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
..shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
 {font-family:Wingdings;
 panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
 {font-family:Wingdings;
 panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
 {font-family:Calibri;
 panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
 {font-family:Tahoma;
 panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
 {margin:0in;
 margin-bottom:.0001pt;
 font-size:12.0pt;
 font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
 {mso-style-priority:99;
 color:blue;
 text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
 {mso-style-priority:99;
 color:purple;
 text-decoration:underline;}
p
 {mso-style-priority:99;
 mso-margin-top-alt:auto;
 margin-right:0in;
 mso-margin-bottom-alt:auto;
 margin-left:0in;
 font-size:12.0pt;
 font-family:"Times New Roman","serif";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
 {mso-style-priority:99;
 mso-style-link:"Balloon Text Char";
 margin:0in;
 margin-bottom:.0001pt;
 font-size:8.0pt;
 font-family:"Tahoma","sans-serif";}
span.EmailStyle18
 {mso-style-type:personal-reply;
 font-family:"Calibri","sans-serif";
 color:#1F497D;}
span.BalloonTextChar
 {mso-style-name:"Balloon Text Char";
 mso-style-priority:99;
 mso-style-link:"Balloon Text";
 font-family:"Tahoma","sans-serif";}
..MsoChpDefault
 {mso-style-type:export-only;
 font-family:"Calibri","sans-serif";}
@page WordSection1
 {size:8.5in 11.0in;
 margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
 {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</HEAD>

<BODY lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<P>
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3Dfont-size:11.0pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:#1F497D>You are making assumptions =
here. I accept the need for some minor breakage in the cause of a significa=
nt improvement. I don=E2=80=99t yet know if this is an example
 of that. Don=E2=80=99t close your mind too early.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3Dfont-size:11.0pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:#1F497D><o:p>&nbsp;</o:p></span></p=
>
<p class=3D"MsoNormal"><b><span style=3Dfont-size:10.0pt;font-family:&quot;=
Tahoma&quot;,&quot;sans-serif&quot;>From:</span></b><span style=3Dfont-size=
:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;> Zijie He [ma=
ilto:hzj_jie@hotmail.com]
<br />
<b>Sent:</b> Wednesday, March 04, 2015 3:45 AM<br />
<b>To:</b> std-proposals@isocpp.org<br />
<b>Cc:</b> hzj_jie@hotmail.com; gmisocpp@gmail.com; hsutter@microsoft.com; =
Stroustrup, Bjarne (ICT)<br />
<b>Subject:</b> Re: Comment on N4165, N4174<o:p></o:p></span></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<p class=3D"MsoNormal">To make sure there is no breaking change, this featu=
re can only be enabled if there is no other matches, the compiler has no ot=
her choice but only throwing compiling error.<o:p></o:p></p>
<div>
<p class=3D"MsoNormal">To the examples, if we are following 'no breaking ch=
ange' principle, most of cases should be straightforward. But I still belie=
ve both nullptr&lt;5&gt; and C* / C&amp; / C &lt;4&gt; are discussible.<o:p=
></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><br />
On Wednesday, March 4, 2015 at 2:02:58 AM UTC&#43;8, Stroustrup, Bjarne wro=
te:<o:p></o:p></p>
<div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto><span style=3Dfont-size:11.0pt;font-family:&quot;Calibri&quot;,&quot=
;sans-serif&quot;;color:#1F497D>&nbsp;</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto><span style=3Dfont-size:11.0pt;font-family:&quot;Calibri&quot;,&quot=
;sans-serif&quot;;color:#1F497D>&nbsp;</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto><b><span style=3Dfont-size:10.0pt;font-family:&quot;Tahoma&quot;,&qu=
ot;sans-serif&quot;>From:</span></b><span style=3Dfont-size:10.0pt;font-fam=
ily:&quot;Tahoma&quot;,&quot;sans-serif&quot;> Zijie He [mailto:<a href=3D"=
javascript:" target=3D"_blank">hzj...@hotmail.com</a>]
<br />
<b>Sent:</b> Monday, March 02, 2015 7:08 PM<br />
<b>To:</b> <a href=3D"javascript:" target=3D"_blank">std-pr...@isocpp.org</=
a><br />
<b>Cc:</b> <a href=3D"javascript:" target=3D"_blank">gmis...@gmail.com</a>;=
 Stroustrup, Bjarne (ICT);
<a href=3D"javascript:" target=3D"_blank">hsu...@microsoft.com</a><br />
<b>Subject:</b> Re: Comment on N4165, N4174</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>&nbsp;<o:p></o:p></p>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>Personally I really like the idea of N4174, though several serious c=
oncerns,<o:p></o:p></p>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>1.&nbsp;f(x,y) means 1. First try x.f(y) =E2=80=93 does x=E2=80=99s =
class have a member f? If so try to use it 2. First try f(x,y) =E2=80=93 is=
 there a function f? If so, try to use it 3. otherwise error<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>This is totally wrong. We can have both f(x, y) and x.f(y) in the co=
de, but this new syntax blocks f(x, y) been called if x.f(y) exists.<o:p></=
o:p></p>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto><span style=3Dfont-size:11.0pt;font-family:&quot;Calibri&quot;,&quot=
;sans-serif&quot;;color:#1F497D>&nbsp;</span><o:p></o:p></p>
<p><span style=3Dfont-size:11.0pt;font-family:Wingdings;color:#1F497D>=C3=
=B0</span><span style=3Dfont-size:7.0pt;color:#1F497D>&nbsp;&nbsp;&nbsp;
</span><span style=3Dfont-size:11.0pt;font-family:&quot;Calibri&quot;,&quot=
;sans-serif&quot;;color:#1F497D>=E2=80=9Ctotally wrong=E2=80=9D is not an a=
rgument. You are right about the implication, and I conjecture that it is m=
ost often desirable. Examples pro and con would be helpful. As it is,
 I might have to settle for what I consider an inferior solution because of=
 compatibility concerns that may be mistaken. Remember, a main motivator is=
 to be able to write specifications/concepts that does not have to duplicat=
e call syntaxes or chose between
 them.</span><o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>&nbsp;<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>2. The doc does not mention the scenario when an inheritance or impl=
icit conversion happened. i.e.<o:p></o:p></p>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto><span style=3Dfont-size:11.0pt;font-family:&quot;Calibri&quot;,&quot=
;sans-serif&quot;;color:#1F497D>&nbsp;</span><o:p></o:p></p>
<p><span style=3Dfont-size:11.0pt;font-family:Wingdings;color:#1F497D>=C3=
=B0</span><span style=3Dfont-size:7.0pt;color:#1F497D>&nbsp;&nbsp;&nbsp;
</span><span style=3Dfont-size:11.0pt;font-family:&quot;Calibri&quot;,&quot=
;sans-serif&quot;;color:#1F497D>The proposal doesn=E2=80=99t go into that l=
evel of detail. Eventually it must, of course, but it looks to me like the =
resolutions of the examples you present (thanks) has straightforward
 unique technical answers.</span><o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>&nbsp;<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>class B { public: void f() { } };<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>class D : B { };<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>void f(D&amp;) { }<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>&nbsp;<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>Which function will be called in the following scenarios?<o:p></o:p>=
</p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>a. B* i =3D new D(); i-&gt;f();<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>b. D i; i.f();<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>&nbsp;<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>class B { public: virtual void f() =3D 0 };<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>class D : B { };<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>void f(D&amp;) { }<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>&nbsp;<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>Will the void f(D&amp;) be considered as the override of B::f?<o:p><=
/o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>&nbsp;<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>class B { };<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>class D : B { public: void f() { } };<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>void f(B&amp;) { }<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>&nbsp;<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>Which function will be called?<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>B* i =3D new D(); i-&gt;f();<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>&nbsp;<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>class A { };<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>class B { public: operator A() { ... }; public: void f() { }; };<o:p=
></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>void f(A&amp;) { }<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>&nbsp;<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>Which function will be called when<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>B i; f(i);<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>&nbsp;<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>3. c, v, cv, c&amp;, v&amp;, cv&amp;, r-value reference ?<o:p></o:p>=
</p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>void f(const C&amp;) { }<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>void f(C&amp;) { }<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>void f(C) { }<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>void f(volatile const&amp; C) { }<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>...<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>&nbsp;<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>When<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>C i; i.f();<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>Which function should be called, should it be consistent with f(i)?<=
o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>&nbsp;<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>4. Will f(C*) be supported?<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>&nbsp;<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>class C { };<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>void f(C*) { }<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>void f(C&amp;) { }<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>&nbsp;<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>Which function should be called?<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>C c; c.f(); (&amp;c)-&gt;f();<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>C* c =3D new C(); c-&gt;f(); (*c).f();<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>It would be really funky, if the behavior of c.f() and (&amp;c)-&gt;=
f() are different.<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>&nbsp;<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>5. nullptr?<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>&nbsp;<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>class A { public: void f() { } };<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>class B { };<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>void f(B&amp;) { }<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>&nbsp;<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>Will the following calls crash?<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>A* a =3D nullptr;<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>f(a);<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>B* b =3D nullptr;<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>b-&gt;f();<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>&nbsp;<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>And, how about<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>class A { };<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>void f(A*) { }<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>A* i =3D nullptr;<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>i-&gt;f();<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>&nbsp;<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>Let's define all the cases we may have, and make this doc become the=
 standard. So involve the original authors of both 4165 and 4174.<o:p></o:p=
></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>&nbsp;<o:p></o:p></p>
</div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto><br />
On Tuesday, March 3, 2015 at 5:13:04 AM UTC&#43;8, <a href=3D"mailto:gmis..=
..@gmail.com">
gmis...@gmail.com</a> wrote:<o:p></o:p></p>
<div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>I'm very keen on Bjarne's variant of the proposal.<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>As Walter says, I think it'll be&nbsp;amazingly useful.<o:p></o:p></=
p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>&nbsp;<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>I would like to see some more talk&nbsp;explaining&nbsp;what it&nbsp=
;initially recommend regarding access to private members and&nbsp;the pros/=
cons of it&nbsp;but I'm keen for this proposal to progress
 and look out for it's progress in each mailing.&nbsp;I'm&nbsp;interested i=
n what other people think of the proposal. I'm particular interested to kno=
w if any compiler has speculatively implemented it so I could play with it =
but that's probably wishful thinking.<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto><br />
On Monday, October 27, 2014 at 9:24:31 PM UTC&#43;13, Ryou Ezoe wrote:<o:p>=
</o:p></p>
</div>
<blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i=
n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-=
bottom:5.0pt">
<p class=3D"MsoNormal" style=3Dmso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto>I have some comments on N4165/N4174.
<br />
<br />
1. weird code <br />
It's my understanding that under this proposal, following code is well-form=
ed. <br />
<br />
4.0.sqrt() ; <br />
&quot;hello&quot;.puts() ; <br />
<br />
Is this correct? <br />
<br />
<br />
If so and If we allow N4165's &quot;Additionally allow =E2=80=9Cthis=E2=80=
=9D in not only <br />
the first parameter location&quot;, <br />
It does allow this: <br />
<br />
fp-&gt;fputs(&quot;hello&quot;) ; <br />
<br />
as well as this: <br />
<br />
&quot;hello&quot;-&gt;fputs(fp) ; <br />
<br />
<br />
2. Tool support <br />
The papers wrote about better tool support. <br />
Although I agree with the idea, there are so many too generic function <br =
/>
templates in the standard library that bloat up the auto completion <br />
candidates. <br />
Like move, swap, addressof. <br />
<br />
Without some constrained template features like concept or some hard <br />
coded/heuristic restriction on tool implementation, <br />
a set of auto completion name candidates are indeed smaller than free <br /=
>
functions, but not that small enough. <br />
<br />
Consider FILE from &lt;stdio.h&gt;. <br />
The paper said it can auto complete fseek. <br />
<br />
FILE * fp ; <br />
fp-&gt;fseek <br />
<br />
It looks nice. <br />
<br />
But, Annex D.5 said C headers are deprecated and we should use C&#43;&#43; =
<br />
header(&lt;cstdio&gt;) instead. <br />
So we should write like this: <br />
<br />
std::FILE * fp =3D ... ; <br />
<br />
This add std namespace to fp's associated namespace so all standard <br />
library names are on the candidate list. <br />
<br />
Suppose we also #included &lt;algorithm&gt; and wrote: <br />
<br />
fp-&gt; <br />
<br />
Tool suggest all &lt;algorithm&gt; function templates because fp is a point=
er. <br />
<br />
fp-&gt;for_each <br />
<br />
Even if without ADL, id-expression allows qualified-id so a tool just <br /=
>
list up all viable functions: <br />
<br />
fp-&gt;std::for_each <br />
<br />
<br />
This is only considering the standard library, I think users also <br />
wrote many too generic functions like this. <br />
Combining those, auto completion candidates will bloat up with <br />
completely unrelated generic function names user don't expect it to be <br =
/>
suggested. <br />
<br />
<br />
I don't think tool support situation will be any better with this proposal.=
 <br />
It may be worse because candidate bloat up also affect existing class <br /=
>
types and overwhelm the result. <br />
<br />
Very common types(like const char *, long double etc) and class types <br /=
>
which has user defined conversion to common types now shows all sort <br />
of common functions as well as user defined literals! <br />
<br />
long double ld ; <br />
ld.operator &quot;&quot; il() ; // std::complex&lt;long double&gt; <br />
<br />
<br />
What do you think? <br />
<br />
-- <br />
Ryou Ezoe <br />
<br />
Occupation: DWANGO Co., Ltd. <br />
<br />
Blog: &nbsp; &nbsp; <a href=3D"http://cpplover.blogspot.com/" target=3D"_bl=
ank">http://cpplover.blogspot.com/</a>
<br />
Twitter: <a href=3D"https://twitter.com/EzoeRyou" target=3D"_blank">https:/=
/twitter.com/EzoeRyou</a>
<br />
GitHub: <a href=3D"https://github.com/EzoeRyou" target=3D"_blank">https://g=
ithub.com/EzoeRyou</a>
<o:p></o:p></p>
</blockquote>
</div>
</div>
</div>
<p class=3D"MsoNormal" style=3Dmargin-bottom:12.0pt><o:p>&nbsp;</o:p></p>
<div class=3D"MsoNormal" align=3D"center" style=3Dtext-align:center>
<hr size=3D"2" width=3D"100%" align=3D"center" />
</div>
<p class=3D"MsoNormal"><br />
<span style=3Dfont-size:7.5pt;font-family:&quot;Arial&quot;,&quot;sans-seri=
f&quot;;color:gray>NOTICE: Morgan Stanley is not acting as a municipal advi=
sor and the opinions or views contained herein are not intended to be, and =
do not constitute, advice within the meaning of Section
 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If y=
ou have received this communication in error, please destroy all electronic=
 and paper copies; do not disclose, use or act upon the information; and no=
tify the sender immediately. Mistransmission
 is not intended to waive confidentiality or privilege. Morgan Stanley rese=
rves the right, to the extent permitted under applicable law, to monitor el=
ectronic communications. This message is subject to terms available at the =
following link:
<a href=3D"http://www.morganstanley.com/disclaimers" target=3D"_blank"><spa=
n style=3Dcolor:gray>http://www.morganstanley.com/disclaimers</span></a> If=
 you cannot access these links, please notify us by reply message and we wi=
ll send the contents to you. By messaging
 with Morgan Stanley you consent to the foregoing.</span><o:p></o:p></p>
</div>
</div>
</div>
</div>
<BR /><BR />
<HR id=3DHR1 />
<BR /><SPAN style=3D"FONT-FAMILY: Arial; COLOR: #808080; FONT-SIZE: 7.5pt">=
NOTICE:=20
Morgan Stanley is not acting as a municipal advisor and the opinions or vie=
ws=20
contained herein are not intended to be, and do not constitute, advice with=
in=20
the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consume=
r=20
Protection Act. If you have received this communication in error, please de=
stroy=20
all electronic and paper copies; do not disclose, use or act upon the=20
information; and notify the sender immediately. Mistransmission is not inte=
nded=20
to waive confidentiality or privilege. Morgan Stanley reserves the right, t=
o the=20
extent permitted under applicable law, to monitor electronic communications=
..=20
This message is subject to terms available at the following link: <A style=
=3D"FONT-FAMILY: Arial; COLOR: #808080; FONT-SIZE: 7.5pt" href=3D"http://ww=
w.morganstanley.com/disclaimers">http://www.morganstanley.com/disclaimers</=
A>=20
If you cannot access these links, please notify us by reply message and we =
will=20
send the contents to you. By messaging with Morgan Stanley you consent to t=
he=20
foregoing.</SPAN><BR />
<P></P>
<P></P>
<P></P></P></BODY>
</HTML>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--_000_B5B93905603D1043AB7FEC27AFEDD82408F8BD6DRRWEX2006N2msad_--

.

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

> 2. The doc does not mention the scenario when an inheritance or implicit
conversion happened. i.e.

It seems to me the paper is perhaps too specific in its wording:

> x.f(y) means
>    1. First try x.f(y) =E2=80=93does x=E2=80=99s class have a member f? I=
f so try to use
it
>    2. Then try f(x,y) =E2=80=93 is there a function f? If so, try to use =
it
>    3. otherwise error

Saying "does x's class have a member f" unnecessarily constrains to the
immediate class type of x. Perhaps rephrasing it along the lines of "is f a
valid callable member function of x?" would readily account for the case of
inheritance. I assume the spirit of the paper is to state that code written
in the existing syntax today should continue to behave as it does, but only
in cases where this alternate syntax is used and the code would otherwise
not resolve to a member function call, consider an additional resolution
strategy for x.f(y).

As for "hello".puts();, although this would be possible per N4174, I don't
think it should be much of a concern. We can already write interesting
tidbits such as:

int nums[5] =3D {0, 1, 2, 3, 4};
cout << 3[nums] << endl;

But people often don't realize this is even possible. It doesn't cause
problems, so we tend to ignore it.


On Mon, Mar 2, 2015 at 7:07 PM Zijie He <hzj_jie@hotmail.com> wrote:

> Personally I really like the idea of N4174, though several serious
> concerns,
> 1. f(x,y) means 1. First try x.f(y) =E2=80=93 does x=E2=80=99s class have=
 a member f? If
> so try to use it 2. First try f(x,y) =E2=80=93 is there a function f? If =
so, try to
> use it 3. otherwise error
> This is totally wrong. We can have both f(x, y) and x.f(y) in the code,
> but this new syntax blocks f(x, y) been called if x.f(y) exists.
>
> 2. The doc does not mention the scenario when an inheritance or implicit
> conversion happened. i.e.
>
> class B { public: void f() { } };
> class D : B { };
> void f(D&) { }
>
> Which function will be called in the following scenarios?
> a. B* i =3D new D(); i->f();
> b. D i; i.f();
>
> class B { public: virtual void f() =3D 0 };
> class D : B { };
> void f(D&) { }
>
> Will the void f(D&) be considered as the override of B::f?
>
> class B { };
> class D : B { public: void f() { } };
> void f(B&) { }
>
> Which function will be called?
> B* i =3D new D(); i->f();
>
> class A { };
> class B { public: operator A() { ... }; public: void f() { }; };
> void f(A&) { }
>
> Which function will be called when
> B i; f(i);
>
> 3. c, v, cv, c&, v&, cv&, r-value reference ?
> void f(const C&) { }
> void f(C&) { }
> void f(C) { }
> void f(volatile const& C) { }
> ...
>
> When
> C i; i.f();
> Which function should be called, should it be consistent with f(i)?
>
> 4. Will f(C*) be supported?
>
> class C { };
> void f(C*) { }
> void f(C&) { }
>
> Which function should be called?
> C c; c.f(); (&c)->f();
> C* c =3D new C(); c->f(); (*c).f();
> It would be really funky, if the behavior of c.f() and (&c)->f() are
> different.
>
> 5. nullptr?
>
> class A { public: void f() { } };
> class B { };
> void f(B&) { }
>
> Will the following calls crash?
> A* a =3D nullptr;
> f(a);
> B* b =3D nullptr;
> b->f();
>
> And, how about
> class A { };
> void f(A*) { }
> A* i =3D nullptr;
> i->f();
>
> Let's define all the cases we may have, and make this doc become the
> standard. So involve the original authors of both 4165 and 4174.
>
>
> On Tuesday, March 3, 2015 at 5:13:04 AM UTC+8, gmis...@gmail.com wrote:
>>
>> I'm very keen on Bjarne's variant of the proposal.
>> As Walter says, I think it'll be amazingly useful.
>>
>> I would like to see some more talk explaining what it initially recommen=
d
>> regarding access to private members and the pros/cons of it but I'm keen
>> for this proposal to progress and look out for it's progress in each
>> mailing. I'm interested in what other people think of the proposal. I'm
>> particular interested to know if any compiler has speculatively implemen=
ted
>> it so I could play with it but that's probably wishful thinking.
>>
>> On Monday, October 27, 2014 at 9:24:31 PM UTC+13, Ryou Ezoe wrote:
>>
>>> I have some comments on N4165/N4174.
>>>
>>> 1. weird code
>>> It's my understanding that under this proposal, following code is
>>> well-formed.
>>>
>>> 4.0.sqrt() ;
>>> "hello".puts() ;
>>>
>>> Is this correct?
>>>
>>>
>>> If so and If we allow N4165's "Additionally allow =E2=80=9Cthis=E2=80=
=9D in not only
>>> the first parameter location",
>>> It does allow this:
>>>
>>> fp->fputs("hello") ;
>>>
>>> as well as this:
>>>
>>> "hello"->fputs(fp) ;
>>>
>>>
>>> 2. Tool support
>>> The papers wrote about better tool support.
>>> Although I agree with the idea, there are so many too generic function
>>> templates in the standard library that bloat up the auto completion
>>> candidates.
>>> Like move, swap, addressof.
>>>
>>> Without some constrained template features like concept or some hard
>>> coded/heuristic restriction on tool implementation,
>>> a set of auto completion name candidates are indeed smaller than free
>>> functions, but not that small enough.
>>>
>>> Consider FILE from <stdio.h>.
>>> The paper said it can auto complete fseek.
>>>
>>> FILE * fp ;
>>> fp->fseek
>>>
>>> It looks nice.
>>>
>>> But, Annex D.5 said C headers are deprecated and we should use C++
>>> header(<cstdio>) instead.
>>> So we should write like this:
>>>
>>> std::FILE * fp =3D ... ;
>>>
>>> This add std namespace to fp's associated namespace so all standard
>>> library names are on the candidate list.
>>>
>>> Suppose we also #included <algorithm> and wrote:
>>>
>>> fp->
>>>
>>> Tool suggest all <algorithm> function templates because fp is a pointer=
..
>>>
>>> fp->for_each
>>>
>>> Even if without ADL, id-expression allows qualified-id so a tool just
>>> list up all viable functions:
>>>
>>> fp->std::for_each
>>>
>>>
>>> This is only considering the standard library, I think users also
>>> wrote many too generic functions like this.
>>> Combining those, auto completion candidates will bloat up with
>>> completely unrelated generic function names user don't expect it to be
>>> suggested.
>>>
>>>
>>> I don't think tool support situation will be any better with this
>>> proposal.
>>> It may be worse because candidate bloat up also affect existing class
>>> types and overwhelm the result.
>>>
>>> Very common types(like const char *, long double etc) and class types
>>> which has user defined conversion to common types now shows all sort
>>> of common functions as well as user defined literals!
>>>
>>> long double ld ;
>>> ld.operator "" il() ; // std::complex<long double>
>>>
>>>
>>> What do you think?
>>>
>>> --
>>> Ryou Ezoe
>>>
>>> Occupation: DWANGO Co., Ltd.
>>>
>>> Blog:     http://cpplover.blogspot.com/
>>> Twitter: https://twitter.com/EzoeRyou
>>> GitHub: https://github.com/EzoeRyou
>>>
>>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr"><span style=3D"font-size:13.1999998092651px">&gt; 2. The d=
oc does not mention the scenario when an inheritance or implicit conversion=
 happened. i.e.</span><div><br></div><div>It seems to me the paper is perha=
ps too specific in its wording:</div><div><br></div><div>&gt; x.f(y) means
<br>&gt; =C2=A0 =C2=A01. First try x.f(y) =E2=80=93does x=E2=80=99s class h=
ave a member f? If so try to use it</div><div>&gt; =C2=A0 =C2=A02. Then try=
 f(x,y) =E2=80=93 is there a function f? If so, try to use it</div><div><sp=
an style=3D"font-size:13.1999998092651px">&gt; =C2=A0 =C2=A03. otherwise er=
ror</span><br></div><div><span style=3D"font-size:13.1999998092651px"><br><=
/span></div><div>Saying &quot;does x&#39;s class have a member f&quot; unne=
cessarily constrains to the immediate class type of x. Perhaps rephrasing i=
t along the lines of &quot;is f a valid callable member function of x?&quot=
; would readily account for the case of inheritance. I assume the spirit of=
 the paper is to state that code written in the existing syntax today shoul=
d continue to behave as it does, but only in cases where this alternate syn=
tax is used and the code would otherwise not resolve to a member function c=
all, consider an additional resolution strategy for x.f(y).</div><div><br><=
/div><div>As for &quot;hello&quot;.puts();, although this would be possible=
 per N4174, I don&#39;t think it should be much of a concern. We can alread=
y write interesting tidbits such as:</div><div><br></div><div><div><span cl=
ass=3D"Apple-tab-span" style=3D"white-space:pre"> </span>int nums[5] =3D {0=
, 1, 2, 3, 4};</div><div><span class=3D"Apple-tab-span" style=3D"white-spac=
e:pre"> </span>cout &lt;&lt; 3[nums] &lt;&lt; endl;</div></div><div><br></d=
iv><div>But people often don&#39;t realize this is even possible. It doesn&=
#39;t cause problems, so we tend to ignore it.</div><div><br></div><div><br=
><div class=3D"gmail_quote">On Mon, Mar 2, 2015 at 7:07 PM Zijie He &lt;<a =
href=3D"mailto:hzj_jie@hotmail.com">hzj_jie@hotmail.com</a>&gt; 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">Personally I really like the=
 idea of N4174, though several serious concerns,<div>1.=C2=A0f(x,y) means 1=
.. First try x.f(y) =E2=80=93 does x=E2=80=99s class have a member f? If so =
try to use it 2. First try f(x,y) =E2=80=93 is there a function f? If so, t=
ry to use it 3. otherwise error</div><div>This is totally wrong. We can hav=
e both f(x, y) and x.f(y) in the code, but this new syntax blocks f(x, y) b=
een called if x.f(y) exists.</div><div><br></div><div>2. The doc does not m=
ention the scenario when an inheritance or implicit conversion happened. i.=
e.</div><div><br></div><div>class B { public: void f() { } };</div><div>cla=
ss D : B { };</div><div>void f(D&amp;) { }</div><div><br></div><div>Which f=
unction will be called in the following scenarios?</div><div>a. B* i =3D ne=
w D(); i-&gt;f();</div><div>b. D i; i.f();</div><div><br></div><div>class B=
 { public: virtual void f() =3D 0 };</div><div>class D : B { };</div><div>v=
oid f(D&amp;) { }</div><div><br></div><div>Will the void f(D&amp;) be consi=
dered as the override of B::f?</div><div><br></div><div>class B { };</div><=
div>class D : B { public: void f() { } };</div><div>void f(B&amp;) { }</div=
><div><br></div><div>Which function will be called?</div><div>B* i =3D new =
D(); i-&gt;f();</div><div><br></div><div>class A { };</div><div>class B { p=
ublic: operator A() { ... }; public: void f() { }; };</div><div>void f(A&am=
p;) { }</div><div><br></div><div>Which function will be called when</div><d=
iv>B i; f(i);</div><div><br></div><div>3. c, v, cv, c&amp;, v&amp;, cv&amp;=
, r-value reference ?</div><div>void f(const C&amp;) { }</div><div>void f(C=
&amp;) { }</div><div>void f(C) { }</div><div>void f(volatile const&amp; C) =
{ }</div><div>...</div><div><br></div><div>When</div><div>C i; i.f();</div>=
<div>Which function should be called, should it be consistent with f(i)?</d=
iv><div><br></div><div>4. Will f(C*) be supported?</div><div><br></div><div=
>class C { };</div><div>void f(C*) { }</div><div>void f(C&amp;) { }</div><d=
iv><br></div><div>Which function should be called?</div><div>C c; c.f(); (&=
amp;c)-&gt;f();</div><div>C* c =3D new C(); c-&gt;f(); (*c).f();</div><div>=
It would be really funky, if the behavior of c.f() and (&amp;c)-&gt;f() are=
 different.</div><div><br></div><div>5. nullptr?</div><div><br></div><div>c=
lass A { public: void f() { } };</div><div>class B { };</div><div>void f(B&=
amp;) { }</div><div><br></div><div>Will the following calls crash?</div><di=
v>A* a =3D nullptr;</div><div>f(a);</div><div>B* b =3D nullptr;</div><div>b=
-&gt;f();</div><div><br></div><div>And, how about</div><div>class A { };</d=
iv><div>void f(A*) { }</div><div>A* i =3D nullptr;</div><div>i-&gt;f();</di=
v><div><br></div><div>Let&#39;s define all the cases we may have, and make =
this doc become the standard. So involve the original authors of both 4165 =
and 4174.</div></div><div dir=3D"ltr"><div><br></div><br>On Tuesday, March =
3, 2015 at 5:13:04 AM UTC+8, <a href=3D"mailto:gmis...@gmail.com" target=3D=
"_blank">gmis...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" styl=
e=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr"><div>I&#39;m very keen on Bjarne&#39;s variant of the pr=
oposal.</div><div>As Walter says, I think it&#39;ll be=C2=A0amazingly usefu=
l.</div><div><br></div><div>I would like to see some more talk=C2=A0explain=
ing=C2=A0what it=C2=A0initially recommend regarding access to private membe=
rs and=C2=A0the pros/cons of it=C2=A0but I&#39;m keen for this proposal to =
progress and look out for it&#39;s progress in each mailing.=C2=A0I&#39;m=
=C2=A0interested in what other people think of the proposal. I&#39;m partic=
ular interested to know if any compiler has speculatively implemented it so=
 I could play with it but that&#39;s probably wishful thinking.</div><div><=
br>On Monday, October 27, 2014 at 9:24:31 PM UTC+13, Ryou Ezoe wrote:</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-l=
eft-style:solid">I have some comments on N4165/N4174.
<br>
<br>1. weird code
<br>It&#39;s my understanding that under this proposal, following code is w=
ell-formed.
<br>
<br>4.0.sqrt() ;
<br>&quot;hello&quot;.puts() ;
<br>
<br>Is this correct?
<br>
<br>
<br>If so and If we allow N4165&#39;s &quot;Additionally allow =E2=80=9Cthi=
s=E2=80=9D in not only
<br>the first parameter location&quot;,
<br>It does allow this:
<br>
<br>fp-&gt;fputs(&quot;hello&quot;) ;
<br>
<br>as well as this:
<br>
<br>&quot;hello&quot;-&gt;fputs(fp) ;
<br>
<br>
<br>2. Tool support
<br>The papers wrote about better tool support.
<br>Although I agree with the idea, there are so many too generic function
<br>templates in the standard library that bloat up the auto completion
<br>candidates.
<br>Like move, swap, addressof.
<br>
<br>Without some constrained template features like concept or some hard
<br>coded/heuristic restriction on tool implementation,
<br>a set of auto completion name candidates are indeed smaller than free
<br>functions, but not that small enough.
<br>
<br>Consider FILE from &lt;stdio.h&gt;.
<br>The paper said it can auto complete fseek.
<br>
<br>FILE * fp ;
<br>fp-&gt;fseek
<br>
<br>It looks nice.
<br>
<br>But, Annex D.5 said C headers are deprecated and we should use C++
<br>header(&lt;cstdio&gt;) instead.
<br>So we should write like this:
<br>
<br>std::FILE * fp =3D ... ;
<br>
<br>This add std namespace to fp&#39;s associated namespace so all standard
<br>library names are on the candidate list.
<br>
<br>Suppose we also #included &lt;algorithm&gt; and wrote:
<br>
<br>fp-&gt;
<br>
<br>Tool suggest all &lt;algorithm&gt; function templates because fp is a p=
ointer.
<br>
<br>fp-&gt;for_each
<br>
<br>Even if without ADL, id-expression allows qualified-id so a tool just
<br>list up all viable functions:
<br>
<br>fp-&gt;std::for_each
<br>
<br>
<br>This is only considering the standard library, I think users also
<br>wrote many too generic functions like this.
<br>Combining those, auto completion candidates will bloat up with
<br>completely unrelated generic function names user don&#39;t expect it to=
 be
<br>suggested.
<br>
<br>
<br>I don&#39;t think tool support situation will be any better with this p=
roposal.
<br>It may be worse because candidate bloat up also affect existing class
<br>types and overwhelm the result.
<br>
<br>Very common types(like const char *, long double etc) and class types
<br>which has user defined conversion to common types now shows all sort
<br>of common functions as well as user defined literals!
<br>
<br>long double ld ;
<br>ld.operator &quot;&quot; il() ; // std::complex&lt;long double&gt;
<br>
<br>
<br>What do you think?
<br>
<br>--=20
<br>Ryou Ezoe
<br>
<br>Occupation: DWANGO Co., Ltd.
<br>
<br>Blog: =C2=A0 =C2=A0 <a href=3D"http://cpplover.blogspot.com/" rel=3D"no=
follow" target=3D"_blank">http://cpplover.blogspot.com/</a>
<br>Twitter: <a href=3D"https://twitter.com/EzoeRyou" rel=3D"nofollow" targ=
et=3D"_blank">https://twitter.com/EzoeRyou</a>
<br>GitHub: <a href=3D"https://github.com/EzoeRyou" rel=3D"nofollow" target=
=3D"_blank">https://github.com/EzoeRyou</a>
<br></blockquote></div></blockquote></div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</blockquote></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a113d19d66d38c80510c65ca5--

.

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

> I don't think tool support situation will be any better with this
proposal.
It may be worse because candidate bloat up also affect existing class
types and overwhelm the result.

If this does come up as a significant concern against these proposals,
perhaps a conservative approach could be adopted: this new resolution
syntax applies iff the function contains a parameter marked with "this".

Then only functions constrained using concepts could mark a parameter with
"this" to enable the syntax; drastically reducing the candidate functions
for tools to consider.

I fear, however, this would create many bike shed arguments on the merits
of which functions to modify.

On Mon, Oct 27, 2014 at 4:24 AM Ryou Ezoe <boostcpp@gmail.com> wrote:

> I have some comments on N4165/N4174.
>
> 1. weird code
> It's my understanding that under this proposal, following code is
> well-formed.
>
> 4.0.sqrt() ;
> "hello".puts() ;
>
> Is this correct?
>
>
> If so and If we allow N4165's "Additionally allow =E2=80=9Cthis=E2=80=9D =
in not only
> the first parameter location",
> It does allow this:
>
> fp->fputs("hello") ;
>
> as well as this:
>
> "hello"->fputs(fp) ;
>
>
> 2. Tool support
> The papers wrote about better tool support.
> Although I agree with the idea, there are so many too generic function
> templates in the standard library that bloat up the auto completion
> candidates.
> Like move, swap, addressof.
>
> Without some constrained template features like concept or some hard
> coded/heuristic restriction on tool implementation,
> a set of auto completion name candidates are indeed smaller than free
> functions, but not that small enough.
>
> Consider FILE from <stdio.h>.
> The paper said it can auto complete fseek.
>
> FILE * fp ;
> fp->fseek
>
> It looks nice.
>
> But, Annex D.5 said C headers are deprecated and we should use C++
> header(<cstdio>) instead.
> So we should write like this:
>
> std::FILE * fp =3D ... ;
>
> This add std namespace to fp's associated namespace so all standard
> library names are on the candidate list.
>
> Suppose we also #included <algorithm> and wrote:
>
> fp->
>
> Tool suggest all <algorithm> function templates because fp is a pointer.
>
> fp->for_each
>
> Even if without ADL, id-expression allows qualified-id so a tool just
> list up all viable functions:
>
> fp->std::for_each
>
>
> This is only considering the standard library, I think users also
> wrote many too generic functions like this.
> Combining those, auto completion candidates will bloat up with
> completely unrelated generic function names user don't expect it to be
> suggested.
>
>
> I don't think tool support situation will be any better with this proposa=
l.
> It may be worse because candidate bloat up also affect existing class
> types and overwhelm the result.
>
> Very common types(like const char *, long double etc) and class types
> which has user defined conversion to common types now shows all sort
> of common functions as well as user defined literals!
>
> long double ld ;
> ld.operator "" il() ; // std::complex<long double>
>
>
> What do you think?
>
> --
> Ryou Ezoe
>
> Occupation: DWANGO Co., Ltd.
>
> Blog:     http://cpplover.blogspot.com/
> Twitter: https://twitter.com/EzoeRyou
> GitHub: https://github.com/EzoeRyou
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at http://groups.google.com/a/isocpp.org/group/std-
> proposals/.
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr"><span style=3D"font-size:13.1999998092651px;line-height:19=
..7999992370605px">&gt; I don&#39;t think tool support situation will be any=
 better with this proposal.</span><br style=3D"font-size:13.1999998092651px=
;line-height:19.7999992370605px"><span style=3D"font-size:13.1999998092651p=
x;line-height:19.7999992370605px">It may be worse because candidate bloat u=
p also affect existing class</span><br style=3D"font-size:13.1999998092651p=
x;line-height:19.7999992370605px"><span style=3D"font-size:13.1999998092651=
px;line-height:19.7999992370605px">types and overwhelm the result.</span><d=
iv><span style=3D"line-height:19.7999992370605px"><br></span></div><div><sp=
an style=3D"line-height:19.7999992370605px">If this does come up as a signi=
ficant concern against these proposals, perhaps a conservative approach cou=
ld be adopted: this new resolution syntax applies iff the function contains=
 a parameter marked with=C2=A0</span><span style=3D"font-size:13.1999998092=
651px;line-height:19.7999992370605px">&quot;this&quot;.</span></div><div><s=
pan style=3D"line-height:19.7999992370605px"><br></span></div><div><span st=
yle=3D"line-height:19.7999992370605px">Then only functions constrained usin=
g concepts could mark a parameter with &quot;this&quot; to enable the synta=
x; drastically reducing the candidate functions for tools to consider.</spa=
n></div><div><span style=3D"line-height:19.7999992370605px"><br></span></di=
v><div><span style=3D"line-height:19.7999992370605px">I fear, however, this=
 would create many bike shed arguments on the merits of which functions to =
modify.</span></div><div><br><div class=3D"gmail_quote">On Mon, Oct 27, 201=
4 at 4:24 AM Ryou Ezoe &lt;<a href=3D"mailto:boostcpp@gmail.com">boostcpp@g=
mail.com</a>&gt; wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I have some comme=
nts on N4165/N4174.<br>
<br>
1. weird code<br>
It&#39;s my understanding that under this proposal, following code is well-=
formed.<br>
<br>
4.0.sqrt() ;<br>
&quot;hello&quot;.puts() ;<br>
<br>
Is this correct?<br>
<br>
<br>
If so and If we allow N4165&#39;s &quot;Additionally allow =E2=80=9Cthis=E2=
=80=9D in not only<br>
the first parameter location&quot;,<br>
It does allow this:<br>
<br>
fp-&gt;fputs(&quot;hello&quot;) ;<br>
<br>
as well as this:<br>
<br>
&quot;hello&quot;-&gt;fputs(fp) ;<br>
<br>
<br>
2. Tool support<br>
The papers wrote about better tool support.<br>
Although I agree with the idea, there are so many too generic function<br>
templates in the standard library that bloat up the auto completion<br>
candidates.<br>
Like move, swap, addressof.<br>
<br>
Without some constrained template features like concept or some hard<br>
coded/heuristic restriction on tool implementation,<br>
a set of auto completion name candidates are indeed smaller than free<br>
functions, but not that small enough.<br>
<br>
Consider FILE from &lt;stdio.h&gt;.<br>
The paper said it can auto complete fseek.<br>
<br>
FILE * fp ;<br>
fp-&gt;fseek<br>
<br>
It looks nice.<br>
<br>
But, Annex D.5 said C headers are deprecated and we should use C++<br>
header(&lt;cstdio&gt;) instead.<br>
So we should write like this:<br>
<br>
std::FILE * fp =3D ... ;<br>
<br>
This add std namespace to fp&#39;s associated namespace so all standard<br>
library names are on the candidate list.<br>
<br>
Suppose we also #included &lt;algorithm&gt; and wrote:<br>
<br>
fp-&gt;<br>
<br>
Tool suggest all &lt;algorithm&gt; function templates because fp is a point=
er.<br>
<br>
fp-&gt;for_each<br>
<br>
Even if without ADL, id-expression allows qualified-id so a tool just<br>
list up all viable functions:<br>
<br>
fp-&gt;std::for_each<br>
<br>
<br>
This is only considering the standard library, I think users also<br>
wrote many too generic functions like this.<br>
Combining those, auto completion candidates will bloat up with<br>
completely unrelated generic function names user don&#39;t expect it to be<=
br>
suggested.<br>
<br>
<br>
I don&#39;t think tool support situation will be any better with this propo=
sal.<br>
It may be worse because candidate bloat up also affect existing class<br>
types and overwhelm the result.<br>
<br>
Very common types(like const char *, long double etc) and class types<br>
which has user defined conversion to common types now shows all sort<br>
of common functions as well as user defined literals!<br>
<br>
long double ld ;<br>
ld.operator &quot;&quot; il() ; // std::complex&lt;long double&gt;<br>
<br>
<br>
What do you think?<br>
<br>
--<br>
Ryou Ezoe<br>
<br>
Occupation: DWANGO Co., Ltd.<br>
<br>
Blog:=C2=A0 =C2=A0 =C2=A0<a href=3D"http://cpplover.blogspot.com/" target=
=3D"_blank">http://cpplover.blogspot.com/</a><br>
Twitter: <a href=3D"https://twitter.com/EzoeRyou" target=3D"_blank">https:/=
/twitter.com/EzoeRyou</a><br>
GitHub: <a href=3D"https://github.com/EzoeRyou" target=3D"_blank">https://g=
ithub.com/EzoeRyou</a><br>
<br>
--<br>
<br>
---<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@<u></u>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/<u></u>isocpp.=
org/group/std-<u></u>proposals/</a>.<br>
</blockquote></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--e89a8f50316ce2b8470510c6a3a9--

.

On 8 March 2015 at 14:50, Bret Kuhns <bkuhns@gmail.com> wrote:
>> 2. The doc does not mention the scenario when an inheritance or implicit
>> conversion happened. i.e.
> It seems to me the paper is perhaps too specific in its wording:
>> x.f(y) means
>>    1. First try x.f(y) =E2=80=93does x=E2=80=99s class have a member f? =
If so try to use
>> it
>>    2. Then try f(x,y) =E2=80=93 is there a function f? If so, try to use=
 it
>>    3. otherwise error
> Saying "does x's class have a member f" unnecessarily constrains to the
> immediate class type of x. Perhaps rephrasing it along the lines of "is f=
 a

No problem, because [class.derived]/2 says
"... Unless redeclared in the derived class, members of a base class
are also considered to be members of the derived class. The base class
members are said to be inherited by the derived class. Inherited
members can be referred to in expressions in the same manner as other
members of the derived class, unless their names are hidden or
ambiguous (10.2)."

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

------=_Part_2517_1761065171.1425848646745
Content-Type: multipart/alternative;
 boundary="----=_Part_2518_1602706043.1425848646745"

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

This how C# handle similar functionality. Another benefit is this could=20
generate warning when you declare free function with this `this` and class=
=20
have member function with same name.
This will prevent lot of problems when we have name clashes.

Interesting effect is that friend functions become member functions with=20
bit different declaration syntax.
class A
{
public:
    friend void foo(this A& a) { /* ... */ }
    friend void bar(this A* p) { /* ... */ }
};

int main()
{
    A a;
    a.foo();
    A* p =3D &a;
    p.bar(); //interesting :)
}



On Sunday, March 8, 2015 at 2:10:24 PM UTC+1, Bret Kuhns wrote:
>
> > I don't think tool support situation will be any better with this=20
> proposal.
> It may be worse because candidate bloat up also affect existing class
> types and overwhelm the result.
>
> If this does come up as a significant concern against these proposals,=20
> perhaps a conservative approach could be adopted: this new resolution=20
> syntax applies iff the function contains a parameter marked with "this".
>
> Then only functions constrained using concepts could mark a parameter wit=
h=20
> "this" to enable the syntax; drastically reducing the candidate functions=
=20
> for tools to consider.
>
> I fear, however, this would create many bike shed arguments on the merits=
=20
> of which functions to modify.
>
> On Mon, Oct 27, 2014 at 4:24 AM Ryou Ezoe <boos...@gmail.com <javascript:=
>>=20
> wrote:
>
>> I have some comments on N4165/N4174.
>>
>> 1. weird code
>> It's my understanding that under this proposal, following code is=20
>> well-formed.
>>
>> 4.0.sqrt() ;
>> "hello".puts() ;
>>
>> Is this correct?
>>
>>
>> If so and If we allow N4165's "Additionally allow =E2=80=9Cthis=E2=80=9D=
 in not only
>> the first parameter location",
>> It does allow this:
>>
>> fp->fputs("hello") ;
>>
>> as well as this:
>>
>> "hello"->fputs(fp) ;
>>
>>
>> 2. Tool support
>> The papers wrote about better tool support.
>> Although I agree with the idea, there are so many too generic function
>> templates in the standard library that bloat up the auto completion
>> candidates.
>> Like move, swap, addressof.
>>
>> Without some constrained template features like concept or some hard
>> coded/heuristic restriction on tool implementation,
>> a set of auto completion name candidates are indeed smaller than free
>> functions, but not that small enough.
>>
>> Consider FILE from <stdio.h>.
>> The paper said it can auto complete fseek.
>>
>> FILE * fp ;
>> fp->fseek
>>
>> It looks nice.
>>
>> But, Annex D.5 said C headers are deprecated and we should use C++
>> header(<cstdio>) instead.
>> So we should write like this:
>>
>> std::FILE * fp =3D ... ;
>>
>> This add std namespace to fp's associated namespace so all standard
>> library names are on the candidate list.
>>
>> Suppose we also #included <algorithm> and wrote:
>>
>> fp->
>>
>> Tool suggest all <algorithm> function templates because fp is a pointer.
>>
>> fp->for_each
>>
>> Even if without ADL, id-expression allows qualified-id so a tool just
>> list up all viable functions:
>>
>> fp->std::for_each
>>
>>
>> This is only considering the standard library, I think users also
>> wrote many too generic functions like this.
>> Combining those, auto completion candidates will bloat up with
>> completely unrelated generic function names user don't expect it to be
>> suggested.
>>
>>
>> I don't think tool support situation will be any better with this=20
>> proposal.
>> It may be worse because candidate bloat up also affect existing class
>> types and overwhelm the result.
>>
>> Very common types(like const char *, long double etc) and class types
>> which has user defined conversion to common types now shows all sort
>> of common functions as well as user defined literals!
>>
>> long double ld ;
>> ld.operator "" il() ; // std::complex<long double>
>>
>>
>> What do you think?
>>
>> --
>> Ryou Ezoe
>>
>> Occupation: DWANGO Co., Ltd.
>>
>> Blog:     http://cpplover.blogspot.com/
>> Twitter: https://twitter.com/EzoeRyou
>> GitHub: https://github.com/EzoeRyou
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at http://groups.google.com/a/isocpp.org/group/std-
>> proposals/.
>>
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr">This how C# handle similar functionality. Another benefit =
is this could generate warning when you declare free function with this `th=
is` and class have member function with same name.<br>This will prevent lot=
 of problems when we have name clashes.<br><br>Interesting effect is that f=
riend functions become member functions with bit different declaration synt=
ax.<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"prettyprint"><div class=3D"subp=
rettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">class=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> A<br></sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">public</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">friend</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> foo</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">this</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> A</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> a</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D=
"styled-by-prettify">/* ... */</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br>&nbsp; &nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">friend</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">voi=
d</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> bar</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">this</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> A</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">*</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> p</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #800;" class=3D"styled-by-prettify">/* ... */</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">};</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> main</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nb=
sp; &nbsp; A a</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&=
nbsp; &nbsp; a</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">foo</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">();</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; A=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> p </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">&amp;</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">a</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br>&nbsp; &nbsp; p</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">bar</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">();</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #800;" class=3D"styled-by-prettify">//interesting=
 :)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></cod=
e></div><br><br><br>On Sunday, March 8, 2015 at 2:10:24 PM UTC+1, Bret Kuhn=
s 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"><span=
 style=3D"font-size:13.1999998092651px;line-height:19.7999992370605px">&gt;=
 I don't think tool support situation will be any better with this proposal=
..</span><br style=3D"font-size:13.1999998092651px;line-height:19.7999992370=
605px"><span style=3D"font-size:13.1999998092651px;line-height:19.799999237=
0605px">It may be worse because candidate bloat up also affect existing cla=
ss</span><br style=3D"font-size:13.1999998092651px;line-height:19.799999237=
0605px"><span style=3D"font-size:13.1999998092651px;line-height:19.79999923=
70605px">types and overwhelm the result.</span><div><span style=3D"line-hei=
ght:19.7999992370605px"><br></span></div><div><span style=3D"line-height:19=
..7999992370605px">If this does come up as a significant concern against the=
se proposals, perhaps a conservative approach could be adopted: this new re=
solution syntax applies iff the function contains a parameter marked with&n=
bsp;</span><span style=3D"font-size:13.1999998092651px;line-height:19.79999=
92370605px">"this".</span></div><div><span style=3D"line-height:19.79999923=
70605px"><br></span></div><div><span style=3D"line-height:19.7999992370605p=
x">Then only functions constrained using concepts could mark a parameter wi=
th "this" to enable the syntax; drastically reducing the candidate function=
s for tools to consider.</span></div><div><span style=3D"line-height:19.799=
9992370605px"><br></span></div><div><span style=3D"line-height:19.799999237=
0605px">I fear, however, this would create many bike shed arguments on the =
merits of which functions to modify.</span></div><div><br><div class=3D"gma=
il_quote">On Mon, Oct 27, 2014 at 4:24 AM Ryou Ezoe &lt;<a href=3D"javascri=
pt:" target=3D"_blank" gdf-obfuscated-mailto=3D"n0SlDg06cLoJ" rel=3D"nofoll=
ow" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.=
href=3D'javascript:';return true;">boos...@gmail.com</a>&gt; wrote:<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">I have some comments on N4165/N4174.<br>
<br>
1. weird code<br>
It's my understanding that under this proposal, following code is well-form=
ed.<br>
<br>
4.0.sqrt() ;<br>
"hello".puts() ;<br>
<br>
Is this correct?<br>
<br>
<br>
If so and If we allow N4165's "Additionally allow =E2=80=9Cthis=E2=80=9D in=
 not only<br>
the first parameter location",<br>
It does allow this:<br>
<br>
fp-&gt;fputs("hello") ;<br>
<br>
as well as this:<br>
<br>
"hello"-&gt;fputs(fp) ;<br>
<br>
<br>
2. Tool support<br>
The papers wrote about better tool support.<br>
Although I agree with the idea, there are so many too generic function<br>
templates in the standard library that bloat up the auto completion<br>
candidates.<br>
Like move, swap, addressof.<br>
<br>
Without some constrained template features like concept or some hard<br>
coded/heuristic restriction on tool implementation,<br>
a set of auto completion name candidates are indeed smaller than free<br>
functions, but not that small enough.<br>
<br>
Consider FILE from &lt;stdio.h&gt;.<br>
The paper said it can auto complete fseek.<br>
<br>
FILE * fp ;<br>
fp-&gt;fseek<br>
<br>
It looks nice.<br>
<br>
But, Annex D.5 said C headers are deprecated and we should use C++<br>
header(&lt;cstdio&gt;) instead.<br>
So we should write like this:<br>
<br>
std::FILE * fp =3D ... ;<br>
<br>
This add std namespace to fp's associated namespace so all standard<br>
library names are on the candidate list.<br>
<br>
Suppose we also #included &lt;algorithm&gt; and wrote:<br>
<br>
fp-&gt;<br>
<br>
Tool suggest all &lt;algorithm&gt; function templates because fp is a point=
er.<br>
<br>
fp-&gt;for_each<br>
<br>
Even if without ADL, id-expression allows qualified-id so a tool just<br>
list up all viable functions:<br>
<br>
fp-&gt;std::for_each<br>
<br>
<br>
This is only considering the standard library, I think users also<br>
wrote many too generic functions like this.<br>
Combining those, auto completion candidates will bloat up with<br>
completely unrelated generic function names user don't expect it to be<br>
suggested.<br>
<br>
<br>
I don't think tool support situation will be any better with this proposal.=
<br>
It may be worse because candidate bloat up also affect existing class<br>
types and overwhelm the result.<br>
<br>
Very common types(like const char *, long double etc) and class types<br>
which has user defined conversion to common types now shows all sort<br>
of common functions as well as user defined literals!<br>
<br>
long double ld ;<br>
ld.operator "" il() ; // std::complex&lt;long double&gt;<br>
<br>
<br>
What do you think?<br>
<br>
--<br>
Ryou Ezoe<br>
<br>
Occupation: DWANGO Co., Ltd.<br>
<br>
Blog:&nbsp; &nbsp; &nbsp;<a href=3D"http://cpplover.blogspot.com/" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.=
com/url?q\75http%3A%2F%2Fcpplover.blogspot.com%2F\46sa\75D\46sntz\0751\46us=
g\75AFQjCNFB9njSrdJmdDtzuKxuJVRjkMk6cQ';return true;" onclick=3D"this.href=
=3D'http://www.google.com/url?q\75http%3A%2F%2Fcpplover.blogspot.com%2F\46s=
a\75D\46sntz\0751\46usg\75AFQjCNFB9njSrdJmdDtzuKxuJVRjkMk6cQ';return true;"=
>http://cpplover.blogspot.com/</a><br>
Twitter: <a href=3D"https://twitter.com/EzoeRyou" target=3D"_blank" rel=3D"=
nofollow" onmousedown=3D"this.href=3D'https://www.google.com/url?q\75https%=
3A%2F%2Ftwitter.com%2FEzoeRyou\46sa\75D\46sntz\0751\46usg\75AFQjCNELTFVRb6q=
-vfMMeNdx0ngU0b9vog';return true;" onclick=3D"this.href=3D'https://www.goog=
le.com/url?q\75https%3A%2F%2Ftwitter.com%2FEzoeRyou\46sa\75D\46sntz\0751\46=
usg\75AFQjCNELTFVRb6q-vfMMeNdx0ngU0b9vog';return true;">https://twitter.com=
/EzoeRyou</a><br>
GitHub: <a href=3D"https://github.com/EzoeRyou" target=3D"_blank" rel=3D"no=
follow" onmousedown=3D"this.href=3D'https://www.google.com/url?q\75https%3A=
%2F%2Fgithub.com%2FEzoeRyou\46sa\75D\46sntz\0751\46usg\75AFQjCNGW0LevPYeWQJ=
pnehARuyNuugly6w';return true;" onclick=3D"this.href=3D'https://www.google.=
com/url?q\75https%3A%2F%2Fgithub.com%2FEzoeRyou\46sa\75D\46sntz\0751\46usg\=
75AFQjCNGW0LevPYeWQJpnehARuyNuugly6w';return true;">https://github.com/Ezoe=
Ryou</a><br>
<br>
--<br>
<br>
---<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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
n0SlDg06cLoJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';ret=
urn true;" onclick=3D"this.href=3D'javascript:';return true;">std-proposal.=
...@<u></u>isoc<wbr>pp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"n0SlDg06cLoJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:=
';return true;">std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';return true=
;" onclick=3D"this.href=3D'http://groups.google.com/a/isocpp.org/group/std-=
proposals/';return true;">http://groups.google.com/a/<u></u>iso<wbr>cpp.org=
/group/std-<u></u>proposals/</a>.<br>
</blockquote></div></div></div>
</blockquote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2518_1602706043.1425848646745--
------=_Part_2517_1761065171.1425848646745--

.

------=_Part_463_955342381.1425906358365
Content-Type: multipart/alternative;
 boundary="----=_Part_464_1851652495.1425906358365"

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

> file->fputs(=E2=80=9CHello world=E2=80=9D);
=20
How is decided what function this calls? What if both fputs(FILE*, T)
and fputs(T, FILE*) are available?

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr"><div><font face=3D"arial, sans-serif"><span style=3D"font-=
size: 12.8000001907349px;">&gt; file-&gt;fputs(=E2=80=9CHello world=E2=80=
=9D);</span></font></div><div><font face=3D"arial, sans-serif"><span style=
=3D"font-size: 12.8000001907349px;">&nbsp;</span></font></div><div><font fa=
ce=3D"arial, sans-serif"><span style=3D"font-size: 12.8000001907349px;">How=
 is decided what function this calls? What if both fputs(FILE*, T)</span></=
font></div><div><font face=3D"arial, sans-serif"><span style=3D"font-size: =
12.8000001907349px;">and fputs(T, FILE*) are available?</span></font></div>=
</div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_464_1851652495.1425906358365--
------=_Part_463_955342381.1425906358365--

.