--20cf307f31708364fc04e72b697b
Content-Type: text/plain; charset=ISO-8859-1

I was listening to the C++ Seasoning talk at Going Native 2013. One thing
he spoke about but did not explicitly name was Type Erasure as a means to
"avoid" pointers that are currently necessary to use polymorphism in C++.

I have used type erasure in a few places in the past and have found that
having value semantics with polymorphic types is very useful. Also the
ability to have runtime polymorphism without using inheritance on the
concrete external type also has many advantages.

The problem with type erasure generally though is the amount of boilerplate
that is required to implement an interface.

Have there been any requests or proposals to have language support to allow
polymorphic value types using something like type-erasure?

I know there is a library implementation in boost, but looking at its usage
it seems like a temporary stop gap measure for something that would be of
great benefit in the language instead.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--20cf307f31708364fc04e72b697b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I was listening to the C++ Seasoning talk at Going Native =
2013. One thing he spoke about but did not explicitly name was Type Erasure=
 as a means to &quot;avoid&quot; pointers that are currently necessary to u=
se polymorphism in C++.<div>
<br></div><div>I have used type erasure in a few places in the past and hav=
e found that having value semantics with polymorphic types is very useful. =
Also the ability to have runtime polymorphism without using inheritance on =
the concrete external type also has many advantages.</div>
<div><br></div><div>The problem with type erasure generally though is the a=
mount of boilerplate that is required to implement an interface.</div><div>=
<br></div><div>Have there been any requests or proposals to have language s=
upport to allow polymorphic value types using something like type-erasure?=
=A0</div>
<div><br></div><div>I know there is a library implementation in boost, but =
looking at its usage it seems like a temporary stop gap measure for somethi=
ng that would be of great benefit in the language instead.</div><div><br>
</div><div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--20cf307f31708364fc04e72b697b--

.

On 9/24/13 8:45 PM, Brendon Costa wrote:
....
> The problem with type erasure generally though is the amount of
> boilerplate that is required to implement an interface.
>
> Have there been any requests or proposals to have language support to
> allow polymorphic value types using something like type-erasure?
>
There have not been any, for the simple reason that nobody has written
one. I gauge that if there was it would be well received.
Aside from a dedicated proposal, another possibility is a suitably
sophisticated (static) reflection facility, which could enable a library
solution that doesn't suffer from the staggering amount of boilerplate.
There has been no progress on that front in this meeting, but there is a
active Study Group for reflection, so that I am moderately optimistic
for the future.

regards

Fabio

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--001a11c37e30c0f85904e7305f7e
Content-Type: text/plain; charset=ISO-8859-1

On 25 September 2013 06:02, Fabio Fracassi <f.fracassi@gmx.net> wrote:

> On 9/24/13 8:45 PM, Brendon Costa wrote:
> ...
>
>  The problem with type erasure generally though is the amount of
>> boilerplate that is required to implement an interface.
>>
>> Have there been any requests or proposals to have language support to
>> allow polymorphic value types using something like type-erasure?
>>
>>  There have not been any, for the simple reason that nobody has written
> one. I gauge that if there was it would be well received.
> Aside from a dedicated proposal, another possibility is a suitably
> sophisticated (static) reflection facility, which could enable a library
> solution that doesn't suffer from the staggering amount of boilerplate.
> There has been no progress on that front in this meeting, but there is a
> active Study Group for reflection, so that I am moderately optimistic for
> the future.
>
>
Would
http://open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3339.pdf
not apply?

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a11c37e30c0f85904e7305f7e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 25 September 2013 06:02, Fabio Fracassi <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:f.fracassi@gmx.net" target=3D"_blank">f.fracassi@gmx.net</a=
>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">On 9/24/13 8:45 PM, Brend=
on Costa wrote:<br>
....<div class=3D"im"><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">
The problem with type erasure generally though is the amount of boilerplate=
 that is required to implement an interface.<br>
<br>
Have there been any requests or proposals to have language support to allow=
 polymorphic value types using something like type-erasure?<br>
<br>
</blockquote></div>
There have not been any, for the simple reason that nobody has written one.=
 I gauge that if there was it would be well received.<br>
Aside from a dedicated proposal, another possibility is a suitably sophisti=
cated (static) reflection facility, which could enable a library solution t=
hat doesn&#39;t suffer from the staggering amount of boilerplate. There has=
 been no progress on that front in this meeting, but there is a active Stud=
y Group for reflection, so that I am moderately optimistic for the future.<=
br>

<br></blockquote><div><br></div><div>Would<br><a href=3D"http://open-std.or=
g/JTC1/SC22/WG21/docs/papers/2012/n3339.pdf">http://open-std.org/JTC1/SC22/=
WG21/docs/papers/2012/n3339.pdf</a><br></div><div>not apply?<br></div></div=
>
</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c37e30c0f85904e7305f7e--

.

This is a multi-part message in MIME format.
--------------060401010404090009060906
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 9/25/13 2:40 AM, Ville Voutilainen wrote:
>
>
>
> On 25 September 2013 06:02, Fabio Fracassi <f.fracassi@gmx.net
> <mailto:f.fracassi@gmx.net>> wrote:
>
>     On 9/24/13 8:45 PM, Brendon Costa wrote:
>     ...
>
>         The problem with type erasure generally though is the amount
>         of boilerplate that is required to implement an interface.
>
>         Have there been any requests or proposals to have language
>         support to allow polymorphic value types using something like
>         type-erasure?
>
>     There have not been any, for the simple reason that nobody has
>     written one. I gauge that if there was it would be well received.
>     Aside from a dedicated proposal, another possibility is a suitably
>     sophisticated (static) reflection facility, which could enable a
>     library solution that doesn't suffer from the staggering amount of
>     boilerplate. There has been no progress on that front in this
>     meeting, but there is a active Study Group for reflection, so that
>     I am moderately optimistic for the future.
>
>
> Would
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3339.pdf
> not apply?
> --
I do not think so, although it goes into this direction. As far as I can
see this proposal does employ type erasure to do  coping, but is not a
general tool to do type erasure for various interfaces. I have not
looked into this paper in detail though.


--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--------------060401010404090009060906
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">On 9/25/13 2:40 AM, Ville Voutilainen
      wrote:<br>
    </div>
    <blockquote
