220 32340 <45a81e95-d352-49ab-9c6e-7375aa41413c@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Jakob Riedle Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: =?UTF-8?B?UmU6IFtzdGQtcHJvcG9zYWxzXSBSZTogQWRkaW5nIHRoZSBLZXl3b3JkIOKAnGludGVyZg==?= =?UTF-8?B?YWNl4oCdIGluIEMrKw==?= Date: Mon, 8 May 2017 13:48:54 -0700 (PDT) Lines: 259 Approved: news@gmane.org Message-ID: <45a81e95-d352-49ab-9c6e-7375aa41413c@isocpp.org> References: <9ee212eb-4037-40c4-94c3-57a9a170a4c3@isocpp.org> <1765502.4y06pMOS3s@tjmaciei-mobl1> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2457_1611138434.1494276534876" X-Trace: blaine.gmane.org 1494276535 26131 195.159.176.226 (8 May 2017 20:48:55 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 8 May 2017 20:48:55 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCX2XNFO6MPRBN5TYPEAKGQE4MY6ZZQ@isocpp.org Mon May 08 22:48:51 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f197.google.com ([209.85.161.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d7paN-0006fL-42 for gclcip-std-proposals@m.gmane.org; Mon, 08 May 2017 22:48:51 +0200 Original-Received: by mail-yw0-f197.google.com with SMTP id h21sf57559415ywc.4 for ; Mon, 08 May 2017 13:48:57 -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=dIuHMVRAr5RMfRmCcpc7CuafcX2h3uGLUCpmywWWeG0=; b=1G9cz29jQBWm2OnbNrz1RLI+Fh6Yj+geb6ulqYRRJadATAMrW1En0OD1psS0WURBxl weFQvb2w+RlB+72o+QKr8DqjFPEGbe2bOegq+wu7a2HpwHW14ZXP9dOCrNqDr/CV5jNr 2NeutwkDIHk9Ixe0+t8Gm8Om6sFEIR3wc8Ao9egVUxp69AtokRsvMdHXpbE2AniA0BUm PGBw4q+q64fAbMfq6DrbE3mnOKknqZLGLZ2eWa1YA0u3GiY5CnqM/DKqTbLs3nWR56Hz C8/1UBzoPYeP8MUkgOZ0Bb5jCKiT5b+i7/MjFbWt8ncu21B7fHWoK3zJtT03W3ATqFdb PPjw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; 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=dIuHMVRAr5RMfRmCcpc7CuafcX2h3uGLUCpmywWWeG0=; b=HgBJd2G3CFgbk49SNmpuWVLsOawTmml3pFvts/RMdXf1DG6WYYsITy/4YvZieciHNp jwPhwoo2foVqOqF8ptMkj4/MWhcIE6+RXnLAB8Ut0NCZO3K4784N1RPAWeR2RCQMFzts aw+yjuxHXHUBw1vkCqhCH3wC2z+0JUpTsKM6vLvksjR7HLSKoQmZMbz2ExHZsnyI4hlY +s11yzLCbEvI+zGGBq2LMRbBzGTu10r59+jPR35T7QZqofKUBjIqIsmpE20XoGtbIBfV UWgLCrFJzlcPUZHnc8VuSMaokx2eZVWWRaf08JLvW2to30g2eEXGogE3QfcPFdU2irth OS8Q== 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=dIuHMVRAr5RMfRmCcpc7CuafcX2h3uGLUCpmywWWeG0=; b=Fn0iAx236WyxgBGHaHnie59m3ABbmtJGjJrlJ5CdrQBewnodp5nujMpcaE2O8P1N6g hThmGZ3Rdq9ii1iADZ+ugszxUWMpIyOhWl6+aJakv/VsPXZRlvm/XrR4yTqmvR4m8/UP 0+f2gutAK8Ig85cdkebQNSVwPIl9xRsKHnuzojzBIS/LWGMUDAxQ4VLQfNvtGej6RoXj GhCYdb/4YTEFNSMWTFh9iWgbFawWwXyn+hNCUVj9dSW0XX6mzPM3ttg6cR0wSNBzk6e4 hTgb75v3YKATH/5SESuyNqArKelxybuZlI9BDuDojiqtDEVWbwlvnpP4c9JeHYVxwaZJ NNGw== X-Gm-Message-State: AN3rC/6NLwIBK/dU+nX+jhLpyPG+WO+msApRJjRVzh1QHfVkDutP2c5m jWU7tWS3th2WOQ== X-Received: by 10.129.91.130 with SMTP id p124mr31882772ywb.49.1494276536479; Mon, 08 May 2017 13:48:56 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.9.241 with SMTP id 46ls10773154otz.6.gmail; Mon, 08 May 2017 13:48:55 -0700 (PDT) X-Received: by 10.157.28.130 with SMTP id l2mr717854ota.17.1494276535389; Mon, 08 May 2017 13:48:55 -0700 (PDT) In-Reply-To: X-Original-Sender: jakob.riedle@gmail.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:32340 Archived-At: ------=_Part_2457_1611138434.1494276534876 Content-Type: multipart/alternative; boundary="----=_Part_2458_1204108005.1494276534876" ------=_Part_2458_1204108005.1494276534876 Content-Type: text/plain; charset=UTF-8 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/45a81e95-d352-49ab-9c6e-7375aa41413c%40isocpp.org. ------=_Part_2458_1204108005.1494276534876 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
At first I was very skeptical of the proposal to add = something that I though to be already in the language.
The to= pic 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 C= oncept
std::erased<Concept> efoo =3D foo;
func(efoo);=C2=A0 // Not a templatized function
Nice idea!

Can we make that e= ven more awesome?? YES!!

How about this:

v= oid func(){
=C2=A0// ...
}

int main(){
// Here the concept 'Callable' is used at a non-deduced = context (where no deduction happens)
// Therefore, the Concept will automatically be interpr= eted as an abstract class to which other types can be type erased to.
std::vector<Callable> myVec;
myVec.emplace( &func );
}

class MyClass{=
=C2=A0std::vecto= r<Callable= > myVec; // same applies here since we are in an unded= uced context

=C2=A0void= set_vector( std::vector<Callable> newVec ){ // This is still a function template where Callable might b= e deduced as std::function<void()>
=C2=A0 myVec =3D std::move(newVec);<= /span> // Here an implicit = conversion happens from the potentially specialized vector (e.g. std::vecto= r<std::function<void()>>) to the vector of type erased Callable= s
=C2= =A0}
}
<= div>
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 hel= pful:

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

std::vector&l= t;Callable= > foo1;
std::vector<std::function<void()&= gt;> fo= o2;=

do_someth= ing( foo1 ); // 'vec' will stay a vector o= f type erased Callables
do_something( foo2 ); <= /span>// 'vec= ' will be deduced to std::vector<std::function<void()>>

Again: Everything that can be deduced at com= pile time will and everything that cannot will be deferred to run time.Since this interpretation of concepts as implicit base classes only happen= s in undeduced contexts (this is currently not allowed), its not breaking c= ode.

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/45a81e95-d352-49ab-9c6e-7375aa41413c= %40isocpp.org.
------=_Part_2458_1204108005.1494276534876-- ------=_Part_2457_1611138434.1494276534876-- .