220 32378 <638143af-5a25-41a8-88bd-5d10ff2c25b4@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Mingxin Wang Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: =?UTF-8?B?UmU6IFtzdGQtcHJvcG9zYWxzXSBSZTogQWRkaW5nIHRoZSBLZXl3b3JkIOKAnGludGVyZg==?= =?UTF-8?B?YWNl4oCdIGluIEMrKw==?= Date: Tue, 9 May 2017 22:00:00 -0700 (PDT) Lines: 304 Approved: news@gmane.org Message-ID: <638143af-5a25-41a8-88bd-5d10ff2c25b4@isocpp.org> References: <9ee212eb-4037-40c4-94c3-57a9a170a4c3@isocpp.org> <1765502.4y06pMOS3s@tjmaciei-mobl1> <20170509050057.GA1227@noemi> <6edad2ff-ea7e-4b26-bf65-0311e63e7633@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_5231_555693314.1494392400677" X-Trace: blaine.gmane.org 1494392408 22796 195.159.176.226 (10 May 2017 05:00:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 10 May 2017 05:00:08 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDNMBNHJWIGBBUN4ZLEAKGQE64X2FNI@isocpp.org Wed May 10 07:00:02 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qk0-f200.google.com ([209.85.220.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d8JjE-0005hE-VQ for gclcip-std-proposals@m.gmane.org; Wed, 10 May 2017 07:00:01 +0200 Original-Received: by mail-qk0-f200.google.com with SMTP id i81sf8289479qke.6 for ; Tue, 09 May 2017 22:00:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=8KyeNSD8BHdtp6Hb91L2CAJRFQmyNOzHdky+AOzngYE=; b=POe+2OEPqy76xq4MEas4yx5grXpbxfakbBqSNvnwxeiWT8efeBP00MBDSmn2TWiBR1 KpdluHegRuaU4QNpDq0tlzdpEXDzSRVw/2xSSh6TXnrvGJStGdNK2PjjdhdM2/rkYJRa W2+LBOlKHlpHEekz7H4VnrXLrfdGZfFdUhK8wP2hWTxLG/XlgcJfLgjKC3+ttYiHsrb9 icgU7O21iHi6Ov3kiQVrCQhU2R+JITEhWGkJn+EqAdpkyI1L0LEnB46I5vQRBhU1+Eg3 0Pxei+KJl4dyAk+miKrPLqt+UXFxpMbmu2Ve8dlDNTNkJLn+3ZYqUAPLU7rBMQ7P01cl QgZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=8KyeNSD8BHdtp6Hb91L2CAJRFQmyNOzHdky+AOzngYE=; b=e6ayVnPjrTbptCKJhDtB7gBOUuXFZgH1C9dw/3n2gM+XO6gPXl3GS4hasrtkJAIJpe mYG8gHFH6ZkNrQiXroPdotBBIz8cAmPBmZcIsPemCNCr9JQ9X21WOMCRwVfdFduGS+Ji /0c4iclW9wjPRm1U3cLm4zGCHFnHjlh3bAeSFfL67lICO5SJmh0+qP8JlZUH+LPlWA0i j+2q5CYXDbKHo0JZlzCvjuhziLNmynKpDk9b+1/dkfOGarJvTi2m39UaUqBuGPnO8d3W EsUfVyUdg8fwWiHuZyjxU7tF0MDO8Uu3VdTLYIyrZwpD7VcG729G1H4xvWygae1bdoWp EmHw== X-Gm-Message-State: AODbwcDRvEvPDoPLQcD6Jsx2AUMWiAlg9Uk9n801nH7H8qdy2QFtpd4B cXcQo+q0C34Ing== X-Received: by 10.200.55.24 with SMTP id o24mr1805581qtb.56.1494392402362; Tue, 09 May 2017 22:00:02 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.68.164 with SMTP id v36ls1979914ote.28.gmail; Tue, 09 May 2017 22:00:01 -0700 (PDT) X-Received: by 10.157.45.132 with SMTP id g4mr78590otb.0.1494392401377; Tue, 09 May 2017 22:00:01 -0700 (PDT) In-Reply-To: X-Original-Sender: wmx16835vv@163.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:32378 Archived-At: ------=_Part_5231_555693314.1494392400677 Content-Type: multipart/alternative; boundary="----=_Part_5232_1288459797.1494392400677" ------=_Part_5232_1288459797.1494392400677 Content-Type: text/plain; charset="UTF-8" Meanwhile, I do think your last idea is extremely valuable and instructive. I am trying to update the solution through decoupling polymorphism and lifetime management. Thank you again! Mingxin Wang On Tuesday, May 9, 2017 at 3:17:59 PM UTC+8, Bengt Gustafsson wrote: > > * I think you are over-using the word "runtime" here. As I understand it > what's happening is duck-typing: When the compiler sees that a variable of > some type T is used where an interface I is required it checks if the T at > hand contains all the methods specified by I. If so it generates (at > compile time) a virtual function table suitable for I which contains > pointers to the corresponding functions of T. In the case that the > corresponding function is virtual and the variable is a reference it seems > most reasonable to generate a stub function which implements a virtual call > to the T function using the variable value as "this". > > * Reusing Concepts as interfaces is a appealing idea but we have already > seen in this thread what a can of worms this opens, unfortunately. If > anyone can disentangle this into a manageable set of rules I would be all > for it, but the problems pointed out, that a concept can contain > requirements for free functions, types etc, and thus the virtual pointer > table is not enough to express the resulting polymorphism. > > * Maybe the keyword interface can be introduced as a contextual keyword > for this purpose, as in: > > struct MyInterface interface { > // only methods allowed > }; > > Maybe the methods should have to be declared virtual inside this construct > or maybe they are virtual by default. > > * I don't think that the ownership/lifetime issues should be mixed with > this duck-typing feature, instead the signature of the (non-template) > function to be called should express this as in: > > void Fun1(MyInterface& p); > void Fun2(std::unique_ptr p); > > Ok, this does not work: while ownership of the p object is established by > the signatures above the ownership of the original object is unclear. And > they can't be the same object as the p object has to consist of the > (generated) virtual function table and the pointer to the original object > (with some unknown ownership). This said, it is too weak of an idea to > automatically infer unique_ptr or shared_ptr as suggested earlier in this > thread. A very common case will be 'no ownership', i.e. a reference to a > stack object or similar, and user defined smart pointer templates. Some > kind of traits class should be able to act as a customization point to > indicate how p relates to the original object. > > > Den tisdag 9 maj 2017 kl. 08:36:20 UTC+2 skrev Mingxin Wang: >> >> Dear Mr. Fromreide, >> >> The "*signatures*" in G++ is a *syntactic sugar* that introduces new >> rules for declaring virtual member functions. The "*interfaces*" is not >> only a syntactic sugar, but a style of implementation for polymorphism, >> enabling types that meet specific requirements implicitly convertible to a >> same type at runtime. >> >> In short, we used to write virtual functions (or "signatures") >> *manually *to implement polymorphism, but now we can use the >> "interfaces" to *generate* efficient implementations for polymorphism >> based on our requirements. >> >> Thank you! >> >> Mingxin Wang >> >> On Tuesday, May 9, 2017 at 1:01:02 PM UTC+8, Magnus Fromreide wrote: >>> >>> On Mon, May 08, 2017 at 08:16:23AM -0700, Nicol Bolas wrote: >>> > On Monday, May 8, 2017 at 10:54:13 AM UTC-4, Thiago Macieira wrote: >>> > > >>> > > On Monday, 8 May 2017 00:30:58 PDT Mingxin Wang wrote: >>> > > > Unlike the "*Concespts*" that work at compile time, the >>> > > > "*Interfaces*" work at runtime mostly. In essence, it is not only >>> > > > a syntactic sugar, but a style of implementation for >>> *polymorphism*: >>> > > > virtual functions are only generated when required at runtime >>> > > >>> > > "virtual functions generated at runtime" needs A LOT of explanation. >>> > > Please >>> > > explain how the compiler would implement such a thing. >>> > > >>> > > i also recommend finding another name for your feature. "interface" >>> is a >>> > > widely >>> > > known term and means something else: it means a base class with >>> virtuals >>> > > that >>> > > need to be overridden. >>> > > >>> > >>> > I think the idea that he's trying to get across is the following. >>> > >>> > An `interface` is a class which is implicitly convertible from any >>> type >>> > which matches some concept. The implicit conversion effectively works >>> by >>> > storing a type-erased pointer/reference to the object it is converted >>> from. >>> > >>> > The concept it matches is defined by the set of member functions in >>> the >>> > `interface`. The `interface` class will automatically generate >>> matching >>> > member functions which forward calls to the type-erased >>> pointer/reference. >>> > >>> > So it's not a "virtual" call in the language sense; it's a virtual >>> call in >>> > the polymorphic sense. >>> >>> So, is this yet another reinvention of the old "signature" extension of >>> G++? >>> >>> https://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC112 >>> >>> /MF >>> >> -- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/638143af-5a25-41a8-88bd-5d10ff2c25b4%40isocpp.org. ------=_Part_5232_1288459797.1494392400677 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Meanwhile, I do think y= our last idea is extremely valuable and instructive. I am trying to update = the solution through decoupling=C2=A0polymorphism and=C2=A0lifetime managem= ent.