cite=3D"mid:CAFk2RUZbzPsKAD2vw7jjagei98ftEwnVdv3_oBw7YdgctY0zVw@mail.gmail.=
com"
      type=3D"cite">
      <div dir=3D"ltr"><br>
        <div class=3D"gmail_extra"><br>
          <br>
          <div class=3D"gmail_quote">On 25 September 2013 06:02, Fabio
            Fracassi <span dir=3D"ltr">&lt;<a moz-do-not-send=3D"true"
                href=3D"mailto:f.fracassi@gmx.net" target=3D"_blank">f.frac=
assi@gmx.net</a>&gt;</span>
            wrote:<br>
            <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px
              0.8ex;border-left:1px solid
              rgb(204,204,204);padding-left:1ex">On 9/24/13 8:45 PM,
              Brendon Costa wrote:<br>
              ...
              <div class=3D"im"><br>
                <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px
                  0px 0.8ex;border-left:1px solid
                  rgb(204,204,204);padding-left:1ex">
                  The problem with type erasure generally though is the
                  amount of boilerplate that is required to implement an
                  interface.<br>
                  <br>
                  Have there been any requests or proposals to have
                  language support to allow polymorphic value types
                  using something like type-erasure?<br>
                  <br>
                </blockquote>
              </div>
              There have not been any, for the simple reason that nobody
              has written one. I gauge that if there was it would be
              well received.<br>
              Aside from a dedicated proposal, another possibility is a
              suitably sophisticated (static) reflection facility, which
              could enable a library solution that doesn't suffer from
              the staggering amount of boilerplate. There has been no
              progress on that front in this meeting, but there is a
              active Study Group for reflection, so that I am moderately
              optimistic for the future.<br>
              <br>
            </blockquote>
            <div><br>
            </div>
            <div>Would<br>
              <a moz-do-not-send=3D"true"
                href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2012=
/n3339.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3339.pdf</=
a><br>
            </div>
            <div>not apply?<br>
            </div>
          </div>
        </div>
      </div>
      -- <br>
    </blockquote>
    I do not think so, although it goes into this direction. As far as I
    can see this proposal does employ type erasure to do=A0 coping, but is
    not a general tool to do type erasure for various interfaces. I have
    not looked into this paper in detail though. <br>
    <br>
    <br>
  </body>
</html>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--------------060401010404090009060906--

.

--089e0160b8283fb24d04e735c363
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Sep 25, 2013 at 3:43 PM, Fabio Fracassi <f.fracassi@gmx.net> wrote:

> I do not think so, although it goes into this direction. As far as I can
> see this proposal does employ type erasure to do  coping, but is not a
> general tool to do type erasure for various interfaces. I have not looked
> into this paper in detail though.


Are you thinking about something like Boost.TypeErasure
http://www.boost.org/doc/libs/1_54_0/doc/html/boost_typeerasure.html ?

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--089e0160b8283fb24d04e735c363
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Wed, Sep 25, 2013 at 3:43 PM, Fabio Fracassi <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:f.fracassi@gmx.net" target=3D"_blank">f.fracassi@gmx.net</a>&g=
t;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">I do not think so, although it goes into this direction. A=
s far as I
    can see this proposal does employ type erasure to do=A0 coping, but is
    not a general tool to do type erasure for various interfaces. I have
    not looked into this paper in detail though.</blockquote></div><br>Are =
you thinking about something like Boost.TypeErasure=A0<a href=3D"http://www=
..boost.org/doc/libs/1_54_0/doc/html/boost_typeerasure.html">http://www.boos=
t.org/doc/libs/1_54_0/doc/html/boost_typeerasure.html</a>=A0?<br>
<br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e0160b8283fb24d04e735c363--

.

--047d7bdc979c0db67e04e7363f69
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 25 September 2013 09:06, Klaim - Jo=EBl Lamotte <mjklaim@gmail.com> wrot=
e:

>
> On Wed, Sep 25, 2013 at 3:43 PM, Fabio Fracassi <f.fracassi@gmx.net>wrote=
:
>
>> I do not think so, although it goes into this direction. As far as I can
>> see this proposal does employ type erasure to do  coping, but is not a
>> general tool to do type erasure for various interfaces. I have not looke=
d
>> into this paper in detail though.
>
>
> Are you thinking about something like Boost.TypeErasure
> http://www.boost.org/doc/libs/1_54_0/doc/html/boost_typeerasure.html ?
>

I think Boost.TypeErasure is great in the way Boost.Lambda was great.  It
shows how far you can get with a library solution, but it really needs core
language support to make it accessible.  People fall back on just using
virtual functions in their interfaces because it is too hard (tedious to
code; lots of noise when debugging, etc.) to give those types value
semantics.

That being said, due to previous conversations I believe we need concepts
as a building block for type erasure, and even then I suspect it will still
need language changes to make it work easily.
--=20
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--=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/.

--047d7bdc979c0db67e04e7363f69
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 25 September 2013 09:06, Klaim - Jo=EBl Lamotte <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:mjklaim@gmail.com" target=3D"_blank">mjkla=
im@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"im"><br><div class=3D"gmail_quote">On Wed, Sep 25, 2013 at 3:=
43 PM, Fabio Fracassi <span dir=3D"ltr">&lt;<a href=3D"mailto:f.fracassi@gm=
x.net" target=3D"_blank">f.fracassi@gmx.net</a>&gt;</span> wrote:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">I do not think so, although it goes into this direction. A=
s far as I
    can see this proposal does employ type erasure to do=A0 coping, but is
    not a general tool to do type erasure for various interfaces. I have
    not looked into this paper in detail though.</blockquote></div><br></di=
v>Are you thinking about something like Boost.TypeErasure=A0<a href=3D"http=
://www.boost.org/doc/libs/1_54_0/doc/html/boost_typeerasure.html" target=3D=
"_blank">http://www.boost.org/doc/libs/1_54_0/doc/html/boost_typeerasure.ht=
ml</a>=A0?<br>

</div></div></blockquote><div><br></div><div>I think Boost.TypeErasure is g=
reat in the way Boost.Lambda was great. =A0It shows how far you can get wit=
h a library solution, but it really needs core language support to make it =
accessible. =A0People fall back on just using virtual functions in their in=
terfaces because it is too hard (tedious to code; lots of noise when debugg=
ing, etc.) to give those types value semantics.</div>

<div><br></div><div>That being said, due to previous conversations I believ=
e we need concepts as a building block for type erasure, and even then I su=
spect it will still need language changes to make it work easily.</div>

</div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto=
:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=
=A0 (847) 691-1404
</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7bdc979c0db67e04e7363f69--

.

This is a multi-part message in MIME format.
--------------020709030200010108040601
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

