220 10473 article Path: news.gmane.org!not-for-mail From: germandiago@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Researching any-like general type erasure (not a proposal as of now). Date: Thu, 1 May 2014 11:09:27 -0700 (PDT) Lines: 187 Approved: news@gmane.org Message-ID: References: <3c02d482-360c-40fc-973c-7a348566d2ff@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_54_25944340.1398967767438" X-Trace: ger.gmane.org 1398967777 29526 80.91.229.3 (1 May 2014 18:09:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 1 May 2014 18:09:37 +0000 (UTC) Cc: germandiago@gmail.com To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDC2VXM4YYDRBWE3RKNQKGQEDSIDTGA@isocpp.org Thu May 01 20:09:31 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f197.google.com ([209.85.223.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WfvQI-0006Pq-SQ for gclcip-std-proposals@m.gmane.org; Thu, 01 May 2014 20:09:31 +0200 Original-Received: by mail-ie0-f197.google.com with SMTP id rd18sf17987681iec.8 for ; Thu, 01 May 2014 11:09:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type; bh=TiDGUkgtAmG7CExnHAdAetjk8djt9YADB7NmOb60QPk=; b=xFAyoAHkhcH8/Z3r5MR217l7CuNSt/mjDJqT//B4e9snQ44szjgxlfVbniyJ8P56zw MGfELas9K/MeEwc8OYw1sy/P/wBtVzC6IpQlSsXFB7YufblOCwfcdkteY4b1KUaKFRaU bbjBWw4Tajar+5Ugxk0izAnwZqR8SrA3qkKeuyJPP9fAiu9zGPuFJPN6mv3KC3RoxvtF QXKEgz9OJBcLfcYrjJFy6gV1W4yrcJPIHRLiwmuxCs9xOax6IcImuTUhIIH6obBumTmP jwfIV/2BBw4xFhqRjDZ86xVzaRuLLCn1FPCLPsXCkf/Cb4St879roNgcLJorjt93brUo xSJg== 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:x-original-sender:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=TiDGUkgtAmG7CExnHAdAetjk8djt9YADB7NmOb60QPk=; b=O2gqyq3lXwgWA1X44arCbpuYxXwQ4a+PdRaJxTO1ARdLRWObRxr6lz31rksPWc5QX3 d84g9BipC6+tMqm+8D6p4XaOOr170oweo++n6C2wpMiB76d6fUTgj7jTNAC8W1+/L+mf eeCD4Qs/LRsu3N56oMVdca7CTigIBq8wh1q64LvbzgAsSchuqO/mhzaB0PFbz9iqFc5v bOdFLwANoiMoW0snB64qoVaQ1h1EeSBQoHoJT8pECfjK4nxOc/8vLYEHRWO7r3dDi4kt TMK+qOP0U9y6hFjsy2GrJiBwcuHlqK/xkW4UvbvPbjksQigPfLrtVyhou40u/IvWmebc k0aw== X-Gm-Message-State: ALoCoQm3X73Ke/5cDfY7JAcOSFzfgOdK6uTe+PDKgwB/pbMy5vP3kYfqwIQUHLGERj1PjFirlSV8 X-Received: by 10.50.33.101 with SMTP id q5mr1992585igi.3.1398967769663; Thu, 01 May 2014 11:09:29 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.66.8 with SMTP id b8ls613420obt.73.gmail; Thu, 01 May 2014 11:09:28 -0700 (PDT) X-Received: by 10.182.200.163 with SMTP id jt3mr26760obc.25.1398967768757; Thu, 01 May 2014 11:09:28 -0700 (PDT) In-Reply-To: <3c02d482-360c-40fc-973c-7a348566d2ff@isocpp.org> X-Original-Sender: germandiago@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:10473 Archived-At: ------=_Part_54_25944340.1398967767438 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In 2. I forgot to mention that the library solution would be something like= =20 poly, that would generate a class that has the same interface as myclass, but it's=20 polymorphic. We also should consider how a poly_ref should behave. El viernes, 2 de mayo de 2014 01:04:08 UTC+7, germa...@gmail.com escribi=C3= =B3: > > Hello everyone, > > There is a thing I am really interested in that I think would be of=20 > general interest for the c++ community. > I would like to generate some discussion on the topic. The intention of= =20 > this post is to collect ideas > and prior art to any-type like erasure. > > So far we have library versions of any-type like erasure, but none of the= m=20 > is perfect. For reference > on the available solutions I will leave here the excellent blog entries= =20 > from Andrzej: > > http://akrzemi1.wordpress.com/2013/11/18/type-erasure-part-i/ > http://akrzemi1.wordpress.com/2013/12/06/type-erasure-part-ii/ > http://akrzemi1.wordpress.com/2013/12/11/type-erasure-part-iii/ > http://akrzemi1.wordpress.com/2014/01/13/type-erasure-part-iv/ > =20 > What I wonder is how we could approach a perfect solution to have this=20 > into the language avoiding the=20 > boiler-plate. > > For now I can think of several solutions: > > 1. Build type erasure directly into the language. This would require=20 > maybe, and would be related also > to overloading operator. (which currently cannot be done). Overloading=20 > this operator could enable > classes like copy_on_write and optional to have the same interface= =20 > as the original class, > but this goes beyond the intention of this research. > 2. Take advantage of static type reflection > + code generation to=20 > build a library solution. > 3. Generate a runtime erased interface from a concept specification? > > > Personally I would like to get rid of traditional OO=20 > inheritance and use this solution all the time, but it=C2=B4s too cumbers= ome=20 > in general. > > Is there anyone I am not aware of working on this? Looking at Sean=20 > Parent's presentation, I think > he must have a good idea of what we would need to make this happen?=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_54_25944340.1398967767438 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In 2. I forgot to mention that the library solution would = be something like poly<myclass>, that would
generate a class that= has the same interface as myclass, but it's polymorphic.

We also should consider how a poly_ref<myclass> should behave= ..



El viernes, 2 de mayo de 2014 01:04:08 U= TC+7, germa...@gmail.com escribi=C3=B3:
Hello everyone,

There is a th= ing I am really interested in that I think would be of general interest for= the c++ community.
I would like to generate some discussion on t= he topic. The intention of this post is to collect ideas
and prio= r art to any-type like erasure.

So far we have lib= rary versions of any-type like erasure, but none of them is perfect. For re= ference
on the available solutions I will leave here the excellen= t blog entries from Andrzej:

    http://ak= rzemi1.wordpress.com/2013/11/18/type-erasure-part-i/
     
What I wonder is how we= could approach a perfect solution to have this into the language avoiding = the 
boiler-plate.

For now I can th= ink of several solutions:

1. Build type erasure di= rectly into the language. This would require maybe, and would be related al= so
to overloading operator. (which currently cannot be done). Ove= rloading this operator could enable
classes like copy_on_write<= ;T> and optional<T> to have the same interface as the original cla= ss,
but this goes beyond the intention of this research.
2. Take advantage of static type reflection + = code generation to build a library solution.
=
3. Generate a runtime erased interface from a concept specification?


Personally I would like to get rid o= f traditional OO 
inheritance and use this solution all the = time, but it=C2=B4s too cumbersome  in general.

Is there anyone I am not aware of working on this? Looking at Sean Paren= t's presentation, I think
he must have a good idea of what we wou= ld need to make this happen? 


--

---
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_54_25944340.1398967767438-- .