Thank you again!

M= ingxin Wang

On Tuesday, May 9, 2017 at 3:17:59 PM UTC+8, Beng= t Gustafsson wrote:
* I think you are over-using the word "runtime" here. As I = understand it what's happening is duck-typing: When the compiler sees t= hat a variable of some type T is used where an interface I is required it c= hecks if the T at hand contains all the methods specified by I. If so it ge= nerates (at compile time) a virtual function table suitable for I which con= tains pointers to the corresponding functions of T. In the case that the co= rresponding function is virtual and the variable is a reference it seems mo= st reasonable to generate a stub function which implements a virtual call t= o the T function using the variable value as "this".

* Reusing Concepts as interfaces is a appealing idea but we have alr= eady seen in this thread what a can of worms this opens, unfortunately. If = anyone can disentangle this into a manageable set of rules I would be all f= or it, but the problems pointed out, that a concept can contain requirement= s for free functions, types etc, and thus the virtual pointer table is not = enough to express the resulting polymorphism.

* Ma= ybe the keyword interface can be introduced as a contextual keyword for thi= s purpose, as in:

=C2=A0 =C2=A0 struct MyInterface= interface {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // only methods a= llowed
=C2=A0 =C2=A0 };

Maybe the method= s should have to be declared virtual inside this construct or maybe they ar= e virtual by default.