On 9/25/13 9:06 AM, Klaim - Jo=EBl Lamotte wrote:
>
> On Wed, Sep 25, 2013 at 3:43 PM, Fabio Fracassi <f.fracassi@gmx.net=20
> <mailto:f.fracassi@gmx.net>> wrote:
>
>     I do not think so, although it goes into this direction. As far as
>     I can see this proposal does employ type erasure to do  coping,
>     but is not a general tool to do type erasure for various
>     interfaces. I have not looked into this paper in detail though.
>
>
> Are you thinking about something like Boost.TypeErasure=20
> http://www.boost.org/doc/libs/1_54_0/doc/html/boost_typeerasure.html ?
>
Yes, but without all the boilerplate. Basically what I would be like to=20
be able to do is this:


struct A {
  void foo();
  void bar();
};

struct B {
  void foo();
  void bar();
  void baz();
};

struct I {
  void foo();
  void bar();
};

void f(type_erased<I> i) {
  i.foo();
  i.bar();
}

int main() {
     A a;
     B b;

     f(a);
     f(b);
}

And have it do the expected thing (i.e. call A::foo, A::bar and then=20
B::foo and B::bar).

Boost type_erasure goes as far as one can go as a pure library solution=20
to this problem, but it still needs quite a bit of boilerplate (and some=20
restrictions in usage) to make "I" work with type_erased<I>.
There are two ways we could make the above work out of the box, one is a=20
dedicated language feature that enables exactly this, the other is to=20
have a general (static) reflection facility, which could enable a=20
library to create the needed boilerplate automatically.


> --=20
>
> ---
> You received this message because you are subscribed to the Google=20
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send=20
> an email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at=20
> http://groups.google.com/a/isocpp.org/group/std-proposals/.

--=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/.

--------------020709030200010108040601
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">On 9/25/13 9:06 AM, Klaim - Jo=EBl
      Lamotte wrote:<br>
    </div>
    <blockquote
cite=3D"mid:CAOU91OO6dYYj3FxygnFMuQBJgCK1o=3DLV0noEa=3DcsvZDjVueKPg@mail.gm=
ail.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra"><br>
          <div class=3D"gmail_quote">On Wed, Sep 25, 2013 at 3:43 PM,
            Fabio Fracassi <span dir=3D"ltr">&lt;<a
                moz-do-not-send=3D"true" href=3D"mailto:f.fracassi@gmx.net"
                target=3D"_blank">f.fracassi@gmx.net</a>&gt;</span> wrote:<=
br>
            <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-=
style:solid;padding-left:1ex">I
              do not think so, although it goes into this direction. As
              far as I can see this proposal does employ type erasure to
              do=A0 coping, but is not a general tool to do type erasure
              for various interfaces. I have not looked into this paper
              in detail though.</blockquote>
          </div>
          <br>
          Are you thinking about something like Boost.TypeErasure=A0<a
            moz-do-not-send=3D"true"
href=3D"http://www.boost.org/doc/libs/1_54_0/doc/html/boost_typeerasure.htm=
l">http://www.boost.org/doc/libs/1_54_0/doc/html/boost_typeerasure.html</a>=
=A0?<br>
          <br>
        </div>
      </div>
    </blockquote>
    Yes, but without all the boilerplate. Basically what I would be like
    to be able to do is this:<br>
    <br>
    <br>
    struct A { <br>
    =A0void foo();<br>
    =A0void bar();<br>
    };<br>
    <br>
    struct B {<br>
    =A0void foo();<br>
    =A0void bar();<br>
    =A0void baz();<br>
    };<br>
    <br>
    struct I {<br>
    =A0void foo();<br>
    =A0void bar();<br>
    };<br>
    <br>
    void f(type_erased&lt;I&gt; i) {<br>
    =A0i.foo();<br>
    =A0i.bar();<br>
    }<br>
    <br>
    int main() {<br>
    =A0=A0=A0 A a;<br>
    =A0=A0=A0 B b;<br>
    <br>
    =A0=A0=A0 f(a);<br>
    =A0=A0=A0 f(b);<br>
    }<br>
    <br>
    And have it do the expected thing (i.e. call A::foo, A::bar and then
    B::foo and B::bar).<br>
    <br>
    Boost type_erasure goes as far as one can go as a pure library
    solution to this problem, but it still needs quite a bit of
    boilerplate (and some restrictions in usage) to make "I" work with
    type_erased&lt;I&gt;.<br>
    There are two ways we could make the above work out of the box, one
    is a dedicated language feature that enables exactly this, the other
    is to have a general (static) reflection facility, which could
    enable a library to create the needed boilerplate automatically.<br>
    <br>
    <br>
    <blockquote
cite=3D"mid:CAOU91OO6dYYj3FxygnFMuQBJgCK1o=3DLV0noEa=3DcsvZDjVueKPg@mail.gm=
ail.com"
      type=3D"cite">-- <br>
      =A0<br>
      --- <br>
      You received this message because you are subscribed to the Google
      Groups "ISO C++ Standard - Future Proposals" group.<br>
      To unsubscribe from this group and stop receiving emails from it,
      send an email to <a class=3D"moz-txt-link-abbreviated" href=3D"mailto=
:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org=
</a>.<br>
      To post to this group, send email to <a class=3D"moz-txt-link-abbrevi=
ated" href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>=
..<br>
      Visit this group at <a moz-do-not-send=3D"true"
        href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/"=
>http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
    </blockquote>
    <br>
  </body>
</html>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--------------020709030200010108040601--

.

--001a11c34b4895e75204e7365b6b
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Sep 25, 2013 at 4:40 PM, Nevin Liber <nevin@eviloverlord.com> wrote:

>
> I think Boost.TypeErasure is great in the way Boost.Lambda was great.  It
> shows how far you can get with a library solution, but it really needs core
> language support to make it accessible.  People fall back on just using
> virtual functions in their interfaces because it is too hard (tedious to
> code; lots of noise when debugging, etc.) to give those types value
> semantics.
>

I agree.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a11c34b4895e75204e7365b6b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Wed, Sep 25, 2013 at 4:40 PM, Nevin Liber <span dir=3D"ltr">&lt;<a href=
=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com=
</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"adM"><div class=3D"im"><div><b=
r></div></div></div><div>I think Boost.TypeErasure is great in the way Boos=
t.Lambda was great. =A0It shows how far you can get with a library solution=
, but it really needs core language support to make it accessible. =A0Peopl=
e fall back on just using virtual functions in their interfaces because it =
is too hard (tedious to code; lots of noise when debugging, etc.) to give t=
hose types value semantics.</div>
</blockquote></div><br>I agree.</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c34b4895e75204e7365b6b--

