220 32350 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: Mon, 8 May 2017 23:10:15 -0700 (PDT) Lines: 292 Approved: news@gmane.org Message-ID: References: <9ee212eb-4037-40c4-94c3-57a9a170a4c3@isocpp.org> <1765502.4y06pMOS3s@tjmaciei-mobl1> <45a81e95-d352-49ab-9c6e-7375aa41413c@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_758_274165352.1494310215176" X-Trace: blaine.gmane.org 1494310222 514 195.159.176.226 (9 May 2017 06:10:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 9 May 2017 06:10:22 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDNMBNHJWIGBBR52YXEAKGQELFIY26Q@isocpp.org Tue May 09 08:10:17 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pf0-f200.google.com ([209.85.192.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d7yLg-0008Ld-NV for gclcip-std-proposals@m.gmane.org; Tue, 09 May 2017 08:10:17 +0200 Original-Received: by mail-pf0-f200.google.com with SMTP id b17sf79770213pfd.1 for ; Mon, 08 May 2017 23:10:22 -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=CMH35W+ZnPIeY5oGRPXgeIvIpvt+hp4u/aQ+hdcuGwo=; b=lm9n6NXAvzjAT9FbFQg/3YPbC74HRVCuOLqVgmW/+yXAwYYEwmpQTof3TeuTGmovzd QbPrcXqS/u7xlbVgktC7O5GHsvM9yKEea4UXM5f5IoymGr/iWLsKMPlOsZIe5IOnOg4U F6C1W5RgOfowmteTJeTMukU43OTTYBgJ8QwwTn2bpyngn+obtd/LnLoBVMWg05FY5jZa 4T2+gYh5Q/rL8hTPssDUYLjy67/PuVEwUWGZR0iv8dVVxkeR8yOCCypINfyUcKs0/VtD py8Pxq+jPNDo3U3jo3YOBleTQVg40a/VL/bsmzwfrRPzHi109hd1xSM6Hq8a9R+H2KIe nhJA== 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=CMH35W+ZnPIeY5oGRPXgeIvIpvt+hp4u/aQ+hdcuGwo=; b=YJ87BYjnC6oDf1VISl/ZHgzZM04dvY1mBHnrBY7DMHyBABLiwsM0v5mFUdJMgULGua Kq/aavNrxzJDfYSy4TzcnV6xOFcEdyYlBdirDimCQx0PjqAhrqhcHLO3C6WKNwgat9Dz iwL8LP4+Gqa/IYFofW65Sp49PDzGAgij3P+zsBzmDG4aK2qPDJ2wZnxFXNTheoaXxkRL xK/OSCmAGiu4Pi/8GA2CZwhrqBCiF3Kk/SBGQVgS6SnVZfeZrlQyjO4PGh2B8CEe78L5 +lBnSiAgwigzM76erV9zRxTdPv9Q6UeR7+Vr4NFcJiK0TcRaBclRYVGqkr2NgylaafEV d2rA== X-Gm-Message-State: AN3rC/74ahjYNNN3aayDlsDSDra4dZm6pqGs4ZIn+Ka13UoWnrZi/nC3 9swqsmFWLwHXQg== X-Received: by 10.99.116.4 with SMTP id p4mr10540625pgc.14.1494310216858; Mon, 08 May 2017 23:10:16 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.15.73 with SMTP id 67ls10452136ott.21.gmail; Mon, 08 May 2017 23:10:15 -0700 (PDT) X-Received: by 10.157.84.44 with SMTP id j44mr1335964oth.16.1494310215808; Mon, 08 May 2017 23:10:15 -0700 (PDT) In-Reply-To: <45a81e95-d352-49ab-9c6e-7375aa41413c@isocpp.org> 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:32350 Archived-At: ------=_Part_758_274165352.1494310215176 Content-Type: multipart/alternative; boundary="----=_Part_759_1725561650.1494310215177" ------=_Part_759_1725561650.1494310215177 Content-Type: text/plain; charset=UTF-8 Dear Mr. Riedle, Thank you for your recognition! I have thought about the idea you posted about possible compile-time deduction, and I found it is *positive *for compiler optimization, but it shall not be abused. For example: Callable a([] { puts("Lambda"); }); a(); is OK to be compiled (after compiler optimization) as puts("Lambda"); But std::vector> a; std::vector> b(a); is ill-formed. An interface is a type, like integral types, classes, lambda expressions, etc. The reason why the code above is ill-formed is similar with the code below (also ill-formed): std::vector a; std::vector b(a); Thank you! Mingxin Wang On Tuesday, May 9, 2017 at 4:48:55 AM UTC+8, Jakob Riedle wrote: > > At first I was very skeptical of the proposal to add something that I > though to be already in the language. > The topic being discussed here now seems to me the missing link between > concepts and type erasure!! > > Thank you Mingxin Wang! > > Foo foo; // foo happens to model Concept >> std::erased efoo = foo; >> func(efoo); // Not a templatized function >> > Nice idea! > > Can we make that even more awesome?? YES!! > > How about this: > > void func(){ > // ... > } > > int main(){ > // Here the concept 'Callable' is used at a non-deduced context (where no > deduction happens) > // Therefore, the Concept will automatically be interpreted as an abstract > class to which other types can be type erased to. > std::vector myVec; > myVec.emplace( &func ); > } > > class MyClass{ > std::vector myVec; // same applies here since we are in an > undeduced context > > void set_vector( std::vector newVec ){ // This is still a > function template where Callable might be deduced as std::function > myVec = std::move(newVec); // Here an implicit conversion happens from > the potentially specialized vector (e.g. > std::vector>) to the vector of type erased Callables > } > } > > Whenever compile time type deduction *can *happen, it will, *analog to > contextpr*. > This is both very efficient and intuitive if you think about it. > Another example might be helpful: > > void do_something( std::vector vec ){ > // ... > } > > std::vector foo1; > std::vector> foo2; > > do_something( foo1 ); // 'vec' will stay a vector of type erased Callables > do_something( foo2 ); // 'vec' will be deduced to > std::vector> > > Again: Everything that can be deduced at compile time will and everything > that cannot will be deferred to run time. > Since this interpretation of concepts as implicit base classes only > happens in undeduced contexts (this is currently not allowed), its not > breaking code. > > How 'bout that??? > > Cheers, > Jakob > -- 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/d832c461-fa3e-429e-a36b-1d0b11eb634f%40isocpp.org. ------=_Part_759_1725561650.1494310215177 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Mr.=C2=A0Riedle,