* I don't think that the= ownership/lifetime issues should be mixed with this duck-typing feature, i= nstead the signature of the (non-template) function to be called should exp= ress this as in:

=C2=A0 =C2=A0 void Fun1(MyInterfa= ce& p);
=C2=A0 =C2=A0 void Fun2(std::unique_ptr<MyInt= erface> p);

Ok, this does not work: while owner= ship of the p object is established by the signatures above the ownership o= f the original object is unclear. And they can't be the same object as = the p object has to consist of the (generated) virtual function table and t= he pointer to the original object (with some unknown ownership). This said,= it is too weak of an idea to automatically infer unique_ptr or shared_ptr = as suggested earlier in this thread. A very common case will be 'no own= ership', i.e. a reference to a stack object or similar, and user define= d smart pointer templates. Some kind of traits class should be able to act = as a customization point to indicate how p relates to the original object.<= br>


Den tisdag 9 maj 2017 kl. 08:36:20 UTC+2 skrev Mingxin Wang= :
Dear Mr. Fromreide,

The "signatures" in G++ is a=C2=A0
=
In short, = we used to write virtual functions (or=C2=A0"signatures&quo= t;)=C2=A0manually=C2=A0to imple= ment=C2=A0polymorphism, bu= t now we can use the "interfaces" to generate=C2=A0= efficient=C2=A0implementations for=C2=A0polymorphism based on our re= quirements.

=
Thank you!

Mingxin Wang

On Tuesday, May 9, 2017 at 1:01:02 PM UT= C+8, Magnus Fromreide wrote:
On Mon,= May 08, 2017 at 08:16:23AM -0700, Nicol Bolas wrote:
> On Monday, May 8, 2017 at 10:54:13 AM UTC-4, Thiago Macieira wrote= :
> >
> > On Monday, 8 May 2017 00:30:58 PDT Mingxin Wang wrote:=20
> > > Unlike the "*Concespts*" that work at compile = time, the=20
> > > "*Interfaces*" work at runtime mostly. In esse= nce, it is not only=20
> > > a syntactic sugar, but a style of implementation for *po= lymorphism*:=20
> > > virtual functions are only generated when required at ru= ntime=20
> >
> > "virtual functions generated at runtime" needs A LO= T of explanation.=20
> > Please=20
> > explain how the compiler would implement such a thing.=20
> >
> > i also recommend finding another name for your feature. "= ;interface" is a=20
> > widely=20
> > known term and means something else: it means a base class wi= th virtuals=20
> > that=20
> > need to be overridden.
> >
>=20
> I think the idea that he's trying to get across is the followi= ng.
>=20
> An `interface` is a class which is implicitly convertible from any= type=20
> which matches some concept. The implicit conversion effectively wo= rks by=20
> storing a type-erased pointer/reference to the object it is conver= ted from.
>=20
> The concept it matches is defined by the set of member functions i= n the=20
> `interface`. The `interface` class will automatically generate mat= ching=20
> member functions which forward calls to the type-erased pointer/re= ference.
>=20
> So it's not a "virtual" call in the language sense; = it's a virtual call in=20
> the polymorphic sense.

So, is this yet another reinvention of the old "signature" ex= tension of G++?

https://gcc.gnu.org/onlinedocs/gcc-2= ..95.3/gcc_5.html#SEC112

/MF

--
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.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/638143af-5a25-41a8-88bd-5d10ff2c25b4= %40isocpp.org.
------=_Part_5232_1288459797.1494392400677-- ------=_Part_5231_555693314.1494392400677-- .