.

On Wed, Sep 25, 2013 at 09:41:55AM -0500, Fabio Fracassi wrote:
> On 9/25/13 9:06 AM, Klaim - Jo=EBl Lamotte wrote:
> >
> >On Wed, Sep 25, 2013 at 3:43 PM, Fabio Fracassi <f.fracassi@gmx.net=20
> ><mailto:f.fracassi@gmx.net>> wrote:
> >
> >    I do not think so, although it goes into this direction. As far as
> >    I can see this proposal does employ type erasure to do  coping,
> >    but is not a general tool to do type erasure for various
> >    interfaces. I have not looked into this paper in detail though.
> >
> >
> >Are you thinking about something like Boost.TypeErasure=20
> >http://www.boost.org/doc/libs/1_54_0/doc/html/boost_typeerasure.html ?
> >
> Yes, but without all the boilerplate. Basically what I would be like to=
=20
> be able to do is this:
>=20
> [example]
>=20

I think this sounds a lot like the old signature extension of g++ 2.95.

There is a paper describing the extension:
http://docs.lib.purdue.edu/cgi/viewcontent.cgi?article=3D2224&context=3Dcst=
ech

/MF

--=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_1083_13538722.1380144440967
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Looking at Fabios example this is very similar to templates. But I=20
understand that you want this to work in runtime i.e. with a reference to=
=20
any of A or B coming in to the function, unknown at compile time. So the=20
boilerplate code required would include a class with virtual methods for=20
each method of the I class and subclasses forwarding to each of A, B and so=
=20
on, along with magically creating a class type_erased<I> with the same=20
methods as I but virtual, which is the base class of all the A and B=20
boilerplate classes. The subclasses would need to have a reference to the=
=20
actual A or B object to use as this pointer for the forwarding calls.=20

Now, the tricky question is how do you call the function f with something=
=20
that can be an A or a B (selectable at runtime) when the classes have no=20
common ancestor. I just can't understand how this can happen, and there is=
=20
no hint of it in Fabios example which looks like a typical template=20
function example except that it requires an extra interface class (which in=
=20
principle acts as a concept).

Even if there is a way to call f I think that the extreme complexity of=20
entering this into the standard would be a big roadblock and I think it=20
goes against the spirit of the language as it hide performance degrading=20
functionality under an inconspicuous syntax. Here you think you do a simple=
=20
call and instead you create a temporary object and perform virtual calls on=
=20
it through a reference. If this got usage instead of templates due to its=
=20
simpler syntax program performance would go down significantly.

A way to wrap a A as an I without inheritance would however be useful in=20
some cases, but I think this would sit better as a new kind of cast, for=20
instance interface_cast<I&>(a). f would take an I& and the I class would=20
declare the methods pure virtual so there is nothing special on the=20
function side, and you see what performance you can expect. The cast=20
creates a wrapper which inherits I and does "virtual perfect forwarding" to=
=20
like named methods in A. However I don't think that the usefulness of this=
=20
is large enough to warrant the core language extensions required. Ownership=
=20
and exception issues seem to be able to make even this complex, especially=
=20
if you want a real by value semantic.

I would rather see a smaller feature something like this:

struct I {
    virtual void foo() =3D 0;
    virtual void bar() =3D 0;
};

template<typename T> structI_impl : public I {
    I_impl(T& t) : my_t(t) {}

    using * =3D my_t;     // Here's the news: This automatically implements=
=20
all pure virtual methods in bases by calling the corresponding method in T=
=20
via the my_t reference. a method name or maybe a comma separated list ok=20
also.

    T& my_t;
};

Den onsdagen den 25:e september 2013 kl. 18:59:13 UTC+2 skrev Magnus=20
Fromreide:
>
> On Wed, Sep 25, 2013 at 09:41:55AM -0500, Fabio Fracassi wrote:=20
> > On 9/25/13 9:06 AM, Klaim - Jo=EF=BF=BDl Lamotte wrote:=20
> > >=20
> > >On Wed, Sep 25, 2013 at 3:43 PM, Fabio Fracassi <f.fra...@gmx.net<java=
script:>=20
> > ><mailto:f.fra...@gmx.net <javascript:>>> wrote:=20
> > >=20
> > >    I do not think so, although it goes into this direction. As far as=
=20
> > >    I can see this proposal does employ type erasure to do  coping,=20
> > >    but is not a general tool to do type erasure for various=20
> > >    interfaces. I have not looked into this paper in detail though.=20
> > >=20
> > >=20
> > >Are you thinking about something like Boost.TypeErasure=20
> > >http://www.boost.org/doc/libs/1_54_0/doc/html/boost_typeerasure.html ?=
=20
> > >=20
> > Yes, but without all the boilerplate. Basically what I would be like to=
=20
> > be able to do is this:=20
> >=20
> > [example]=20
> >=20
>
> I think this sounds a lot like the old signature extension of g++ 2.95.=
=20
>
> There is a paper describing the extension:=20
> http://docs.lib.purdue.edu/cgi/viewcontent.cgi?article=3D2224&context=3Dc=
stech=20
>
> /MF=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_1083_13538722.1380144440967
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Looking at Fabios example this is very similar to template=
s. But I understand that you want this to work in runtime i.e. with a refer=
ence to any of A or B coming in to the function, unknown at compile time. S=
o the boilerplate code required would include a class with virtual methods =
for each method of the I class and subclasses forwarding to each of A, B an=
d so on, along with magically creating a class type_erased&lt;I&gt; with th=
e same methods as I but virtual, which is the base class of all the A and B=
 boilerplate classes. The subclasses would need to have a reference to the =
actual A or B object to use as this pointer for the forwarding calls.&nbsp;=
<div><br></div><div>Now, the tricky question is how do you call the functio=
n f with something that can be an A or a B (selectable at runtime) when the=
 classes have no common ancestor. I just can't understand how this can happ=
en, and there is no hint of it in Fabios example which looks like a typical=
 template function example except that it requires an extra interface class=
 (which in principle acts as a concept).</div><div><br></div><div>Even if t=
here is a way to call f I think that the extreme complexity of entering thi=
s into the standard would be a big roadblock and I think it goes against th=
e spirit of the language as it hide performance degrading functionality und=
er an inconspicuous syntax. Here you think you do a simple call and instead=
 you create a temporary object and perform virtual calls on it through a re=
