220 10472 <3c02d482-360c-40fc-973c-7a348566d2ff@isocpp.org> article Path: news.gmane.org!not-for-mail From: germandiago@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Researching any-like general type erasure (not a proposal as of now). Date: Thu, 1 May 2014 11:04:08 -0700 (PDT) Lines: 131 Approved: news@gmane.org Message-ID: <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_43_6226503.1398967448947" X-Trace: ger.gmane.org 1398967456 24209 80.91.229.3 (1 May 2014 18:04:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 1 May 2014 18:04:16 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDC2VXM4YYDRBGMZRKNQKGQELIINTJI@isocpp.org Thu May 01 20:04:12 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qc0-f197.google.com ([209.85.216.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WfvL9-0008H3-B7 for gclcip-std-proposals@m.gmane.org; Thu, 01 May 2014 20:04:11 +0200 Original-Received: by mail-qc0-f197.google.com with SMTP id i8sf11187485qcq.8 for ; Thu, 01 May 2014 11:04:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id: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=QzDyNUakjjFm8f5KBAAGs/yw6G6RIGZDO0nNWN+QaCY=; b=VSRdjEaS4G2PgbxB5KGMV8B/HdCqBhHVXNKzpaVSI9tN900N3LwbXDbPm6AldcoWBm uCIpIsOKRczNVozyMqik6idUGbExjRZOLU+OT5VMFGKD2IOU3DnJl+ErSJHwwq0VbKgR 2Uf/PKWq55yEPrVkOEuWiy7XEUK7+DvUDgJdfoy5W3weCEN7cXo+gevhHMXtZ/B/hRbc txNwfFAGF3GYsboUmyajlt7zuUNaqjSXCRDb5vlWqU0wzhbYZyXzlUFm542Kr0g0UTCI dHvGvL2aomY0BjyqFUD67Vpp9bLGXU8qbOrZGKu5MEVHWwc2fgPfR1oP6i0s7xWp84Nm UeiA== 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:message-id: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=QzDyNUakjjFm8f5KBAAGs/yw6G6RIGZDO0nNWN+QaCY=; b=gPRdGZslmptBfv4PiineL/7KGy3mVPr2JaFmb7d2eeoZmfXejk/tslnCLHhGdh0lhZ nwkvTr2O8vISO2c4uV3yOMlpH2X6NdyBiyqkpOYfP+ZWsz+f9d85fCA/hlzpxsdXIZGp D51nBntfdDTSqIo6bp1LLQK+PPSqFGN5YhdicZTTmHSDHbf+ZWqMzB/pHTkf5xmeQS5V PIZdffzEO3tfQmj1FHmG9RGwMCemQfeN2us2h+h5D2bLNTMin631utc1pHoIsv5ljRCq ASLKAHhSwLm999eIh03n5W7HoI9cSfTDVYj4AoYlb6viU96Rsp2mKcZ4ifdzW1s9KIDh Xgng== X-Gm-Message-State: ALoCoQkc7szCDVPa4h2um31+ba/bZlH5qgr8hJr3++aKEFOgbMz6lKer7dPDC7TEfi8dEyhy68fS X-Received: by 10.52.165.179 with SMTP id yz19mr5503063vdb.1.1398967450523; Thu, 01 May 2014 11:04:10 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.153.41 with SMTP id vd9ls528606obb.27.gmail; Thu, 01 May 2014 11:04:09 -0700 (PDT) X-Received: by 10.182.142.38 with SMTP id rt6mr86124obb.10.1398967449523; Thu, 01 May 2014 11:04:09 -0700 (PDT) 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:10472 Archived-At: ------=_Part_43_6226503.1398967448947 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello everyone, There is a thing I am really interested in that I think would be of general= =20 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 them= =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 into= =20 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 maybe,= =20 and would be related also to overloading operator. (which currently cannot be done). Overloading this= =20 operator could enable classes like copy_on_write and optional to have the same interface as= =20 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 cumbersom= e in=20 general. Is there anyone I am not aware of working on this? Looking at Sean Parent's= =20 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_43_6226503.1398967448947 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello everyone,

There is a thing I am r= eally interested in that I think would be of general interest for the c++ c= ommunity.
I would like to generate some discussion on the topic. = The intention of this post is to collect ideas
and prior art to a= ny-type like erasure.

So far we have library versi= ons of any-type like erasure, but none of them is perfect. For reference
on the available solutions I will leave here the excellent blog ent= ries from Andrzej:

    =  
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 think of several solutions:

1. Build type erasure directly into the language. This woul= d require maybe, and would be related also
to overloading operato= r. (which currently cannot be done). Overloading this operator could enable=
classes like copy_on_write<T> and optional<T> to hav= e the same interface as the original class,
but this goes beyond = the intention of this research.
2. Take advantage of static ty= pe reflection + code generation to build a libra= ry solution.
3. Generate a runtime erased interface from a concep= t specification?


Personally I would= like to get rid of 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? Loo= king at Sean Parent's presentation, I think
he must have a good i= dea of what we would 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_43_6226503.1398967448947-- .