220 16707 article Path: news.gmane.org!not-for-mail From: "Stroustrup, Bjarne" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: RE: Comment on N4165, N4174 Date: Wed, 4 Mar 2015 15:21:18 +0000 Lines: 1017 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/alternative; boundary="_000_B5B93905603D1043AB7FEC27AFEDD82408F8BD6DRRWEX2006N2msad_" X-Trace: ger.gmane.org 1425482717 28203 80.91.229.3 (4 Mar 2015 15:25:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 4 Mar 2015 15:25:17 +0000 (UTC) Cc: "gmisocpp@gmail.com" , "hsutter@microsoft.com" To: Zijie He , "std-proposals@isocpp.org" Original-X-From: std-proposals+bncBDMMF6WXYAIRBTGH3STQKGQEVZBZYWQ@isocpp.org Wed Mar 04 16:25:06 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f71.google.com ([209.85.218.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YTBAU-0005Q7-53 for gclcip-std-proposals@m.gmane.org; Wed, 04 Mar 2015 16:25:02 +0100 Original-Received: by oiav63 with SMTP id v63sf33349544oia.3 for ; Wed, 04 Mar 2015 07:25:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-type:mime-version:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=gN+G4q8qk27Jqn1mcpLyr03f+WWBOOrJ0h7XE0puWdw=; b=dg9glgUJwiA/GJ7R1ymNfktPdm59SfOOm0BuAS6um2K4xNXzMs19UEP/1DyfrI5NY2 iX/KykV+YilO3gNCIhUmoEqb6OA/tHllUpx3o+LGKzQaut3ILaD3jPrlSMlvg+re5qQW BtM5bGFCqfO9HajrJbY9HmT706hqt0XWrVX6Tlu9KfNko6gFkbTpMaXoidFV8TMzKb7i 8RKDiGQR+LYQn5P9SyGy/7ikw52aTUZvO+Mec+r7g6JloQQDAvaqsQjt+I9NqI+HUcSe b8VpQbydEirVORiSHPn++ejT8go11ML4853WxKkjZTfPO9 X-Gm-Message-State: ALoCoQmyMsm9hHgEXMMQAG1nvAvF1EIOj4aA4VpJk5acA3CGp5/9EG2+vOZExEQ/RLObkMIRNAVB X-Received: by 10.50.92.10 with SMTP id ci10mr27780523igb.8.1425482701183; Wed, 04 Mar 2015 07:25:01 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.109.166 with SMTP id l35ls691069qgf.8.gmail; Wed, 04 Mar 2015 07:25:00 -0800 (PST) X-Received: by 10.55.43.88 with SMTP id r85mr8049140qkh.35.1425482700176; Wed, 04 Mar 2015 07:25:00 -0800 (PST) Original-Received: from hqmtaint02.ms.com (hqmtaint02.ms.com. [205.228.53.69]) by mx.google.com with ESMTPS id 5si3686226qgy.56.2015.03.04.07.25.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Mar 2015 07:25:00 -0800 (PST) Received-SPF: pass (google.com: domain of Bjarne.Stroustrup@morganstanley.com designates 205.228.53.69 as permitted sender) client-ip=205.228.53.69; Original-Received: from hqmtaint02 (localhost.ms.com [127.0.0.1]) by hqmtaint02.ms.com (output Postfix) with ESMTP id C95D795C21A; Wed, 4 Mar 2015 10:24:59 -0500 (EST) Original-Received: from rrsmmta01.ms.com (rrsmmta01.ms.com [10.196.129.198]) by hqmtaint02.ms.com (internal Postfix) with ESMTP id 95B6D9EC001; Wed, 4 Mar 2015 10:24:59 -0500 (EST) Original-Received: from RRWEX2003N2.msad.ms.com (rrwex2003n2.ms.com [10.196.135.17]) by rrsmmta01.ms.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t24FOq3w001946; Wed, 4 Mar 2015 15:24:59 GMT Original-Received: from HZWEX2001N4.msad.ms.com (10.195.131.18) by RRWEX2003N2.msad.ms.com (10.196.135.17) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 4 Mar 2015 10:21:20 -0500 Original-Received: from RRWEX2006N2.msad.ms.com ([10.196.139.203]) by HZWEX2001N4.msad.ms.com ([10.195.131.18]) with mapi id 14.03.0224.002; Wed, 4 Mar 2015 10:21:19 -0500 Thread-Topic: Comment on N4165, N4174 Thread-Index: AQHQVUYUpRpv5d53fE2hKG5vlZPYup0K8dOQgAFmiICAABpp0A== In-Reply-To: Accept-Language: en-US, af-ZA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mspolicyagent: version=1.0 x-originating-ip: [10.195.12.63] X-EXCLAIMER-MD-CONFIG: be3bdf5c-71de-49fb-a1b7-ad6a6a1df5e2 X-EXCLAIMER-MD-CONFIG: f2a46809-d95e-4647-8996-91897c738879 X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Status: not scanned, disabled by settings X-KLMS-AntiPhishing: not scanned, disabled by settings X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server, version 8.0.1.705, bases: 2015/03/04 08:11:00 #10825807; khse: 2014-03-12 13:55:01 X-KLMS-AntiVirus-Status: Clean, skipped X-Original-Sender: bjarne.stroustrup@morganstanley.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of Bjarne.Stroustrup@morganstanley.com designates 205.228.53.69 as permitted sender) smtp.mail=Bjarne.Stroustrup@morganstanley.com; dkim=pass header.i=@morganstanley.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:16707 Archived-At: --_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] Sent: Monday, March 02, 2015 7:08 PM To: std-pr...@isocpp.org Cc: gmis...@gmail.com; Stroustrup, Bjarne (ICT); hsu...@micros= oft.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. =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 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 . 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() 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 and wrote: fp-> Tool suggest all 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 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

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.

 

From: Zijie He [ma= ilto: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; = Stroustrup, Bjarne (ICT)
Subject: Re: Comment on N4165, N4174

 

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.

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<5> and C* / C& / C <4> are discussible.


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

 

 

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

 

Personally I really like the idea of N4174, though several serious c= oncerns,

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 co= de, 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 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.

 

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

 

=C3= =B0    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.

 

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?<= /o:p>

 

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)?<= o:p>

 

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 recommend 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 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.


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 point= er.

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://g= ithub.com/EzoeRyou

 


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: http://www.morganstanley.com/disclaimers 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.




= 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: http://www.morganstanley.com/disclaimers=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.

--

---
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>.
--_000_B5B93905603D1043AB7FEC27AFEDD82408F8BD6DRRWEX2006N2msad_-- .