ference. If this got usage instead of templates due to its simpler syntax p=
rogram performance would go down significantly.</div><div><br></div><div>A =
way to wrap a A as an I without inheritance would however be useful in some=
 cases, but I think this would sit better as a new kind of cast, for instan=
ce interface_cast&lt;I&amp;&gt;(a). f would take an I&amp; and the I class =
would declare the methods pure virtual so there is nothing special on the f=
unction side, and you see what performance you can expect. The cast creates=
 a wrapper which inherits I and does "virtual perfect forwarding" to like n=
amed methods in A. However I don't think that the usefulness of this is lar=
ge enough to warrant the core language extensions required. Ownership and e=
xception issues seem to be able to make even this complex, especially if yo=
u want a real by value semantic.</div><div><br></div><div>I would rather se=
e a smaller feature something like this:</div><div><br></div><div>struct I =
{</div><div>&nbsp; &nbsp; virtual void foo() =3D 0;</div><div>&nbsp; &nbsp;=
 virtual void bar() =3D 0;</div><div>};</div><div><br></div><div>template&l=
t;typename T&gt; structI_impl : public I {</div><div>&nbsp; &nbsp; I_impl(T=
&amp; t) : my_t(t) {}</div><div><br></div><div>&nbsp; &nbsp; using * =3D my=
_t; &nbsp; &nbsp; // Here's the news: This automatically implements all pur=
e virtual methods in bases by calling the corresponding method in T via the=
 my_t reference. a method name or maybe a comma separated list ok also.</di=
v><div><br></div><div>&nbsp; &nbsp; T&amp; my_t;</div><div>};</div><div><br=
>Den onsdagen den 25:e september 2013 kl. 18:59:13 UTC+2 skrev Magnus Fromr=
eide:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">On Wed, Sep 25, 2013 at 0=
9:41:55AM -0500, Fabio Fracassi wrote:
<br>&gt; On 9/25/13 9:06 AM, Klaim - Jo=EF=BF=BDl Lamotte wrote:
<br>&gt; &gt;
<br>&gt; &gt;On Wed, Sep 25, 2013 at 3:43 PM, Fabio Fracassi &lt;<a href=3D=
"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"fEVk4EeaUS0J">f.fr=
a...@gmx.net</a>=20
<br>&gt; &gt;&lt;mailto:<a href=3D"javascript:" target=3D"_blank" gdf-obfus=
cated-mailto=3D"fEVk4EeaUS0J">f.fra...@gmx.net</a>&gt;&gt; wrote:
<br>&gt; &gt;
<br>&gt; &gt; &nbsp; &nbsp;I do not think so, although it goes into this di=
rection. As far as
<br>&gt; &gt; &nbsp; &nbsp;I can see this proposal does employ type erasure=
 to do &nbsp;coping,
<br>&gt; &gt; &nbsp; &nbsp;but is not a general tool to do type erasure for=
 various
<br>&gt; &gt; &nbsp; &nbsp;interfaces. I have not looked into this paper in=
 detail though.
<br>&gt; &gt;
<br>&gt; &gt;
<br>&gt; &gt;Are you thinking about something like Boost.TypeErasure=20
<br>&gt; &gt;<a href=3D"http://www.boost.org/doc/libs/1_54_0/doc/html/boost=
_typeerasure.html" target=3D"_blank">http://www.boost.org/doc/<wbr>libs/1_5=
4_0/doc/html/boost_<wbr>typeerasure.html</a> ?
<br>&gt; &gt;
<br>&gt; Yes, but without all the boilerplate. Basically what I would be li=
ke to=20
<br>&gt; be able to do is this:
<br>&gt;=20
<br>&gt; [example]
<br>&gt;=20
<br>
<br>I think this sounds a lot like the old signature extension of g++ 2.95.
<br>
<br>There is a paper describing the extension:
<br><a href=3D"http://docs.lib.purdue.edu/cgi/viewcontent.cgi?article=3D222=
4&amp;context=3Dcstech" target=3D"_blank">http://docs.lib.purdue.edu/<wbr>c=
gi/viewcontent.cgi?article=3D<wbr>2224&amp;context=3Dcstech</a>
<br>
<br>/MF
<br></blockquote></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1083_13538722.1380144440967--

.