Thank you for your recognition!

I have thought about the idea=C2=A0you posted=C2=A0about=C2= =A0possible compile-time deduction, and I found it is=C2=A0positive for=C2=A0compiler optimizat= ion, but it shall not be abused. For example:

=
Callable<= ;void()> a([] { puts("Lambda"); });
a();

is OK to be compiled=C2=A0(after=C2= =A0c= ompiler optimization)=C2=A0as

puts("Lambda");

But

std::vector<function= <void()>> a;
std::vector<Cal= lable<void()>> b(a);

is=C2=A0ill-forme= d.

An interface is a type, like=C2=A0integral types,=C2= =A0classes, lambda expressions, etc. The reason why the code above is=C2=A0= ill-formed=C2=A0is similar with the code below (also ill-form= ed):

std::vector<int> a;
std::vector<double> b(a);

Thank you!

Mingxin Wang

On Tuesday, May 9, 2017 at 4:48:55 AM UTC+8, Ja= kob Riedle wrote:
At first I was very skeptical of the proposal to add something tha= t I though to be already in the language.
The topic being dis= cussed here now seems to me the missing link between concepts and type eras= ure!!

Thank you Mingxin Wang!

<= div dir=3D"ltr">
Foo foo; // foo happens to model Concept
std::erased<Concept> efoo =3D foo;
func(efoo);=C2=A0 /= / Not a templatized function
Nice idea!

Can we make that even more awesome?? Y= ES!!

How about this:

void func(){
=C2=A0// ...
= }

int main(){
// Here the concept 'Callable' is use= d at a non-deduced context (where no deduction happens)
// Therefore, the Con= cept will automatically be interpreted as an abstract class to which other = types can be type erased to.
std::vector<Callable= > my= Vec;myVec.= emplace( &= func );=
}
class MyClass{
=C2=A0std::vector<Callable> myVec; // same applies here since we are in an undeduced context

=C2=A0void set_vector( std::vector<Callable> newVec ){ // This is still a function template where Callable might= be deduced as std::function<void()>
=C2=A0 myVec =3D std::move(newVec); // Here an implicit con= version happens from the potentially specialized vector (e.g. std::vector&l= t;std::function<void()>>) to the vector of type erased Callab= les
=C2=A0}
}
<= br>
Whenever compile time type deduction can happen, it wi= ll, analog to contextpr.
This is both very efficient and i= ntuitive if you think about it.
Another example might be helpful:=

void do_something( std::vector<Callable> vec ){
// ...=
}

std::vector<= Callable> foo1;
std::vector<std::function<void()>> foo2;

do_somethi= ng( foo= 1 ); // 'vec' will stay a vector of type= erased Callables
do_something<= span style=3D"color:#660">( foo2 <= span style=3D"color:#660">); // 'vec' will be deduced to std::vector<st= d::function<void()>>

Again: Everything that can be deduced= at compile time will and everything that cannot will be deferred to run ti= me.
Since this interpretation of concepts as implicit base classes only= happens in undeduced contexts (this is currently not allowed), its not bre= aking code.

How 'bout that???

Cheers,
Jakob

--
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/d832c461-fa3e-429e-a36b-1d0b11eb634f= %40isocpp.org.
------=_Part_759_1725561650.1494310215177-- ------=_Part_758_274165352.1494310215176-- .