220 16616 article Path: news.gmane.org!not-for-mail From: Zijie He Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Comment on N4165, N4174 Date: Mon, 2 Mar 2015 16:07:46 -0800 (PST) Lines: 420 Approved: news@gmane.org Message-ID: References: <8c9d5f60-8c76-4763-9da6-c159db1f3d80@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3693_576688624.1425341266670" X-Trace: ger.gmane.org 1425341286 4430 80.91.229.3 (3 Mar 2015 00:08:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 3 Mar 2015 00:08:06 +0000 (UTC) Cc: gmisocpp@gmail.com, bs@ms.com, hsutter@microsoft.com To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBD6IXSMN7QKRBU7W2OTQKGQEAJ7PE3Y@isocpp.org Tue Mar 03 01:07:52 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f70.google.com ([209.85.218.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YSaNK-0001ja-8y for gclcip-std-proposals@m.gmane.org; Tue, 03 Mar 2015 01:07:50 +0100 Original-Received: by mail-oi0-f70.google.com with SMTP id u20sf236699295oif.1 for ; Mon, 02 Mar 2015 16:07:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:content-type:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=Rwl+DJ6ZKrWD4ZzmQ70McBuW7BELvkKbh6WSoSZbjdA=; b=fsfqwkBdwWb0bgF7YWjLTT8B0MeHyc1lYrPzmdQAJ0D9S1+PgIgaEk+fmTSM+I8m67 UQmKyE2CN5k8weQ6VqlCVHlyqP7FLyRpuDEtQsdHhsUu1UWmX1HSRIgwt06/kUSl+kNz CHt/Atlxv21hJImr465FiwCsYQBiRV5MVQiSYdR1ELPUHpsrxL1kMyvimvxUMkEe2X37 0F4lgRuIOGuIHra+jaHEjJgIt6tybb7G9mgA6f38U6m3KoC4H7F3g8YpNnvQ7NYlPt/9 HM9QWw7iDN+6geNn53lBd+vb1siB4COjPY53jA9Eg7VEDVjeOuwHfho/zDj7gKzL2bts lT5g== X-Gm-Message-State: ALoCoQkgcHqyRrJZx4LzTzkspTOy2siktlNraAlGQaFk3diVS/4jIJtalWsZ391W8Bey1TMzwrte X-Received: by 10.43.63.196 with SMTP id xf4mr30332074icb.22.1425341269037; Mon, 02 Mar 2015 16:07:49 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.27.3 with SMTP id p3ls798782obg.25.gmail; Mon, 02 Mar 2015 16:07:47 -0800 (PST) X-Received: by 10.182.4.101 with SMTP id j5mr207297obj.24.1425341267054; Mon, 02 Mar 2015 16:07:47 -0800 (PST) In-Reply-To: <8c9d5f60-8c76-4763-9da6-c159db1f3d80@isocpp.org> X-Original-Sender: Hzj_jie@hotmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:16616 Archived-At: ------=_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 .=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() 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 and wrote:=20 >> >> fp->=20 >> >> Tool suggest all 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=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
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 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
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.

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

cl= ass 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: vo= id f() { } };
void f(B&) { }

Which f= unction 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 ?
<= div>void f(const C&) { }
void f(C&) { }
void f(= C) { }
void f(volatile const& C) { }
...
=
When
C i; i.f();
Which function should b= e called, should it be consistent with f(i)?

4. Wi= ll f(C*) be supported?

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

Which func= tion 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 k= een on Bjarne's variant of the proposal.
As Walter says, I think = it'll be amazingly useful.

I would like to se= e some more talk explaining what it initially recommend rega= rding access to private members and the pros/cons of it but I'm k= een for this proposal to progress and look out for it's progress in each ma= iling. I'm 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.

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 p= ointer.

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 propo= sal.
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:     htt= p://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 &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+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/<= /a>.
------=_Part_3694_812004657.1425341266670-- ------=_Part_3693_576688624.1425341266670-- .