Without going into detail on your alternative, did you read up on the
motivating examples for type erasure?
One of the best introductions is the one by Sean Parent (full talk, from
C++Now: http://www.youtube.com/watch?v=_BpMYeUFXv8&feature=youtu.be ,
slides
https://github.com/boostcon/cppnow_presentations_2012/blob/master/fri/value_semantics/value_semantics.pdf)
or not quite as high quality, and shameless plug my own talk about it:
http://prezi.com/kg6d82f-_yky/type-erasure/
Please note that one important feature of type erasure is that it uses
value semantics.


AFAICT You are basically right what the implementation involves, the
technique is well understood (for fixed interfaces) and used for example
in boost any (look at this first, it's just ~200 LoC and quite easy to
understand) or std::shared_ptr's deleter.





On 9/25/13 4:27 PM, Bengt Gustafsson wrote:
> Looking at Fabios example this is very similar to templates. But I
> understand that you want this to work in runtime i.e. with a reference
> to any of A or B coming in to the function, unknown at compile time.
> So the boilerplate code required would include a class with virtual
> methods for each method of the I class and subclasses forwarding to
> each of A, B and so on, along with magically creating a class
> type_erased<I> with the same methods as I but virtual, which is the
> base class of all the A and B boilerplate classes. The subclasses
> would need to have a reference to the actual A or B object to use as
> this pointer for the forwarding calls.
>
> Now, the tricky question is how do you call the function f with
> something that can be an A or a B (selectable at runtime) when the
> classes have no common ancestor.
You synthesize one, look at boost::any. Problem is that we have no way
to do it for arbitrary interfaces.

> I just can't understand how this can happen, and there is no hint of
> it in Fabios example which looks like a typical template function
> example except that it requires an extra interface class (which in
> principle acts as a concept).
>
Right, type erasure is sometimes also called runtime concepts.

> Even if there is a way to call f I think that the extreme complexity
> of entering this into the standard would be a big roadblock
It is certainly not an easy feature to standardize, which is one of the
reasons why nobody has done it yet.


> and I think it goes against the spirit of the language as it hide
> performance degrading functionality under an inconspicuous syntax.
> Here you think you do a simple call and instead you create a temporary
> object and perform virtual calls on it through a reference. If this
> got usage instead of templates due to its simpler syntax program
> performance would go down significantly.
It actually makes it easier to not pay for what you do not need, since
you can defer making interfaces virtual until you really need it. Type
erasure also plays very nicely in conjunction with templates.


--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_7736_14217558.1380188077689
Content-Type: text/plain; charset=ISO-8859-1

After checking out your references I still need a more fleshed out example
which actually uses the proposed syntax. One way would be to show the
source code for the slide's example with your new syntax instead of
explicit implementationt templates...

It does seem that my "using *" but with some finesse to it would be the key
stone feature needed. Maybe some other changes could be added but that
would be the most typing-saving part of it. This seems akin to the mixin
proposal here a few weeks ago, although not exactly the same. In general I
think we should strive for simple features which are useful in many places
rather than complex features which sort of build library into the language,
such as automatically generating template class hierarchies which are
invisible to the programmer... Another way to put it is that history shows
us that when you add a feature to C++ it will very often be used for
something else. Introducing a very specific feature like you suggestion
isn't going in that direction.

Den torsdagen den 26:e september 2013 kl. 00:42:53 UTC+2 skrev Fabio
Fracassi:
>
> Without going into detail on your alternative, did you read up on the
> motivating examples for type erasure?
> One of the best introductions is the one by Sean Parent (full talk, from
> C++Now: http://www.youtube.com/watch?v=_BpMYeUFXv8&feature=youtu.be ,
> slides
>
> https://github.com/boostcon/cppnow_presentations_2012/blob/master/fri/value_semantics/value_semantics.pdf)
>
> or not quite as high quality, and shameless plug my own talk about it:
> http://prezi.com/kg6d82f-_yky/type-erasure/
> Please note that one important feature of type erasure is that it uses
> value semantics.
>
>
> AFAICT You are basically right what the implementation involves, the
> technique is well understood (for fixed interfaces) and used for example
> in boost any (look at this first, it's just ~200 LoC and quite easy to
> understand) or std::shared_ptr's deleter.
>
>
>
>
>
> On 9/25/13 4:27 PM, Bengt Gustafsson wrote:
> > Looking at Fabios example this is very similar to templates. But I
> > understand that you want this to work in runtime i.e. with a reference
> > to any of A or B coming in to the function, unknown at compile time.
> > So the boilerplate code required would include a class with virtual
> > methods for each method of the I class and subclasses forwarding to
> > each of A, B and so on, along with magically creating a class
> > type_erased<I> with the same methods as I but virtual, which is the
> > base class of all the A and B boilerplate classes. The subclasses
> > would need to have a reference to the actual A or B object to use as
> > this pointer for the forwarding calls.
> >
> > Now, the tricky question is how do you call the function f with
> > something that can be an A or a B (selectable at runtime) when the
> > classes have no common ancestor.
> You synthesize one, look at boost::any. Problem is that we have no way
> to do it for arbitrary interfaces.
>
> > I just can't understand how this can happen, and there is no hint of
> > it in Fabios example which looks like a typical template function
> > example except that it requires an extra interface class (which in
> > principle acts as a concept).
> >
> Right, type erasure is sometimes also called runtime concepts.
>
> > Even if there is a way to call f I think that the extreme complexity
> > of entering this into the standard would be a big roadblock
> It is certainly not an easy feature to standardize, which is one of the
> reasons why nobody has done it yet.
>
>
> > and I think it goes against the spirit of the language as it hide
> > performance degrading functionality under an inconspicuous syntax.
> > Here you think you do a simple call and instead you create a temporary
> > object and perform virtual calls on it through a reference. If this
> > got usage instead of templates due to its simpler syntax program
> > performance would go down significantly.
> It actually makes it easier to not pay for what you do not need, since
> you can defer making interfaces virtual until you really need it. Type
> erasure also plays very nicely in conjunction with templates.
>
>
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_7736_14217558.1380188077689
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">After checking out your references I still need a more fle=
shed out example which actually uses the proposed syntax. One way would be =
to show the source code for the slide's example with your new syntax instea=
d of explicit implementationt templates...&nbsp;<div><br></div><div>It does=
 seem that my "using *" but with some finesse to it would be the key stone =
feature needed. Maybe some other changes could be added but that would be t=
he most typing-saving part of it. This seems akin to the mixin proposal her=
e a few weeks ago, although not exactly the same. In general I think we sho=
uld strive for simple features which are useful in many places rather than =
complex features which sort of build library into the language, such as aut=
omatically generating template class hierarchies which are invisible to the=
 programmer... Another way to put it is that history shows us that when you=
 add a feature to C++ it will very often be used for something else. Introd=
ucing a very specific feature like you suggestion isn't going in that direc=
tion.<br><br>Den torsdagen den 26:e september 2013 kl. 00:42:53 UTC+2 skrev=
 Fabio Fracassi:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Without going =
into detail on your alternative, did you read up on the=20
<br>motivating examples for type erasure?
<br>One of the best introductions is the one by Sean Parent (full talk, fro=
m=20
<br>C++Now: <a href=3D"http://www.youtube.com/watch?v=3D_BpMYeUFXv8&amp;fea=
ture=3Dyoutu.be" target=3D"_blank">http://www.youtube.com/watch?<wbr>v=3D_B=
pMYeUFXv8&amp;feature=3Dyoutu.be</a> ,=20
<br>slides=20
<br><a href=3D"https://github.com/boostcon/cppnow_presentations_2012/blob/m=
aster/fri/value_semantics/value_semantics.pdf" target=3D"_blank">https://gi=
thub.com/boostcon/<wbr>cppnow_presentations_2012/<wbr>blob/master/fri/value=
_<wbr>semantics/value_semantics.pdf</a>)=20
<br>or not quite as high quality, and shameless plug my own talk about it:=
=20
<br><a href=3D"http://prezi.com/kg6d82f-_yky/type-erasure/" target=3D"_blan=
k">http://prezi.com/kg6d82f-_yky/<wbr>type-erasure/</a>
<br>Please note that one important feature of type erasure is that it uses=
=20
<br>value semantics.
<br>
<br>
<br>AFAICT You are basically right what the implementation involves, the=20
<br>technique is well understood (for fixed interfaces) and used for exampl=
e=20
<br>in boost any (look at this first, it's just ~200 LoC and quite easy to=
=20
<br>understand) or std::shared_ptr's deleter.
<br>
<br>
<br>
<br>
<br>
<br>On 9/25/13 4:27 PM, Bengt Gustafsson wrote:
<br>&gt; Looking at Fabios example this is very similar to templates. But I=
=20
<br>&gt; understand that you want this to work in runtime i.e. with a refer=
ence=20
<br>&gt; to any of A or B coming in to the function, unknown at compile tim=
e.=20
<br>&gt; So the boilerplate code required would include a class with virtua=
l=20
<br>&gt; methods for each method of the I class and subclasses forwarding t=
o=20
<br>&gt; each of A, B and so on, along with magically creating a class=20
<br>&gt; type_erased&lt;I&gt; with the same methods as I but virtual, which=
 is the=20
<br>&gt; base class of all the A and B boilerplate classes. The subclasses=
=20
<br>&gt; would need to have a reference to the actual A or B object to use =
as=20
<br>&gt; this pointer for the forwarding calls.
<br>&gt;
<br>&gt; Now, the tricky question is how do you call the function f with=20
<br>&gt; something that can be an A or a B (selectable at runtime) when the=
=20
<br>&gt; classes have no common ancestor.
<br>You synthesize one, look at boost::any. Problem is that we have no way=
=20
<br>to do it for arbitrary interfaces.
<br>
<br>&gt; I just can't understand how this can happen, and there is no hint =
of=20
<br>&gt; it in Fabios example which looks like a typical template function=
=20
<br>&gt; example except that it requires an extra interface class (which in=
=20
<br>&gt; principle acts as a concept).
<br>&gt;
<br>Right, type erasure is sometimes also called runtime concepts.
<br>
<br>&gt; Even if there is a way to call f I think that the extreme complexi=
ty=20
<br>&gt; of entering this into the standard would be a big roadblock
<br>It is certainly not an easy feature to standardize, which is one of the=
=20
<br>reasons why nobody has done it yet.
<br>
<br>
<br>&gt; and I think it goes against the spirit of the language as it hide=
=20
<br>&gt; performance degrading functionality under an inconspicuous syntax.=
=20
<br>&gt; Here you think you do a simple call and instead you create a tempo=
rary=20
<br>&gt; object and perform virtual calls on it through a reference. If thi=
s=20
<br>&gt; got usage instead of templates due to its simpler syntax program=
=20
<br>&gt; performance would go down significantly.
<br>It actually makes it easier to not pay for what you do not need, since=
=20
<br>you can defer making interfaces virtual until you really need it. Type=
=20
<br>erasure also plays very nicely in conjunction with templates.
<br>
<br>
<br></blockquote></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_7736_14217558.1380188077689--

.

On 9/26/13 4:34 AM, Bengt Gustafsson wrote:
> After checking out your references I still need a more fleshed out
> example which actually uses the proposed syntax. One way would be to
> show the source code for the slide's example with your new syntax
> instead of explicit implementationt templates...
>
> It does seem that my "using *" but with some finesse to it would be
> the key stone feature needed. Maybe some other changes could be added
> but that would be the most typing-saving part of it. This seems akin
> to the mixin proposal here a few weeks ago, although not exactly the
> same. In general I think we should strive for simple features which
> are useful in many places rather than complex features which sort of
> build library into the language, such as automatically generating
> template class hierarchies which are invisible to the programmer...
> Another way to put it is that history shows us that when you add a
> feature to C++ it will very often be used for something else.
> Introducing a very specific feature like you suggestion isn't going in
> that direction.
>
I am not yet thinking of a concrete syntax for the feature.
 From a superficial glance it looks like your using* syntax could work,
even if I am not sure whether the virtuals in there are necessary.


--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_184_10491930.1380273087012
Content-Type: text/plain; charset=ISO-8859-1

I was trying to subdivide what you need to implement type erasure into a
core language part (using *) and a (possible) library part, the
type_erased<> template.

I don't like the name type erasure as it does not let you implicitly
understand what it is. Something with interface would at least point in the
right direction.

As for the virtual I was trying to find a way to make it definable what
methods * stands for. "all pure virtual methods that need to be implemented
to make the class concrete" was the best I could come up with. "All
methods" would work, but I suspect that a feature like using * would find
other uses where more control is desired.

One observation for your use case is that we need to get the methods
expanded both with and without virtual: In the type_erased<T> class itself
without virtual and in the base class for the implementations with virtual!
That kind of sucks... and may be a reason that you (right?) were suggesting
that the whole thing be a core language feature. Allowing "using virtual *"
would be a band-aid level solution but I would want something more elegant.

Den torsdagen den 26:e september 2013 kl. 15:20:50 UTC+2 skrev Fabio
Fracassi:
>
> On 9/26/13 4:34 AM, Bengt Gustafsson wrote:
> > After checking out your references I still need a more fleshed out
> > example which actually uses the proposed syntax. One way would be to
> > show the source code for the slide's example with your new syntax
> > instead of explicit implementationt templates...
> >
> > It does seem that my "using *" but with some finesse to it would be
> > the key stone feature needed. Maybe some other changes could be added
> > but that would be the most typing-saving part of it. This seems akin
> > to the mixin proposal here a few weeks ago, although not exactly the
> > same. In general I think we should strive for simple features which
> > are useful in many places rather than complex features which sort of
> > build library into the language, such as automatically generating
> > template class hierarchies which are invisible to the programmer...
> > Another way to put it is that history shows us that when you add a
> > feature to C++ it will very often be used for something else.
> > Introducing a very specific feature like you suggestion isn't going in
> > that direction.
> >
> I am not yet thinking of a concrete syntax for the feature.
>  From a superficial glance it looks like your using* syntax could work,
> even if I am not sure whether the virtuals in there are necessary.
>
>
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_184_10491930.1380273087012
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I was trying to subdivide what you need to implement type =
erasure into a core language part (using *) and a (possible) library part, =
the type_erased&lt;&gt; template.<div><br></div><div>I don't like the name =
type erasure as it does not let you implicitly understand what it is. Somet=
hing with interface would at least point in the right direction.</div><div>=
<br></div><div>As for the virtual I was trying to find a way to make it def=
inable what methods * stands for. "all pure virtual methods that need to be=
 implemented to make the class concrete" was the best I could come up with.=
 "All methods" would work, but I suspect that a feature like using * would =
find other uses where more control is desired.</div><div><br></div><div>One=
 observation for your use case is that we need to get the methods expanded =
both with and without virtual: In the type_erased&lt;T&gt; class itself wit=
hout virtual and in the base class for the implementations with virtual! Th=
at kind of sucks... and may be a reason that you (right?) were suggesting t=
hat the whole thing be a core language feature. Allowing "using virtual *" =
would be a band-aid level solution but I would want something more elegant.=
<br><br>Den torsdagen den 26:e september 2013 kl. 15:20:50 UTC+2 skrev Fabi=
o Fracassi:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 9/26/13 4:34 AM,=
 Bengt Gustafsson wrote:
<br>&gt; After checking out your references I still need a more fleshed out=
=20
<br>&gt; example which actually uses the proposed syntax. One way would be =
to=20
<br>&gt; show the source code for the slide's example with your new syntax=
=20
<br>&gt; instead of explicit implementationt templates...
<br>&gt;
<br>&gt; It does seem that my "using *" but with some finesse to it would b=
e=20
<br>&gt; the key stone feature needed. Maybe some other changes could be ad=
ded=20
<br>&gt; but that would be the most typing-saving part of it. This seems ak=
in=20
<br>&gt; to the mixin proposal here a few weeks ago, although not exactly t=
he=20
<br>&gt; same. In general I think we should strive for simple features whic=
h=20
<br>&gt; are useful in many places rather than complex features which sort =
of=20
<br>&gt; build library into the language, such as automatically generating=
=20
<br>&gt; template class hierarchies which are invisible to the programmer..=
..=20
<br>&gt; Another way to put it is that history shows us that when you add a=
=20
<br>&gt; feature to C++ it will very often be used for something else.=20
<br>&gt; Introducing a very specific feature like you suggestion isn't goin=
g in=20
<br>&gt; that direction.
<br>&gt;
<br>I am not yet thinking of a concrete syntax for the feature.
<br>&nbsp;From a superficial glance it looks like your using* syntax could =
work,=20
<br>even if I am not sure whether the virtuals in there are necessary.
<br>
<br>
<br></blockquote></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_184_10491930.1380273087012--

.

--001a11c2c8ea281c8604e75e0b42
Content-Type: text/plain; charset=ISO-8859-1

On 27 September 2013 04:11, Bengt Gustafsson
<bengt.gustafsson@beamways.com>wrote:

> I was trying to subdivide what you need to implement type erasure into a
> core language part (using *) and a (possible) library part, the
> type_erased<> template.
>

IMO it is extremely unlikely that any serious proposal for type erasure
will be considered until we get concepts (and possibly reflection, but I'm
not convinced we want or need the latter for it).


> I don't like the name type erasure as it does not let you implicitly
> understand what it is.
>

If you want to bike shed, that's fine, but (again, IMO) it doesn't seem
worthwhile at this stage.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a11c2c8ea281c8604e75e0b42
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 27 September 2013 04:11, Bengt Gustafsson <span dir=3D"=
ltr">&lt;<a href=3D"mailto:bengt.gustafsson@beamways.com" target=3D"_blank"=
>bengt.gustafsson@beamways.com</a>&gt;</span> wrote:<br><div class=3D"gmail=
_extra">

<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
I was trying to subdivide what you need to implement type erasure into a co=
re language part (using *) and a (possible) library part, the type_erased&l=
t;&gt; template.</div>

</blockquote><div><br></div><div>IMO it is extremely unlikely that any seri=
ous proposal for type erasure will be considered until we get concepts (and=
 possibly reflection, but I&#39;m not convinced we want or need the latter =
for it).</div>

<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>I don&#3=
9;t like the name type erasure as it does not let you implicitly understand=
 what it is.<br>

</div></div></blockquote><div><br></div><div>If you want to bike shed, that=
&#39;s fine, but (again, IMO) it doesn&#39;t seem worthwhile at this stage.=
</div></div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
&gt;=A0 (847) 691-1404
</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c2c8ea281c8604e75e0b42--

.

This is a multi-part message in MIME format.
--------------030204050001010600010506
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 9/27/13 9:09 AM, Nevin Liber wrote:
> On 27 September 2013 04:11, Bengt Gustafsson
> <bengt.gustafsson@beamways.com <mailto:bengt.gustafsson@beamways.com>>
> wrote:
>
>     I was trying to subdivide what you need to implement type erasure
>     into a core language part (using *) and a (possible) library part,
>     the type_erased<> template.
>
>
> IMO it is extremely unlikely that any serious proposal for type
> erasure will be considered until we get concepts (and possibly
> reflection, but I'm not convinced we want or need the latter for it).
>
>     I don't like the name type erasure as it does not let you
>     implicitly understand what it is.
>
>
> If you want to bike shed, that's fine, but (again, IMO) it doesn't
> seem worthwhile at this stage.
>
  +1

Even though I would very much like to see a proposal as soon as
possible, I do think that any proposal that does not take the whole
design space and especially the interactions with (the not yet
finallized) Concepts into account is ill fated.

Fabio



--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--------------030204050001010600010506
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">On 9/27/13 9:09 AM, Nevin Liber wrote:<b=
r>
    </div>
    <blockquote
cite=3D"mid:CAGg_6+Nmj17hA39L-2yv+f85R=3Dnfa8wAr9V_PkXsd2QROyEE-Q@mail.gmai=
l.com"
      type=3D"cite">
      <div dir=3D"ltr">On 27 September 2013 04:11, Bengt Gustafsson <span
          dir=3D"ltr">&lt;<a moz-do-not-send=3D"true"
            href=3D"mailto:bengt.gustafsson@beamways.com" target=3D"_blank"=
>bengt.gustafsson@beamways.com</a>&gt;</span>
        wrote:<br>
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">
            <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div dir=3D"ltr">I was trying to subdivide what you need to
                implement type erasure into a core language part (using
                *) and a (possible) library part, the
                type_erased&lt;&gt; template.</div>
            </blockquote>
            <div><br>
            </div>
            <div>IMO it is extremely unlikely that any serious proposal
              for type erasure will be considered until we get concepts
              (and possibly reflection, but I'm not convinced we want or
              need the latter for it).</div>
            <div>=A0</div>
            <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div dir=3D"ltr">
                <div>I don't like the name type erasure as it does not
                  let you implicitly understand what it is.<br>
                </div>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>If you want to bike shed, that's fine, but (again, IMO)
              it doesn't seem worthwhile at this stage.</div>
          </div>
          <br>
        </div>
      </div>
    </blockquote>
    =A0+1<br>
    <br>
    Even though I would very much like to see a proposal as soon as
    possible, I do think that any proposal that does not take the whole
    design space and especially the interactions with (the not yet
    finallized) Concepts into account is ill fated.<br>
    <br>
    Fabio<br>
    <br>
    <br>
    <br>
  </body>
</html>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--------------030204050001010600010506--

.