------=_Part_7696_263759176.1411674015069
Content-Type: text/plain; charset=UTF-8

Hello everyone,

I would like to ask for feedback concerning this idea I had about
non-intrusive "dynamic" polymorphism:

https://www.dropbox.com/s/tg737sf8sj1p1ht/Virtual%20concepts%20for%20polymorphic%20types.pdf?dl=1

This is just a rough sketch, please do not expect any full-blown proposal.
My goal is to find out whether it makes sense to invest more time on it, or
if the idea is basically bull***t.

A few highlights:

1. The idea is about introducing non-intrusive support for dynamic
polymorphism (similar to Haskell's typeclasses);
2. The idea is similar to the old C++0x "concept maps", but is *not*
related to templates;
3. Code using a "virtual concept" can be compiled separately and does not
need to see the definition of the instances of that concept.

Thank you,

Andy

--

---
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_7696_263759176.1411674015069
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello everyone,<br><br>I would like to ask for feedback co=
ncerning this idea I had about non-intrusive "dynamic" polymorphism:<br><br=
>https://www.dropbox.com/s/tg737sf8sj1p1ht/Virtual%20concepts%20for%20polym=
orphic%20types.pdf?dl=3D1<br><br>This is just a rough sketch, please do not=
 expect any full-blown proposal. My goal is to find out whether it makes se=
nse to invest more time on it, or if the idea is basically bull***t.<br><br=
>A few highlights:<br><br>1. The idea is about introducing non-intrusive su=
pport for dynamic polymorphism (similar to Haskell's typeclasses);<br>2. Th=
e idea is similar to the old C++0x "concept maps", but is *not* related to =
templates;<br>3. Code using a "virtual concept" can be compiled separately =
and does not need to see the definition of the instances of that concept.<b=
r><br>Thank you,<br><br>Andy</div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_7696_263759176.1411674015069--

.

--047d7b6772fcfeecaf0503f1ca89
Content-Type: text/plain; charset=UTF-8

Just a few thoughts:

The fact that it only works on polymorphic types makes sense based on your
implementation, but is extremely limiting. Type erasure, an alternative
that we already have access to, can operate on types that don't have a
vtable and doesn't need the additional metadata.

What limitations are there to the kind of functions that you can define in
a virtual concept? Can I create new constructors, or a destructor, or an
operator= for a virtual concept? Can I pass an instance of a virtual
concept by value, or by rvalue-reference? If so, it seems that each itable
will at least need to include references to the various special member
functions of the concrete type. Or is one only allowed to pass virtual
concepts by pointer or lvalue-reference?

How does the compiler determine the size of a class's vtable when you might
load a DLL that contains a virtual concept?

On Thu, Sep 25, 2014 at 2:40 PM, Andy Prowl <andy.prowl@gmail.com> wrote:

> Hello everyone,
>
> I would like to ask for feedback concerning this idea I had about
> non-intrusive "dynamic" polymorphism:
>
>
> https://www.dropbox.com/s/tg737sf8sj1p1ht/Virtual%20concepts%20for%20polymorphic%20types.pdf?dl=1
>
> This is just a rough sketch, please do not expect any full-blown proposal.
> My goal is to find out whether it makes sense to invest more time on it, or
> if the idea is basically bull***t.
>
> A few highlights:
>
> 1. The idea is about introducing non-intrusive support for dynamic
> polymorphism (similar to Haskell's typeclasses);
> 2. The idea is similar to the old C++0x "concept maps", but is *not*
> related to templates;
> 3. Code using a "virtual concept" can be compiled separately and does not
> need to see the definition of the instances of that concept.
>
> Thank you,
>
> Andy
>
> --
>
> ---
> 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/.
>

--

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

--047d7b6772fcfeecaf0503f1ca89
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Just a few thoughts:<div><br></div><div>The fact that it o=
nly works on polymorphic types makes sense based on your implementation, bu=
t is extremely limiting. Type erasure, an alternative that we already have =
access to, can operate on types that don&#39;t have a vtable and doesn&#39;=
t need the additional metadata.</div><div><br></div><div>What limitations a=
re there to the kind of functions that you can define in a virtual concept?=
 Can I create new constructors, or a destructor, or an operator=3D for a vi=
rtual concept? Can I pass an instance of a virtual concept by value, or by =
rvalue-reference? If so, it seems that each itable will at least need to in=
clude references to the various special member functions of the concrete ty=
pe. Or is one only allowed to pass virtual concepts by pointer or lvalue-re=
ference?</div><div><br></div><div>How does the compiler determine the size =
of a class&#39;s vtable when you might load a DLL that contains a virtual c=
oncept?</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote=
">On Thu, Sep 25, 2014 at 2:40 PM, Andy Prowl <span dir=3D"ltr">&lt;<a href=
=3D"mailto:andy.prowl@gmail.com" target=3D"_blank">andy.prowl@gmail.com</a>=
&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hello=
 everyone,<br><br>I would like to ask for feedback concerning this idea I h=
ad about non-intrusive &quot;dynamic&quot; polymorphism:<br><br><a href=3D"=
https://www.dropbox.com/s/tg737sf8sj1p1ht/Virtual%20concepts%20for%20polymo=
rphic%20types.pdf?dl=3D1" target=3D"_blank">https://www.dropbox.com/s/tg737=
sf8sj1p1ht/Virtual%20concepts%20for%20polymorphic%20types.pdf?dl=3D1</a><br=
><br>This is just a rough sketch, please do not expect any full-blown propo=
sal. My goal is to find out whether it makes sense to invest more time on i=
t, or if the idea is basically bull***t.<br><br>A few highlights:<br><br>1.=
 The idea is about introducing non-intrusive support for dynamic polymorphi=
sm (similar to Haskell&#39;s typeclasses);<br>2. The idea is similar to the=
 old C++0x &quot;concept maps&quot;, but is *not* related to templates;<br>=
3. Code using a &quot;virtual concept&quot; can be compiled separately and =
does not need to see the definition of the instances of that concept.<br><b=
r>Thank you,<br><br>Andy</div><span class=3D"HOEnZb"><font color=3D"#888888=
">

<p></p>

-- <br>
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />

--047d7b6772fcfeecaf0503f1ca89--

.

------=_Part_275_2016851443.1411731745969
Content-Type: text/plain; charset=UTF-8

Thank you for your valuable comments Brent.

As I mentioned, what I have so far is just a sketch, but I'll try to
address your points.

1. Concerning existing type erasure techniques, the only library solution I
know of is Boost.TypeErasure. You're correct, it does work with
non-polymorphic types, but it is not really easy to use, and it does not
satisfy the assertion "&cx == &x" from the document I attached: my idea is
to support reference semantics and allow accessing an object through a
virtual concept without creating a proxy object (it must be *that* object
which I pass around that gets referenced). Also, I believe (please correct
me if I am wrong) that Boost.TypeErasure only supports duck-typing: I
cannot specify, for instance, a concept (call it "C") such as "has member
function foo()" and then pass to a function expecting a "C&" an object
which only has a function "bar()", but for which an instantiation of C
exists in which "foo()" delegates to "bar()". Unless I'm mistaken, that is
basically how typeclasses work in Haskell. Finally, Boost.TypeErasure makes
heavy use of templates, which is likely going to have a significant impact
on compilation time;

2. The problem with supporting non-polymorphic classes, at least in the
solution I have sketched so far, is that some sort of "ctable pointer" is
necessary on every instance of an object to enable the caller to find the
correct instantiation of a concept for the object at hand without knowing
its type. For polymorphic types this is easy: we just reuse the vptr and
extend the vtable with extra information. For non-polymorphic types we are
in trouble, because if the compiler added a "ctable pointer" at the
beginning of the in-memory representation of the object, client code which
uses that object in a non-polymorphic way would be broken, because it would
expect a different layout (I am not a compiler guy, so again, correct me if
I'm wrong);

3. Defining destructors in a virtual concept is not meaningful as far as I
can see: all types have a destructor, so "having a destructor" is a
contract that all types satisfy - no need to make it explicit. An object
referenced by a virtual contract will be destroyed when it goes out of
scope (if it has automatic storage duration), or when it gets deleted (if
it has dynamic storage duration);

4. Good point about constructors and other special member functions (except
destructors). The main use case I can see for virtual concepts is indeed to
access objects through references/pointers: after all, the idea is to
support dynamic polymorphism the same way inheritance does, but
non-intrusively, and inheritance-based polymorphism somehow forces us to
use references and pointers. However, I am aware that polymorphic classes
can be used with value semantics, and I do have a feeling that the same
would be possible for virtual concepts, but honestly, I did not have this
use case in mind when I started developing this idea. Definitely worth a
deeper thought.

5. If a ctable is present as an extension of a vtable - as in the document
I linked -, then its first field (the metadata) may contain information on
its size.

Does this answer your questions, at least partly? If not, please let me
know and I'll try to formulate better answers. Any feedback is welcome.

Kind regards,

Andy

--

---
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_275_2016851443.1411731745969
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thank you for your valuable comments Brent.<br><br>As I me=
ntioned, what I have so far is just a sketch, but I'll try to address your =
points.&nbsp;<br><br>1. Concerning existing type erasure techniques, the on=
ly library solution I know of is Boost.TypeErasure. You're correct, it does=
 work with non-polymorphic types, but it is not really easy to use, and it =
does not satisfy the assertion "&amp;cx =3D=3D &amp;x" from the document I =
attached: my idea is to support reference semantics and allow accessing an =
object through a virtual concept without creating a proxy object (it must b=
e *that* object which I pass around that gets referenced). Also, I believe =
(please correct me if I am wrong) that Boost.TypeErasure only supports duck=
-typing: I cannot specify, for instance, a concept (call it "C") such as "h=
as member function foo()" and then pass to a function expecting a "C&amp;" =
an object which only has a function "bar()", but for which an instantiation=
 of C exists in which "foo()" delegates to "bar()". Unless I'm mistaken, th=
at is basically how typeclasses work in Haskell. Finally, Boost.TypeErasure=
 makes heavy use of templates, which is likely going to have a significant =
impact on compilation time;<br><br>2. The problem with supporting non-polym=
orphic classes, at least in the solution I have sketched so far, is that so=
me sort of "ctable pointer" is necessary on every instance of an object to =
enable the caller to find the correct instantiation of a concept for the ob=
ject at hand without knowing its type. For polymorphic types this is easy: =
we just reuse the vptr and extend the vtable with extra information. For no=
n-polymorphic types we are in trouble, because if the compiler added a "cta=
ble pointer" at the beginning of the in-memory representation of the object=
, client code which uses that object in a non-polymorphic way would be brok=
en, because it would expect a different layout (I am not a compiler guy, so=
 again, correct me if I'm wrong);<br><br>3. Defining destructors in a virtu=
al concept is not meaningful as far as I can see: all types have a destruct=
or, so "having a destructor" is a contract that all types satisfy - no need=
 to make it explicit. An object referenced by a virtual contract will be de=
stroyed when it goes out of scope (if it has automatic storage duration), o=
r when it gets deleted (if it has dynamic storage duration);<br><br><span s=
tyle=3D"font-size: 13.3333330154419px;">4. Good point about constructors an=
d other special member functions (except destructors)</span>. The main use =
case I can see for virtual concepts is indeed to access objects through ref=
erences/pointers: after all, the idea is to support dynamic polymorphism th=
e same way inheritance does, but non-intrusively, and inheritance-based pol=
ymorphism somehow forces us to use references and pointers. However, I am a=
ware that polymorphic classes can be used with value semantics, and I do ha=
ve a feeling that the same would be possible for virtual concepts, but hone=
stly, I did not have this use case in mind when I started developing this i=
dea. Definitely worth a deeper thought.<br><br>5. If a ctable is present as=
 an extension of a vtable - as in the document I linked -, then its first f=
ield (the metadata) may contain information on its size.<br><br>Does this a=
nswer your questions, at least partly? If not, please let me know and I'll =
try to formulate better answers. Any feedback is welcome.<br><br>Kind regar=
ds,<br><br>Andy</div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_275_2016851443.1411731745969--

.

--e89a8ff24d4bced7f40503fae70b
Content-Type: text/plain; charset=UTF-8

Regarding 5, I may not have explained myself clearly.

Suppose I have a library called coollib which I distribute as a DLL.
Coollib includes a polymorphic class X, whose ctable size needs to be known
when I distribute the DLL. However, if a client program Funprog tries to
make X implement a virtual concept (I understand this to be your primary
motivation?) it won't work with your proposed implementation. Funprog needs
to alter X's ctable in order to make X implement a virtual concept, and yet
we can't do that without breaking coollib's ABI.


On Fri, Sep 26, 2014 at 6:42 AM, Andy Prowl <andy.prowl@gmail.com> wrote:

> Thank you for your valuable comments Brent.
>
> As I mentioned, what I have so far is just a sketch, but I'll try to
> address your points.
>
> 1. Concerning existing type erasure techniques, the only library solution
> I know of is Boost.TypeErasure. You're correct, it does work with
> non-polymorphic types, but it is not really easy to use, and it does not
> satisfy the assertion "&cx == &x" from the document I attached: my idea is
> to support reference semantics and allow accessing an object through a
> virtual concept without creating a proxy object (it must be *that* object
> which I pass around that gets referenced). Also, I believe (please correct
> me if I am wrong) that Boost.TypeErasure only supports duck-typing: I
> cannot specify, for instance, a concept (call it "C") such as "has member
> function foo()" and then pass to a function expecting a "C&" an object
> which only has a function "bar()", but for which an instantiation of C
> exists in which "foo()" delegates to "bar()". Unless I'm mistaken, that is
> basically how typeclasses work in Haskell. Finally, Boost.TypeErasure makes
> heavy use of templates, which is likely going to have a significant impact
> on compilation time;
>
> 2. The problem with supporting non-polymorphic classes, at least in the
> solution I have sketched so far, is that some sort of "ctable pointer" is
> necessary on every instance of an object to enable the caller to find the
> correct instantiation of a concept for the object at hand without knowing
> its type. For polymorphic types this is easy: we just reuse the vptr and
> extend the vtable with extra information. For non-polymorphic types we are
> in trouble, because if the compiler added a "ctable pointer" at the
> beginning of the in-memory representation of the object, client code which
> uses that object in a non-polymorphic way would be broken, because it would
> expect a different layout (I am not a compiler guy, so again, correct me if
> I'm wrong);
>
> 3. Defining destructors in a virtual concept is not meaningful as far as I
> can see: all types have a destructor, so "having a destructor" is a
> contract that all types satisfy - no need to make it explicit. An object
> referenced by a virtual contract will be destroyed when it goes out of
> scope (if it has automatic storage duration), or when it gets deleted (if
> it has dynamic storage duration);
>
> 4. Good point about constructors and other special member functions
> (except destructors). The main use case I can see for virtual concepts is
> indeed to access objects through references/pointers: after all, the idea
> is to support dynamic polymorphism the same way inheritance does, but
> non-intrusively, and inheritance-based polymorphism somehow forces us to
> use references and pointers. However, I am aware that polymorphic classes
> can be used with value semantics, and I do have a feeling that the same
> would be possible for virtual concepts, but honestly, I did not have this
> use case in mind when I started developing this idea. Definitely worth a
> deeper thought.
>
> 5. If a ctable is present as an extension of a vtable - as in the document
> I linked -, then its first field (the metadata) may contain information on
> its size.
>
> Does this answer your questions, at least partly? If not, please let me
> know and I'll try to formulate better answers. Any feedback is welcome.
>
> Kind regards,
>
> Andy
>
> --
>
> ---
> 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/.
>

--

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

--e89a8ff24d4bced7f40503fae70b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Regarding 5, I may not have explained myself clearly.<div>=
<br></div><div>Suppose I have a library called coollib which I distribute a=
s a DLL. Coollib includes a polymorphic class X, whose ctable size needs to=
 be known when I distribute the DLL. However, if a client program Funprog t=
ries to make X implement a virtual concept (I understand this to be your pr=
imary motivation?) it won&#39;t work with your proposed implementation. Fun=
prog needs to alter X&#39;s ctable in order to make X implement a virtual c=
oncept, and yet we can&#39;t do that without breaking coollib&#39;s ABI.</d=
iv><div><br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_=
quote">On Fri, Sep 26, 2014 at 6:42 AM, Andy Prowl <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:andy.prowl@gmail.com" target=3D"_blank">andy.prowl@gmail.co=
m</a>&gt;</span> wrote:<br><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">=
Thank you for your valuable comments Brent.<br><br>As I mentioned, what I h=
ave so far is just a sketch, but I&#39;ll try to address your points.=C2=A0=
<br><br>1. Concerning existing type erasure techniques, the only library so=
lution I know of is Boost.TypeErasure. You&#39;re correct, it does work wit=
h non-polymorphic types, but it is not really easy to use, and it does not =
satisfy the assertion &quot;&amp;cx =3D=3D &amp;x&quot; from the document I=
 attached: my idea is to support reference semantics and allow accessing an=
 object through a virtual concept without creating a proxy object (it must =
be *that* object which I pass around that gets referenced). Also, I believe=
 (please correct me if I am wrong) that Boost.TypeErasure only supports duc=
k-typing: I cannot specify, for instance, a concept (call it &quot;C&quot;)=
 such as &quot;has member function foo()&quot; and then pass to a function =
expecting a &quot;C&amp;&quot; an object which only has a function &quot;ba=
r()&quot;, but for which an instantiation of C exists in which &quot;foo()&=
quot; delegates to &quot;bar()&quot;. Unless I&#39;m mistaken, that is basi=
cally how typeclasses work in Haskell. Finally, Boost.TypeErasure makes hea=
vy use of templates, which is likely going to have a significant impact on =
compilation time;<br><br>2. The problem with supporting non-polymorphic cla=
sses, at least in the solution I have sketched so far, is that some sort of=
 &quot;ctable pointer&quot; is necessary on every instance of an object to =
enable the caller to find the correct instantiation of a concept for the ob=
ject at hand without knowing its type. For polymorphic types this is easy: =
we just reuse the vptr and extend the vtable with extra information. For no=
n-polymorphic types we are in trouble, because if the compiler added a &quo=
t;ctable pointer&quot; at the beginning of the in-memory representation of =
the object, client code which uses that object in a non-polymorphic way wou=
ld be broken, because it would expect a different layout (I am not a compil=
er guy, so again, correct me if I&#39;m wrong);<br><br>3. Defining destruct=
ors in a virtual concept is not meaningful as far as I can see: all types h=
ave a destructor, so &quot;having a destructor&quot; is a contract that all=
 types satisfy - no need to make it explicit. An object referenced by a vir=
tual contract will be destroyed when it goes out of scope (if it has automa=
tic storage duration), or when it gets deleted (if it has dynamic storage d=
uration);<br><br><span style=3D"font-size:13.3333330154419px">4. Good point=
 about constructors and other special member functions (except destructors)=
</span>. The main use case I can see for virtual concepts is indeed to acce=
ss objects through references/pointers: after all, the idea is to support d=
ynamic polymorphism the same way inheritance does, but non-intrusively, and=
 inheritance-based polymorphism somehow forces us to use references and poi=
nters. However, I am aware that polymorphic classes can be used with value =
semantics, and I do have a feeling that the same would be possible for virt=
ual concepts, but honestly, I did not have this use case in mind when I sta=
rted developing this idea. Definitely worth a deeper thought.<br><br>5. If =
a ctable is present as an extension of a vtable - as in the document I link=
ed -, then its first field (the metadata) may contain information on its si=
ze.<br><br>Does this answer your questions, at least partly? If not, please=
 let me know and I&#39;ll try to formulate better answers. Any feedback is =
welcome.<br><br>Kind regards,<br><br>Andy</div><div class=3D"HOEnZb"><div c=
lass=3D"h5">

<p></p>

-- <br>
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />

--e89a8ff24d4bced7f40503fae70b--

.

------=_Part_943_177413500.1411758105835
Content-Type: text/plain; charset=UTF-8

OK, I think I see what you mean. You're right, that would be a problem.

I therefore propose an alternative implementation technique which - unless
I'm overlooking something again - should work for non-polymorphic types
too, including fundamental types, and does not require a ctable.

The idea is that any time a variable of virtual concept type (C*, C&, or
plain C plus cv-qualification, where C is a virtual concept) is
initialized, the storage that holds it is extended by the size of one
pointer. The additional pointer points to the itable for the static type of
the initializing expression. In other words, supposing there is an
instantiation of type X for the virtual concept C, and given something like:

X x;
C* c = &x;
c.foo();

The compiler would initialize c with the address of x, and next to the
location of c it would store an additional pointer to the itable of X for
C. Same for references (the standard doesn't require references to occupy
memory, but AFAIK compilers implement references as pointers). The case
where c is not of reference/pointer type is handled similarly:

X x;
C c = x; // ASSUME X IS COPY-CONSTRUCTIBLE AND SATISFIES VIRTUAL CONCEPT C
c.foo();

The compiler here would copy-construct an object of type X from x and make
it available through the virtual concept C by storing the itable pointer
for C(X) next to the storage occupied by c.

A slightly more detailed, yet only sketched description is given here (see
the "Implementation technique" section): http://bit.ly/ZgruFY.

I do realize there is much more to cover, but I'd like to know if this
looks more promising or if the idea is fundamentally flawed.

Thank you,

Andy

--

---
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_943_177413500.1411758105835
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">OK, I think I see what you mean. You're right, that would =
be a problem.&nbsp;<br><br>I therefore propose an alternative implementatio=
n technique which - unless I'm overlooking something again - should work fo=
r non-polymorphic types too, including fundamental types, and does not requ=
ire a ctable.<br><br>The idea is that any time a variable of virtual concep=
t type (C*, C&amp;, or plain C plus cv-qualification,&nbsp;<span style=3D"f=
ont-size: 13.3333330154419px;">where C is a virtual concept</span>) is init=
ialized, the storage that holds it is extended by the size of one pointer. =
The additional pointer points to the itable for the static type of the init=
ializing expression. In other words, supposing there is an instantiation of=
 type X for the virtual concept C, and given something like:<br><br><div cl=
ass=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); word-wra=
p: break-word; background-color: rgb(250, 250, 250);"><code class=3D"pretty=
print"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"=
styled-by-prettify">X x</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br>C</span><font color=3D"#666600"><span style=3D"color: #660;" class=
=3D"styled-by-prettify">*</span></font><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> c </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">x</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br>c</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">foo</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">();</span><font color=3D"#666600"></font></=
div></code></div><br>The compiler would initialize c with the address of x,=
 and next to the location of c it would store an additional pointer to the =
itable of X for C. Same for references (the standard doesn't require refere=
nces to occupy memory, but AFAIK compilers implement references as pointers=
). The case where c is not of reference/pointer type is handled similarly:<=
br><br><div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, =
187); word-wrap: break-word; background-color: rgb(250, 250, 250);"><code c=
lass=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">X x</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br>C c </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> x</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #800;" class=3D"styled-by-prettify">// ASSUME X IS CO=
PY-CONSTRUCTIBLE AND SATISFIES VIRTUAL CONCEPT C</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br>c</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">foo</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">();</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br></span></div></code></div><br>The compiler here would copy-co=
nstruct an object of type X from x and make it available through the virtua=
l concept C by storing the itable pointer for C(X) next to the storage occu=
pied by c.<br><br>A slightly more detailed, yet only sketched description i=
s given here (see the "Implementation technique" section):&nbsp;<a href=3D"=
http://bit.ly/ZgruFY">http://bit.ly/ZgruFY</a>.<br><br>I do realize there i=
s much more to cover, but I'd like to know if this looks more promising or =
if the idea is fundamentally flawed.<br><br>Thank you,<br><br>Andy</div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_943_177413500.1411758105835--

.

--e89a8ff24d4be45e9d050406c041
Content-Type: text/plain; charset=UTF-8

I think this new version is definitely an improvement. Two pointers will be
more feasible than one. I think there are some additional implementation
complications to consider.

In order to build an object of virtual concept, we very much need
information on the dynamic type of the object to be converted. Perhaps I
have a function shave(Animal* a) which wants to convert a to the virtual
concept Fuzzy. shave(Sheep*) might work if Sheep implements Fuzzy, and
shave(Snake*) might not work. So, in order to even determine if we can
convert the object to Fuzzy, we'll need to either add something to Animal's
vtable or use RTTI, etc to determine if the conversion is possible.
Repurposing dynamic_cast to work with virtual concepts makes sense for
supporting this case where the conversion cannot be determined statically.
Unless, of course, virtual concepts can only use the static type of an
object (Animal in this case) but I don't get the impression that is the
intent.

A perhaps more feasible implementation for performing the conversion would
involve each virtual concept having a table where each entry is { typeid,
itable* }. So the compiler uses RTTI to determine a unique id for the
dynamic type of the object, finds the corresponding entry in the virtual
concept's table, and dispatches the call into that corresponding itable
entry. This allows us to augment a type without modifying it in any way (as
long as we can do RTTI).

On Fri, Sep 26, 2014 at 2:01 PM, Andy Prowl <andy.prowl@gmail.com> wrote:

> OK, I think I see what you mean. You're right, that would be a problem.
>
> I therefore propose an alternative implementation technique which - unless
> I'm overlooking something again - should work for non-polymorphic types
> too, including fundamental types, and does not require a ctable.
>
> The idea is that any time a variable of virtual concept type (C*, C&, or
> plain C plus cv-qualification, where C is a virtual concept) is
> initialized, the storage that holds it is extended by the size of one
> pointer. The additional pointer points to the itable for the static type of
> the initializing expression. In other words, supposing there is an
> instantiation of type X for the virtual concept C, and given something like:
>
> X x;
> C* c = &x;
> c.foo();
>
> The compiler would initialize c with the address of x, and next to the
> location of c it would store an additional pointer to the itable of X for
> C. Same for references (the standard doesn't require references to occupy
> memory, but AFAIK compilers implement references as pointers). The case
> where c is not of reference/pointer type is handled similarly:
>
> X x;
> C c = x; // ASSUME X IS COPY-CONSTRUCTIBLE AND SATISFIES VIRTUAL CONCEPT C
> c.foo();
>
> The compiler here would copy-construct an object of type X from x and make
> it available through the virtual concept C by storing the itable pointer
> for C(X) next to the storage occupied by c.
>
> A slightly more detailed, yet only sketched description is given here (see
> the "Implementation technique" section): http://bit.ly/ZgruFY.
>
> I do realize there is much more to cover, but I'd like to know if this
> looks more promising or if the idea is fundamentally flawed.
>
> Thank you,
>
> Andy
>
> --
>
> ---
> 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/.
>

--

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

--e89a8ff24d4be45e9d050406c041
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I think this new version is definitely an improvement. Two=
 pointers will be more feasible than one. I think there are some additional=
 implementation complications to consider.<div><br></div><div>In order to b=
uild an object of virtual concept, we very much need information on the dyn=
amic type of the object to be converted. Perhaps I have a function <font fa=
ce=3D"courier new, monospace">shave(Animal* a) </font>which wants to conver=
t a to the virtual concept <font face=3D"courier new, monospace">Fuzzy</fon=
t>. <font face=3D"courier new, monospace">shave(Sheep*)</font> might work i=
f <font face=3D"courier new, monospace">Sheep </font>implements <font face=
=3D"courier new, monospace">Fuzzy</font>, and <font face=3D"courier new, mo=
nospace">shave(Snake*)</font> might not work. So, in order to even determin=
e if we can convert the object to <font face=3D"courier new, monospace">Fuz=
zy</font>, we&#39;ll need to either add something to <font face=3D"courier =
new, monospace">Animal</font>&#39;s vtable or use RTTI, etc to determine if=
 the conversion is possible. Repurposing <font face=3D"courier new, monospa=
ce">dynamic_cast</font> to work with virtual concepts makes sense for suppo=
rting this case where the conversion cannot be determined statically. Unles=
s, of course, virtual concepts can only use the static type of an object (A=
nimal in this case) but I don&#39;t get the impression that is the intent.<=
/div><div><br></div><div>A perhaps more feasible implementation for perform=
ing the conversion would involve each virtual concept having a table where =
each entry is<font face=3D"courier new, monospace"> { typeid, itable* }</fo=
nt>. So the compiler uses RTTI to determine a unique id for the dynamic typ=
e of the object, finds the corresponding entry in the virtual concept&#39;s=
 table, and dispatches the call into that corresponding itable entry. This =
allows us to augment a type without modifying it in any way (as long as we =
can do RTTI).</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail=
_quote">On Fri, Sep 26, 2014 at 2:01 PM, Andy Prowl <span dir=3D"ltr">&lt;<=
a href=3D"mailto:andy.prowl@gmail.com" target=3D"_blank">andy.prowl@gmail.c=
om</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
>OK, I think I see what you mean. You&#39;re right, that would be a problem=
..=C2=A0<br><br>I therefore propose an alternative implementation technique =
which - unless I&#39;m overlooking something again - should work for non-po=
lymorphic types too, including fundamental types, and does not require a ct=
able.<br><br>The idea is that any time a variable of virtual concept type (=
C*, C&amp;, or plain C plus cv-qualification,=C2=A0<span style=3D"font-size=
:13.3333330154419px">where C is a virtual concept</span>) is initialized, t=
he storage that holds it is extended by the size of one pointer. The additi=
onal pointer points to the itable for the static type of the initializing e=
xpression. In other words, supposing there is an instantiation of type X fo=
r the virtual concept C, and given something like:<br><br><div style=3D"bor=
der:1px solid rgb(187,187,187);word-wrap:break-word;background-color:rgb(25=
0,250,250)"><code><div><span style=3D"color:#000">X x</span><span style=3D"=
color:#660">;</span><span style=3D"color:#000"><br>C</span><font color=3D"#=
666600"><span style=3D"color:#660">*</span></font><span style=3D"color:#000=
"> c </span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"=
> </span><span style=3D"color:#660">&amp;</span><span style=3D"color:#000">=
x</span><span style=3D"color:#660">;</span><span style=3D"color:#000"><br>c=
</span><span style=3D"color:#660">.</span><span style=3D"color:#000">foo</s=
pan><span style=3D"color:#660">();</span><font color=3D"#666600"></font></d=
iv></code></div><br>The compiler would initialize c with the address of x, =
and next to the location of c it would store an additional pointer to the i=
table of X for C. Same for references (the standard doesn&#39;t require ref=
erences to occupy memory, but AFAIK compilers implement references as point=
ers). The case where c is not of reference/pointer type is handled similarl=
y:<br><br><div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-w=
ord;background-color:rgb(250,250,250)"><code><div><span style=3D"color:#000=
">X x</span><span style=3D"color:#660">;</span><span style=3D"color:#000"><=
br>C c </span><span style=3D"color:#660">=3D</span><span style=3D"color:#00=
0"> x</span><span style=3D"color:#660">;</span><span style=3D"color:#000"> =
</span><span style=3D"color:#800">// ASSUME X IS COPY-CONSTRUCTIBLE AND SAT=
ISFIES VIRTUAL CONCEPT C</span><span style=3D"color:#000"><br>c</span><span=
 style=3D"color:#660">.</span><span style=3D"color:#000">foo</span><span st=
yle=3D"color:#660">();</span><span style=3D"color:#000"><br></span></div></=
code></div><br>The compiler here would copy-construct an object of type X f=
rom x and make it available through the virtual concept C by storing the it=
able pointer for C(X) next to the storage occupied by c.<br><br>A slightly =
more detailed, yet only sketched description is given here (see the &quot;I=
mplementation technique&quot; section):=C2=A0<a href=3D"http://bit.ly/ZgruF=
Y" target=3D"_blank">http://bit.ly/ZgruFY</a>.<br><br>I do realize there is=
 much more to cover, but I&#39;d like to know if this looks more promising =
or if the idea is fundamentally flawed.<br><br>Thank you,<br><br>Andy</div>=
<div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />

--e89a8ff24d4be45e9d050406c041--

.

------=_Part_214_68565114.1411824574531
Content-Type: text/plain; charset=UTF-8

Thank you Brent.

Actually I believe it is the *static* type of the initializing expression
that should be used rather than the dynamic type, otherwise we would break
type-safety.

An Animal* can be provided when a Fuzzy* is expected if and only if there
is a concept instantiation of Animal for Fuzzy (or of a class Animal
derives from for Fuzzy). If not, passing a Snake* (for which we assume no
instantiation exists) may result in a refused bequest at run-time.

The idea is to allow determining at compile-time that a function call
through a virtual concept is going to be meaningfully implemented, while
leaving the concrete binding at run-time - pretty much like classical
dynamic polymorphism through inheritance: You don't know what will be
called, but you know that something suitable will be called.

*** (PROBLEM) ***

Incidentally, I spotted a problem with the implementation technique I last
proposed. In order to compile a function that uses a virtual concept with
value semantics (e.g. a function that accepts an object of virtual concept
type by value), the compiler needs to know the size of that object. So for
instance, in order to compile the following:

void foo(C obj)
{
   std::cout << obj.bar();
}

The compiler needs to know the size of "obj". According to my current
implementation technique, the size of "obj" is "one pointer + the size of
the argument to foo()", but the latter is known only at call site -
possibly in a different translation unit; so that won't work.

*** (SOLUTION) ***

I think it makes sense to always have objects of virtual concept type
represented by a pair of pointers: the first pointer ("optr") is the
pointer to the object which is being accessed polymorphically (and which is
also the result of "&obj"), whereas the second pointer ("iptr") is the
pointer to the itable. This gives "obj" a fixed size - twice a pointer size.

Then, when compiling a function call like the following:

int main()
{
    int x = 42;
    foo(x);
}

The compiler will copy-construct "x" into an unnamed object on the stack;
the argument "obj" will have the "optr" pointing to that unnamed object,
and the "iptr" pointing to the itable of "int" for C. The unnamed object
will be destroyed when the call to foo() returns. Likewise, when
copy-constructing an object:

int main()
{
    int x = 42;
    C obj = x;
    std::cout << obj.bar();
}

The "optr" of "obj" will point to an unnamed object copy-constructed from
"x". That object will be destroyed when "x" gets destroyed.

Open issue: how to make this work for the initialization of non-static data
members of non-reference, non-pointer concept type (we can't just create
the unnamed object on the stack, because the embedding object might have
dynamic storage duration)? How could the compiler do the magic? Or shall we
forbid this (I'd rather allow it, for orthogonality)?

When the concept object being initialized has reference or pointer type, on
the other hand, no copy-construction is involved and no "unnamed" object
needs to be created.

I updated the draft accordingly: http://bit.ly/ZgruFY.

Kind regards,

Andy

--

---
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_214_68565114.1411824574531
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thank you Brent.<br><br>Actually I believe it is the *stat=
ic* type of the initializing expression that should be used rather than the=
 dynamic type, otherwise we would break type-safety. <br><br>An Animal* can=
 be provided when a Fuzzy* is expected if and only if there is a concept in=
stantiation of Animal for Fuzzy (or of a class Animal derives from for Fuzz=
y). If not, passing a Snake* (for which we assume no instantiation exists) =
may result in a refused bequest at run-time. <br><br>The idea is to allow d=
etermining at compile-time that a function call through a virtual concept i=
s going to be meaningfully implemented, while leaving the concrete binding =
at run-time - pretty much like classical dynamic polymorphism through inher=
itance: You don't know what will be called, but you know that something sui=
table will be called.<br><br>*** (PROBLEM) ***<br><br>Incidentally, I spott=
ed a problem with the implementation technique I last proposed. In order to=
 compile a function that uses a virtual concept with value semantics (e.g. =
a function that accepts an object of virtual concept type by value), the co=
mpiler needs to know the size of that object. So for instance, in order to =
compile the following:<br><br><div class=3D"prettyprint" style=3D"border: 1=
px solid rgb(187, 187, 187); word-wrap: break-word; background-color: rgb(2=
50, 250, 250);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><=
span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> foo</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">C obj</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>&nbsp; &nbsp;std</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">cout </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">&lt;&lt;</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> obj</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">bar</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">();</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">}</span></div></code></div><br>=
The compiler needs to know the size of "obj". According to my current imple=
mentation technique,&nbsp;the size of "obj" is "one pointer + the size of t=
he argument to foo()", but the latter is known only at call site - possibly=
 in a different translation unit; so that won't work.<br><br>*** (SOLUTION)=
 ***<br><br>I think it makes sense to always have objects of virtual concep=
t type represented by a pair of pointers: the first pointer ("optr") is the=
 pointer to the object which is being accessed polymorphically (and which i=
s also the result of "&amp;obj"), whereas the second pointer ("iptr") is th=
e pointer to the itable. This gives "obj" a fixed size - twice a pointer si=
ze.<br><br>Then, when compiling a function call like the following:<br><br>=
<div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); w=
ord-wrap: break-word; background-color: rgb(250, 250, 250);"><code class=3D=
"prettyprint"><div class=3D"subprettyprint"><font color=3D"#660066"><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> main</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">()</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> x </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">42</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; foo</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">x</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">}</span></font></div></code></div><br>The =
compiler will copy-construct "x" into an unnamed object on the stack; the a=
rgument "obj" will have the "optr" pointing to that unnamed object, and the=
 "iptr" pointing to the itable of "int" for C. The unnamed object will be d=
estroyed when the call to foo() returns. Likewise, when copy-constructing a=
n object:<br><br><div><font face=3D"monospace"><div class=3D"prettyprint" s=
tyle=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; backgr=
ound-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"=
subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">i=
nt</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> main</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> x </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"sty=
led-by-prettify">42</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br>&nbsp; &nbsp; C obj </span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> x</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp;=
 &nbsp; std</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">cout </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;&lt;</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> obj</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">bar</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">();</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br></span></div></code></div><br></font><span style=3D"f=
ont-size: 13.3333330154419px;">The "optr" of "obj" will point to an unnamed=
 object copy-constructed from "x". That object will be destroyed when "x" g=
ets destroyed.<br><br>Open issue: how to make this work for the initializat=
ion of non-static data members of non-reference, non-pointer concept type (=
we can't just create the unnamed object on the stack, because the embedding=
 object might have dynamic storage duration)? How could the compiler do the=
 magic? Or shall we forbid this (I'd rather allow it, for orthogonality)?</=
span></div><div><br><span style=3D"font-size: 13.3333330154419px;">When the=
 concept object being initialized has reference or pointer type, on the oth=
er hand, no copy-construction is involved and no "unnamed" object needs to =
be created.</span><br style=3D"font-size: 13.3333330154419px;"><br>I update=
d the draft accordingly:&nbsp;<a href=3D"http://bit.ly/ZgruFY" target=3D"_b=
lank" style=3D"font-size: 13.3333330154419px; cursor: pointer;">http://bit.=
ly/ZgruFY</a><span style=3D"font-size: 13px;">.</span></div><div><br>Kind r=
egards,<br><br>Andy</div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_214_68565114.1411824574531--

.

This is a multi-part message in MIME format.
--------------090008060808080103030800
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 26/09/14 21:01, Andy Prowl a =C3=A9crit :
> OK, I think I see what you mean. You're right, that would be a problem.
>
> I therefore propose an alternative implementation technique which -=20
> unless I'm overlooking something again - should work for=20
> non-polymorphic types too, including fundamental types, and does not=20
> require a ctable.
>
> The idea is that any time a variable of virtual concept type (C*, C&,=20
> or plain C plus cv-qualification, where C is a virtual concept) is=20
> initialized, the storage that holds it is extended by the size of one=20
> pointer. The additional pointer points to the itable for the static=20
> type of the initializing expression. In other words, supposing there=20
> is an instantiation of type X for the virtual concept C, and given=20
> something like:
>
> |
> X x;
> C*c =3D&x;
> c.foo();
> |
>
> The compiler would initialize c with the address of x, and next to the=20
> location of c it would store an additional pointer to the itable of X=20
> for C. Same for references (the standard doesn't require references to=20
> occupy memory, but AFAIK compilers implement references as pointers).=20
> The case where c is not of reference/pointer type is handled similarly:
>
> |
> X x;
> C c =3Dx;// ASSUME X IS COPY-CONSTRUCTIBLE AND SATISFIES VIRTUAL CONCEPT =
C
> c.foo();
> |
>
> The compiler here would copy-construct an object of type X from x and=20
> make it available through the virtual concept C by storing the itable=20
> pointer for C(X) next to the storage occupied by c.
>
> A slightly more detailed, yet only sketched description is given here=20
> (see the "Implementation technique" section): http://bit.ly/ZgruFY.
>
> I do realize there is much more to cover, but I'd like to know if this=20
> looks more promising or if the idea is fundamentally flawed.
>
Hi,

I think the idea is in general useful, and surely need a lot of refinements=
..
However the name virtual concept is not really good and the=20
implementation can surely be improved, but I don't think the=20
implementation is the most important part for the time been. Anyway a=20
type erased implementation with an additional adaptor to do the mapping,=20
seems more understandable to me.
What I think is important is what we want to be able to do.

Your virtual concept could be related to abstract data types=20
(http://en.wikipedia.org/wiki/Abstract_data_type).
Type erasure usually has value semantics, but it is possible to give it=20
reference or pointer semantics also.

Do you expect x to be deleted after a call to delete c in the following=20
example?

|
|X*xptr =3Dnew X;
||C*c =3Dxptr;
|c->foo();
delete c
|

If this is the case, you need a way to state it explicitly on the=20
virtual concept definition.

BTW, why do you need that

  C& cx =3D x;
  assert(&cx =3D=3D &x);

?
Note that as C is not really a class, the assertion must not forcedly be=20
implied.

Could virtual concepts inherit from other virtual concepts?



Vicente

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

--------------090008060808080103030800
Content-Type: text/html; charset=UTF-8
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">Le 26/09/14 21:01, Andy Prowl a =C3=A9cr=
it=C2=A0:<br>
    </div>
    <blockquote
      cite=3D"mid:2d4ca82b-fe3e-471c-8c6a-e108e5596236@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">OK, I think I see what you mean. You're right, that
        would be a problem.=C2=A0<br>
        <br>
        I therefore propose an alternative implementation technique
        which - unless I'm overlooking something again - should work for
        non-polymorphic types too, including fundamental types, and does
        not require a ctable.<br>
        <br>
        The idea is that any time a variable of virtual concept type
        (C*, C&amp;, or plain C plus cv-qualification,=C2=A0<span
          style=3D"font-size: 13.3333330154419px;">where C is a virtual
          concept</span>) is initialized, the storage that holds it is
        extended by the size of one pointer. The additional pointer
        points to the itable for the static type of the initializing
        expression. In other words, supposing there is an instantiation
        of type X for the virtual concept C, and given something like:<br>
        <br>
        <div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187,
          187); word-wrap: break-word; background-color: rgb(250, 250,
          250);"><code class=3D"prettyprint">
            <div class=3D"subprettyprint"><span style=3D"color: #000;"
                class=3D"styled-by-prettify">X x</span><span style=3D"color=
:
                #660;" class=3D"styled-by-prettify">;</span><span
                style=3D"color: #000;" class=3D"styled-by-prettify"><br>
                C</span><font color=3D"#666600"><span style=3D"color: #660;=
"
                  class=3D"styled-by-prettify">*</span></font><span
                style=3D"color: #000;" class=3D"styled-by-prettify"> c </sp=
an><span
                style=3D"color: #660;" class=3D"styled-by-prettify">=3D</sp=
an><span
                style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span
                style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</=
span><span
                style=3D"color: #000;" class=3D"styled-by-prettify">x</span=
><span
                style=3D"color: #660;" class=3D"styled-by-prettify">;</span=
><span
                style=3D"color: #000;" class=3D"styled-by-prettify"><br>
                c</span><span style=3D"color: #660;"
                class=3D"styled-by-prettify">.</span><span style=3D"color:
                #000;" class=3D"styled-by-prettify">foo</span><span
                style=3D"color: #660;" class=3D"styled-by-prettify">();</sp=
an></div>
          </code></div>
        <br>
        The compiler would initialize c with the address of x, and next
        to the location of c it would store an additional pointer to the
        itable of X for C. Same for references (the standard doesn't
        require references to occupy memory, but AFAIK compilers
        implement references as pointers). The case where c is not of
        reference/pointer type is handled similarly:<br>
        <br>
        <div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187,
          187); word-wrap: break-word; background-color: rgb(250, 250,
          250);"><code class=3D"prettyprint">
            <div class=3D"subprettyprint"><span style=3D"color: #000;"
                class=3D"styled-by-prettify">X x</span><span style=3D"color=
:
                #660;" class=3D"styled-by-prettify">;</span><span
                style=3D"color: #000;" class=3D"styled-by-prettify"><br>
                C c </span><span style=3D"color: #660;"
                class=3D"styled-by-prettify">=3D</span><span style=3D"color=
:
                #000;" class=3D"styled-by-prettify"> x</span><span
                style=3D"color: #660;" class=3D"styled-by-prettify">;</span=
><span
                style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span
                style=3D"color: #800;" class=3D"styled-by-prettify">//
                ASSUME X IS COPY-CONSTRUCTIBLE AND SATISFIES VIRTUAL
                CONCEPT C</span><span style=3D"color: #000;"
                class=3D"styled-by-prettify"><br>
                c</span><span style=3D"color: #660;"
                class=3D"styled-by-prettify">.</span><span style=3D"color:
                #000;" class=3D"styled-by-prettify">foo</span><span
                style=3D"color: #660;" class=3D"styled-by-prettify">();</sp=
an><span
                style=3D"color: #000;" class=3D"styled-by-prettify"><br>
              </span></div>
          </code></div>
        <br>
        The compiler here would copy-construct an object of type X from
        x and make it available through the virtual concept C by storing
        the itable pointer for C(X) next to the storage occupied by c.<br>
        <br>
        A slightly more detailed, yet only sketched description is given
        here (see the "Implementation technique" section):=C2=A0<a
          moz-do-not-send=3D"true" href=3D"http://bit.ly/ZgruFY">http://bit=
..ly/ZgruFY</a>.<br>
        <br>
        I do realize there is much more to cover, but I'd like to know
        if this looks more promising or if the idea is fundamentally
        flawed.<br>
        <br>
      </div>
    </blockquote>
    Hi, <br>
    <br>
    I think the idea is in general useful, and surely need a lot of
    refinements.<br>
    However the name virtual concept is not really good and the
    implementation can surely be improved, but I don't think the
    implementation is the most important part for the time been. Anyway
    a type erased implementation with an additional adaptor to do the
    mapping, seems more understandable to me.<br>
    What I think is important is what we want to be able to do. <br>
    <br>
    Your virtual concept could be related to abstract data types
    (<a class=3D"moz-txt-link-freetext" href=3D"http://en.wikipedia.org/wik=
i/Abstract_data_type">http://en.wikipedia.org/wiki/Abstract_data_type</a>).=
<br>
    Type erasure usually has value semantics, but it is possible to give
    it reference or pointer semantics also.<br>
    =C2=A0<br>
    Do you expect x to be deleted after a call to delete c in the
    following example?<br>
    <br>
    <div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187,
      187); word-wrap: break-word; background-color: rgb(250, 250,
      250);"><code class=3D"prettyprint">
        <div class=3D"subprettyprint"><code class=3D"prettyprint"><span
              style=3D"color: #000;" class=3D"styled-by-prettify">X</span><=
font
              color=3D"#666600"><span style=3D"color: #660;"
                class=3D"styled-by-prettify">*</span></font><span
              style=3D"color: #000;" class=3D"styled-by-prettify"> xptr </s=
pan><span
              style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span=
><span
              style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span
              style=3D"color: #660;" class=3D"styled-by-prettify">new X</sp=
an><span
              style=3D"color: #000;" class=3D"styled-by-prettify"></span><s=
pan
              style=3D"color: #660;" class=3D"styled-by-prettify">;</span><=
span
              style=3D"color: #000;" class=3D"styled-by-prettify"><br>
            </span></code><code class=3D"prettyprint"><span style=3D"color:
              #000;" class=3D"styled-by-prettify">C</span><font
              color=3D"#666600"><span style=3D"color: #660;"
                class=3D"styled-by-prettify">*</span></font><span
              style=3D"color: #000;" class=3D"styled-by-prettify"> c </span=
><span
              style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span=
><span
              style=3D"color: #000;" class=3D"styled-by-prettify"> xptr</sp=
an><span
              style=3D"color: #660;" class=3D"styled-by-prettify">;</span><=
span
              style=3D"color: #000;" class=3D"styled-by-prettify"><br>
            </span></code><span style=3D"color: #000;"
            class=3D"styled-by-prettify">c</span><span style=3D"color:
            #660;" class=3D"styled-by-prettify">-&gt;</span><span
            style=3D"color: #000;" class=3D"styled-by-prettify">foo</span><=
span
            style=3D"color: #660;" class=3D"styled-by-prettify">();<br>
            delete c<br>
          </span></div>
      </code></div>
    <br>
    If this is the case, you need a way to state it explicitly on the
    virtual concept definition.<br>
    <br>
    BTW, why do you need that <br>
    <br>
    =C2=A0C&amp; cx =3D x;<br>
    =C2=A0assert(&amp;cx =3D=3D &amp;x); <br>
    <br>
    ?<br>
    Note that as C is not really a class, the assertion must not
    forcedly be implied.<br>
    <br>
    Could virtual concepts inherit from other virtual concepts?<br>
    <br>
    <br>
    <br>
    Vicente<br>
  </body>
</html>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />

--------------090008060808080103030800--

.

------=_Part_1473_1899515248.1411832366107
Content-Type: text/plain; charset=UTF-8

Hi Vicente,

Thank you for sharing your thoughts. I will try to address your points in
the following.

1. I am not particularly attached to the name "virtual concept". In Haskell
there is something very similar which is called "typeclass", so I could
have used that name. On the other hand, the old C++0x idea of "concept
maps" was also something pretty similar, except for the fact that they were
meant for template-based compile-time polymorphism (just like Concepts
Lite), while my goal was to provide a mechanism for non-intrusive dynamic
polymorphism. I picked the name "concept" to evoke the parallel with
concept maps, and the adjective "virtual" to draw a connection with virtual
call dispatch. But this is really a detail to me, so I'm open to
suggestions for a better terminology.

2. In your example, I do expect "x" to be deleted when doing "delete c". My
original idea was that all virtual concepts should implicitly support
destruction as part of the interface they define, and the every itable
would contain an entry for the corresponding type's instantiation pointing
to that type's destructor. However, I could as well require the destructor
to be explicitly mentioned in the virtual concept's definition as a
prerequisite for writing "delete c" (but also for using objects of concept
type with value semantics, since objects with automatic storage duration
are implicitly destroyed when they go out of scope). For other special
operations, like copy-construction, I require the corresponding special
member function to be explicitly mentioned in the concept definition (see
the draft I linked).

3. The reason why I think the assertion (&cx == &x) should not fail is that
I want to enable reference semantics. Judging from what you write, I am now
led to think that satisfying this assertion is not a necessary condition
for achieving my goal. Anyway, my idea is that if a client stores a pointer
to a virtual concept (say, "C* pc"), and later wants to figure out if the
object pointed to by "pc" is the same object as another object pointed to
by "px" (of type "T*", where "T" has an instantiation for "C"), it may do
so by checking whether (pc == px). I thought special support from the
compiler would be necessary to realize this, and that implementation would
be the toughest obstacle - that's why I am trying to tackle it since the
beginning. Please let me know if I am mistaken.

4. I do find it reasonable to allow virtual concepts to derive from other
virtual concepts, but so far I haven't really thought through this in
detail. In fact, when I opened this thread I considered it quite likely
that my idea would be immediately classified as unfeasible by the experts,
so I didn't want to invest time and effort on a full-blown proposal before
getting some feedback.

Concerning the use of techniques based on type erasure (with which I am
only mildly familiar from the technical viewpoint), one of my goals is to
make code using virtual concepts compile fast (ideally as fast as code
using traditional inheritance-based polymorphism). This is why I would
avoid library solutions such as Boost.TypeErasure, because they will likely
be heavily based on templates, and that does have a significant impact on
build time - and readability as well, unless macros are used, but I
personally dislike macros.

Kind regards,

Andy

--

---
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_1473_1899515248.1411832366107
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Vicente,<br><br>Thank you for sharing your thoughts. I =
will try to address your points in the following.<br><br>1. I am not partic=
ularly attached to the name "virtual concept". In Haskell there is somethin=
g very similar which is called "typeclass", so I could have used that name.=
 On the other hand, the old C++0x idea of "concept maps" was also something=
 pretty similar, except for the fact that they were meant for template-base=
d compile-time polymorphism (just like Concepts Lite), while my goal was to=
 provide a mechanism for non-intrusive dynamic polymorphism. I picked the n=
ame "concept" to evoke the parallel with concept maps, and the adjective "v=
irtual" to draw a connection with virtual call dispatch. But this is really=
 a detail to me, so I'm open to suggestions for a better terminology.<br><b=
r>2. In your example, I do expect "x" to be deleted when doing "delete c". =
My original idea was that all virtual concepts should implicitly support de=
struction as part of the interface they define, and the every itable would =
contain an entry for the corresponding type's instantiation pointing to tha=
t type's destructor. However, I could as well require the destructor to be =
explicitly mentioned in the virtual concept's definition as a prerequisite =
for writing "delete c" (but also for using objects of concept type with val=
ue semantics, since objects with automatic storage duration are implicitly =
destroyed when they go out of scope). For other special operations, like co=
py-construction, I require the corresponding special member function to be =
explicitly mentioned in the concept definition (see the draft I linked).<br=
><br>3. The reason why I think the assertion (&amp;cx =3D=3D &amp;x) should=
 not fail is that I want to enable reference semantics. Judging from what y=
ou write, I am now led to think that satisfying this assertion is not a nec=
essary condition for achieving my goal. Anyway, my idea is that if a client=
 stores a pointer to a virtual concept&nbsp;<span style=3D"font-size: 13.33=
33330154419px;">(say, "C* pc")</span>, and later wants to figure out if the=
 object pointed to by "pc" is the same object as another object pointed to =
by "px" (of type "T*", where "T" has an instantiation for "C"), it may do s=
o by checking whether (pc =3D=3D px). I thought special support from the co=
mpiler would be necessary to realize this, and that implementation would be=
 the toughest obstacle - that's why I am trying to tackle it since the begi=
nning. Please let me know if I am mistaken.<br><br>4. I do find it reasonab=
le to allow virtual concepts to derive from other virtual concepts, but so =
far I haven't really thought through this in detail. In fact, when I opened=
 this thread I considered it quite likely that my idea would be immediately=
 classified as unfeasible by the experts, so I didn't want to invest time a=
nd effort on a full-blown proposal before getting some feedback.<br><br>Con=
cerning the use of techniques based on type erasure (with which I am only m=
ildly familiar from the technical viewpoint), one of my goals is to make co=
de using virtual concepts compile fast (ideally as fast as code using tradi=
tional inheritance-based polymorphism). This is why I would avoid library s=
olutions such as Boost.TypeErasure, because they will likely be heavily bas=
ed on templates, and that does have a significant impact on build time - an=
d readability as well, unless macros are used, but I personally dislike mac=
ros.<br><br>Kind regards,<br><br>Andy</div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_1473_1899515248.1411832366107--

.

------=_Part_1507_1608025895.1411859059909
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

BTW, some related literature:

 - Paper "Runtime Polymorphic Generic Programming [...]" by Mat Marcus,=20
Jaakko J=C3=A4rvi, and Sean Parent:=20
http://www.emarcus.org/papers/MPOOL2007-marcus.pdf

 - Slides of a presentation by Sean Parent on Adobe.Poly:=20
http://stlab.adobe.com/wiki/images/c/c9/Boost_poly.pdf

 - Sean Parent's talk "Value Semantics and Concepts-based Polymorphism":=20
https://www.youtube.com/watch?v=3D_BpMYeUFXv8

 - Sean Parent's talk "C++ Seasoning" @ GoingNative 2013:=20
http://channel9.msdn.com/Events/GoingNative/2013/Cpp-Seasoning

 - Sean Parent's talk "Inheritance Is The Base Class of Evil" @ GoingNative=
=20
2013:=20
http://channel9.msdn.com/Events/GoingNative/2013/Inheritance-Is-The-Base-Cl=
ass-of-Evil

 - Poly library by Pyry Jahkola: https://github.com/pyrtsa/poly

Kind regards,

Andy

--=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_1507_1608025895.1411859059909
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>BTW, some related literature:</div><div><br></div><di=
v style=3D"font-size: 13.3333330154419px;">&nbsp;- Paper "Runtime Polymorph=
ic Generic Programming [...]" by Mat Marcus, Jaakko J=C3=A4rvi, and Sean Pa=
rent: <a href=3D"http://www.emarcus.org/papers/MPOOL2007-marcus.pdf">http:/=
/www.emarcus.org/papers/MPOOL2007-marcus.pdf</a></div><div><br><div style=
=3D"font-size: 13.3333330154419px;">&nbsp;- Slides of a presentation by Sea=
n Parent on Adobe.Poly: <a href=3D"http://stlab.adobe.com/wiki/images/c/c9/=
Boost_poly.pdf">http://stlab.adobe.com/wiki/images/c/c9/Boost_poly.pdf</a><=
/div><br><div style=3D"font-size: 13.3333330154419px;">&nbsp;- Sean Parent'=
s talk "Value Semantics and Concepts-based Polymorphism": <a href=3D"https:=
//www.youtube.com/watch?v=3D_BpMYeUFXv8">https://www.youtube.com/watch?v=3D=
_BpMYeUFXv8</a></div><br>&nbsp;- Sean Parent's talk "C++ Seasoning" @ Going=
Native 2013: <a href=3D"http://channel9.msdn.com/Events/GoingNative/2013/Cp=
p-Seasoning">http://channel9.msdn.com/Events/GoingNative/2013/Cpp-Seasoning=
</a></div><div><br></div><div>&nbsp;- Sean Parent's talk "Inheritance Is Th=
e Base Class of Evil" @ GoingNative 2013: <a href=3D"http://channel9.msdn.c=
om/Events/GoingNative/2013/Inheritance-Is-The-Base-Class-of-Evil">http://ch=
annel9.msdn.com/Events/GoingNative/2013/Inheritance-Is-The-Base-Class-of-Ev=
il</a></div><div><br></div><div>&nbsp;- Poly library by Pyry Jahkola: <a hr=
ef=3D"https://github.com/pyrtsa/poly">https://github.com/pyrtsa/poly</a><br=
><br>Kind regards,<br><br>Andy</div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_1507_1608025895.1411859059909--

.

This is a multi-part message in MIME format.
--------------080909030208090401060605
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 27/09/14 17:39, Andy Prowl a =C3=A9crit :
> Hi Vicente,
>
> Thank you for sharing your thoughts. I will try to address your points=20
> in the following.
Sorry if my replay is too long and not clear enough.
>
> 1. I am not particularly attached to the name "virtual concept". In=20
> Haskell there is something very similar which is called "typeclass",=20
> so I could have used that name. On the other hand, the old C++0x idea=20
> of "concept maps" was also something pretty similar, except for the=20
> fact that they were meant for template-based compile-time polymorphism=20
> (just like Concepts Lite), while my goal was to provide a mechanism=20
> for non-intrusive dynamic polymorphism. I picked the name "concept" to=20
> evoke the parallel with concept maps, and the adjective "virtual" to=20
> draw a connection with virtual call dispatch. But this is really a=20
> detail to me, so I'm open to suggestions for a better terminology.
What you are proposing (locking for) is close to Haskell type classes,=20
but I don't think that it is possible to instantiate type classes (as=20
objects) in Haskell, Type class instances are the data type for which=20
there is a mapping. I believe that the user instantiate data types and=20
use the operations of the type class via the data type -> type class=20
mapping. Haskell type classes are much closer to concepts than what you=20
propose.

I would not use the name Concept as a Concept is not limited to a set of=20
functions. Abstract data types are more function oriented, this is way I=20
suggested this name. ADA abstract data types provide something similar=20
to what you are proposing IIRC. I don't know if we can take the address=20
of an abstract data type instance in ADA :(

You could also take a look at Java Generics as the compiler uses type=20
erasure to generate one compiled version of each generic class.
>
> 2. In your example, I do expect "x" to be deleted when doing "delete=20
> c". My original idea was that all virtual concepts should implicitly=20
> support destruction as part of the interface they define, and the=20
> every itable would contain an entry for the corresponding type's=20
> instantiation pointing to that type's destructor. However, I could as=20
> well require the destructor to be explicitly mentioned in the virtual=20
> concept's definition as a prerequisite for writing "delete c" (but=20
> also for using objects of concept type with value semantics, since=20
> objects with automatic storage duration are implicitly destroyed when=20
> they go out of scope). For other special operations, like=20
> copy-construction, I require the corresponding special member function=20
> to be explicitly mentioned in the concept definition (see the draft I=20
> linked).
>
I read the draft before posting. With value semantics, there is nothing=20
to delete (at least at the user level), only to destroy. As the virtual=20
concept knows exactly what type is stored (type erased) , I don't see=20
why the stored types must define a virtual destructor. Am I missing=20
something?
> 3. The reason why I think the assertion (&cx =3D=3D &x) should not fail i=
s=20
> that I want to enable reference semantics. Judging from what you=20
> write, I am now led to think that satisfying this assertion is not a=20
> necessary condition for achieving my goal.
I think that adding this requirement would make things more complex than=20
needed.
> Anyway, my idea is that if a client stores a pointer to a virtual=20
> concept (say, "C* pc"), and later wants to figure out if the object=20
> pointed to by "pc" is the same object as another object pointed to by=20
> "px" (of type "T*", where "T" has an instantiation for "C"), it may do=20
> so by checking whether (pc =3D=3D px).
yes, this is tempting, an maybe desirable. The question is whether we=20
want to check if the virtual concept pointer points to the same memory=20
address as the pointer to the type or just to be able to compare them. =20
The operator=3D=3D between pointers to virtual concept and a pointers to=20
types can be defined, without forcing that they have the same physical=20
address.

template <class M>
bool operator=3D=3D(const C* x, const  M* y) {
   return __underlying_ptr(x) =3D=3D y; // pointer semantics
}

where __underlying_ptr is an intrinsic that the compiler could reach to=20
manage. Is if a C* was implemented as a smart pointer.

The operator& on virtual concepts could also be defined using the same=20
intrinsic.

I'm not really happy with this however.

> I thought special support from the compiler would be necessary to=20
> realize this, and that implementation would be the toughest obstacle -=20
> that's why I am trying to tackle it since the beginning. Please let me=20
> know if I am mistaken.
I really don't know.
If I were using a smart pointer approach to implement a virtual concept=20
with pointer semantics let me call it virtual_concept_ptr<C>, I would=20
expect the following

X x;;
X* px;;
px =3D &x;
virtual_concept_ptr<C> pc(px);
assertion (pc =3D=3D px)

But if I have a virtual concept with value semantics, let me call it=20
virtual_concept_value<C>,

virtual_concept_value<C> c(x);
virtual_concept_value<C>* pc =3D &c;

The following comparison has no sens as we are using value semantics.

assertion (pc =3D=3D &x)

But the following would have a sense

assertion (*pc =3D=3D x)


The difference between virtual_concept_ptr<C> and virtual_concept<C>*,=20
is that the  virtual_concept_ptr<C> has pointer semantic, while=20
virtual_concept<C>* has value semantic, even if we are using a pointer.=20
That is, virtual_concept_ptr<C> is not the same as virtual_concept<C>*

When we rewrite the previous using directly virtual concepts

X x;;
X* px;;
px =3D &x;
C* pc; // (1)
pc =3Dpx;


C c(x);
C* pc; // (2)
pc =3D &c;

The question is how do we interpret the C* pc; declaration. Has the=20
concept C value or pointer semantics? I don't have a response. That=20
could mean that, at the language level, we would need to consider=20
different syntax to represent the different semantics. This wouldn't fit=20
well with c++. So IMO, the type erased type must have value semantics.=20
If we want a virtual concept with pointer semantics, the virtual concept=20
must define the operations 'pointer' operations and accept only=20
'pointers' as a smart pointer.

>
> 4. I do find it reasonable to allow virtual concepts to derive from=20
> other virtual concepts, but so far I haven't really thought through=20
> this in detail. In fact, when I opened this thread I considered it=20
> quite likely that my idea would be immediately classified as=20
> unfeasible by the experts, so I didn't want to invest time and effort=20
> on a full-blown proposal before getting some feedback.
I believe that the experts have not talk yet ;-)
>
> Concerning the use of techniques based on type erasure (with which I=20
> am only mildly familiar from the technical viewpoint), one of my goals=20
> is to make code using virtual concepts compile fast (ideally as fast=20
> as code using traditional inheritance-based polymorphism). This is why=20
> I would avoid library solutions such as Boost.TypeErasure, because=20
> they will likely be heavily based on templates, and that does have a=20
> significant impact on build time - and readability as well, unless=20
> macros are used, but I personally dislike macros.
I can understand that you want to avoid Boost.TypeErasure. For me type=20
erasure is not associated to a library solution. It can be associated to=20
the language and the compiler can do it better than a library. When I=20
said that a type erasure implementation could be appropriated, I should=20
said instead that your proposal fits naturally with a type erased model.=20
Just you're locking for pointer semantics. Maybe it is worth considering=20
a virtual concept (with value semantics) that is a pointer to another=20
virtual concept.

Resuming, I believe that introducing in the language type erased types=20
with value semantics will already be a good goal.

Vicente

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

--------------080909030208090401060605
Content-Type: text/html; charset=UTF-8
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">Le 27/09/14 17:39, Andy Prowl a =C3=A9cr=
it=C2=A0:<br>
    </div>
    <blockquote
      cite=3D"mid:2354b547-7e6f-4ec5-995f-8d09bbc0b9af@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">Hi Vicente,<br>
        <br>
        Thank you for sharing your thoughts. I will try to address your
        points in the following.<br>
      </div>
    </blockquote>
    Sorry if my replay is too long and not clear enough.<br>
    <blockquote
      cite=3D"mid:2354b547-7e6f-4ec5-995f-8d09bbc0b9af@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr"><br>
        1. I am not particularly attached to the name "virtual concept".
        In Haskell there is something very similar which is called
        "typeclass", so I could have used that name. On the other hand,
        the old C++0x idea of "concept maps" was also something pretty
        similar, except for the fact that they were meant for
        template-based compile-time polymorphism (just like Concepts
        Lite), while my goal was to provide a mechanism for
        non-intrusive dynamic polymorphism. I picked the name "concept"
        to evoke the parallel with concept maps, and the adjective
        "virtual" to draw a connection with virtual call dispatch. But
        this is really a detail to me, so I'm open to suggestions for a
        better terminology.<br>
      </div>
    </blockquote>
    What you are proposing (locking for) is close to Haskell type
    classes, but I don't think that it is possible to instantiate type
    classes (as objects) in Haskell, Type class instances are the data
    type for which there is a mapping. I believe that the user
    instantiate data types and use the operations of the type class via
    the data type -&gt; type class mapping. Haskell type classes are
    much closer to concepts than what you propose. <br>
    <br>
    I would not use the name Concept as a Concept is not limited to a
    set of functions. Abstract data types are more function oriented,
    this is way I suggested this name. ADA abstract data types provide
    something similar to what you are proposing IIRC. I don't know if we
    can take the address of an abstract data type instance in ADA :(<br>
    <br>
    You could also take a look at Java Generics as the compiler uses
    type erasure to generate one compiled version of each generic class.<br=
>
    <blockquote
      cite=3D"mid:2354b547-7e6f-4ec5-995f-8d09bbc0b9af@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr"><br>
        2. In your example, I do expect "x" to be deleted when doing
        "delete c". My original idea was that all virtual concepts
        should implicitly support destruction as part of the interface
        they define, and the every itable would contain an entry for the
        corresponding type's instantiation pointing to that type's
        destructor. However, I could as well require the destructor to
        be explicitly mentioned in the virtual concept's definition as a
        prerequisite for writing "delete c" (but also for using objects
        of concept type with value semantics, since objects with
        automatic storage duration are implicitly destroyed when they go
        out of scope). For other special operations, like
        copy-construction, I require the corresponding special member
        function to be explicitly mentioned in the concept definition
        (see the draft I linked).<br>
        <br>
      </div>
    </blockquote>
    I read the draft before posting. With value semantics, there is
    nothing to delete (at least at the user level), only to destroy. As
    the virtual concept knows exactly what type is stored (type erased)
    , I don't see why the stored types must define a virtual destructor.
    Am I missing something? <br>
    <blockquote
      cite=3D"mid:2354b547-7e6f-4ec5-995f-8d09bbc0b9af@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">3. The reason why I think the assertion (&amp;cx =3D=
=3D
        &amp;x) should not fail is that I want to enable reference
        semantics. Judging from what you write, I am now led to think
        that satisfying this assertion is not a necessary condition for
        achieving my goal. </div>
    </blockquote>
    I think that adding this requirement would make things more complex
    than needed.<br>
    <blockquote
      cite=3D"mid:2354b547-7e6f-4ec5-995f-8d09bbc0b9af@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">Anyway, my idea is that if a client stores a
        pointer to a virtual concept=C2=A0<span style=3D"font-size:
          13.3333330154419px;">(say, "C* pc")</span>, and later wants to
        figure out if the object pointed to by "pc" is the same object
        as another object pointed to by "px" (of type "T*", where "T"
        has an instantiation for "C"), it may do so by checking whether
        (pc =3D=3D px). </div>
    </blockquote>
    yes, this is tempting, an maybe desirable. The question is whether
    we want to check if the virtual concept pointer points to the same
    memory address as the pointer to the type or just to be able to
    compare them.=C2=A0 The operator=3D=3D between pointers to virtual conc=
ept
    and a pointers to types can be defined, without forcing that they
    have the same physical address.<br>
    <br>
    template &lt;class M&gt;<br>
    bool operator=3D=3D(const C* x, const=C2=A0 M* y) { <br>
    =C2=A0 return __underlying_ptr(x) =3D=3D y; // pointer semantics<br>
    } <br>
    <br>
    where __underlying_ptr is an intrinsic that the compiler could reach
    to manage. Is if a C* was implemented as a smart pointer.<br>
    <br>
    The operator&amp; on virtual concepts could also be defined using
    the same intrinsic.<br>
    <br>
    I'm not really happy with this however.<br>
    <br>
    <blockquote
      cite=3D"mid:2354b547-7e6f-4ec5-995f-8d09bbc0b9af@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">I thought special support from the compiler would
        be necessary to realize this, and that implementation would be
        the toughest obstacle - that's why I am trying to tackle it
        since the beginning. Please let me know if I am mistaken.<br>
      </div>
    </blockquote>
    I really don't know. <br>
    If I were using a smart pointer approach to implement a virtual
    concept with pointer semantics let me call it
    virtual_concept_ptr&lt;C&gt;, I would expect the following<br>
    <br>
    X x;;<br>
    X* px;;<br>
    px =3D &amp;x;<br>
    virtual_concept_ptr&lt;C&gt; pc(px);<br>
    assertion (pc =3D=3D px)<br>
    <br>
    But if I have a virtual concept with value semantics, let me call it
    virtual_concept_value&lt;C&gt;, <br>
    <br>
    virtual_concept_value&lt;C&gt; c(x);<br>
    virtual_concept_value&lt;C&gt;* pc =3D &amp;c;<br>
    <br>
    The following comparison has no sens as we are using value
    semantics.<br>
    <br>
    assertion (pc =3D=3D &amp;x)<br>
    <br>
    But the following would have a sense<br>
    <br>
    assertion (*pc =3D=3D x)<br>
    <br>
    <br>
    The difference between virtual_concept_ptr&lt;C&gt; and
    virtual_concept&lt;C&gt;*, is that the=C2=A0 virtual_concept_ptr&lt;C&g=
t;
    has pointer semantic, while=C2=A0
    virtual_concept&lt;C&gt;* has value semantic, even if we are using a
    pointer. That is, virtual_concept_ptr&lt;C&gt; is not the same as
    virtual_concept&lt;C&gt;*<br>
    <br>
    When we rewrite the previous using directly virtual concepts<br>
    <br>
    X x;;<br>
    X* px;;<br>
    px =3D &amp;x;<br>
    C* pc; // (1)<br>
    pc =3Dpx;<br>
    <br>
    <br>
    C c(x);<br>
    C* pc; // (2)<br>
    pc =3D &amp;c;<br>
    <br>
    The question is how do we interpret the C* pc; declaration. Has the
    concept C value or pointer semantics? I don't have a response. That
    could mean that, at the language level, we would need to consider
    different syntax to represent the different semantics. This wouldn't
    fit well with c++. So IMO, the type erased type must have value
    semantics. If we want a virtual concept with pointer semantics, the
    virtual concept must define the operations 'pointer' operations and
    accept only 'pointers' as a smart pointer.<br>
    <br>
    <blockquote
      cite=3D"mid:2354b547-7e6f-4ec5-995f-8d09bbc0b9af@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr"><br>
        4. I do find it reasonable to allow virtual concepts to derive
        from other virtual concepts, but so far I haven't really thought
        through this in detail. In fact, when I opened this thread I
        considered it quite likely that my idea would be immediately
        classified as unfeasible by the experts, so I didn't want to
        invest time and effort on a full-blown proposal before getting
        some feedback.<br>
      </div>
    </blockquote>
    I believe that the experts have not talk yet ;-)<br>
    <blockquote
      cite=3D"mid:2354b547-7e6f-4ec5-995f-8d09bbc0b9af@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr"><br>
        Concerning the use of techniques based on type erasure (with
        which I am only mildly familiar from the technical viewpoint),
        one of my goals is to make code using virtual concepts compile
        fast (ideally as fast as code using traditional
        inheritance-based polymorphism). This is why I would avoid
        library solutions such as Boost.TypeErasure, because they will
        likely be heavily based on templates, and that does have a
        significant impact on build time - and readability as well,
        unless macros are used, but I personally dislike macros.<br>
      </div>
    </blockquote>
    I can understand that you want to avoid Boost.TypeErasure. For me
    type erasure is not associated to a library solution. It can be
    associated to the language and the compiler can do it better than a
    library. When I said that a type erasure implementation could be
    appropriated, I should said instead that your proposal fits
    naturally with a type erased model. Just you're locking for pointer
    semantics. Maybe it is worth considering a virtual concept (with
    value semantics) that is a pointer to another virtual concept.<br>
    <br>
    Resuming, I believe that introducing in the language type erased
    types with value semantics will already be a good goal.<br>
    =C2=A0 <br>
    Vicente<br>
  </body>
</html>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />

--------------080909030208090401060605--

.

--f46d041826ec1bcf31050423224a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

=E2=80=8BHi, I think the initial idea have some merits but proposing to mod=
ify the
class definitions to adhere to a "virtual concept" seems going backward to
me.
In any way it made me realize the following, just pure ideas that might be
useful to someone around here.

Let's assume that we have
 1. concepts (as defined in the last proposals from Sutton & Stroustrup &
others)
 2. reflection on concepts (at least ways to generate code from patterns
depending on the properties of a concept)
 3. a way to ask for a concept in a template definition (not a type
matching the concept, an actual concept)

Then it would be possible to build library types that can, for example, do
the same work as proposed here. Something like:

   void some_work( C<Iterator> it ); // concrete function, C<Iterator> is a
concrete type.

In this case C would be a template class which interface would look like:

    template< concept K >
    class C
    {
    public:
        // ...
        C( K&& value ); // actually a template constructor using the
concept K
        C& operator=3D( K&& value );  /// actually a template assignment
operator using the concept K

    private:
        /// code using reflection to generate the type-erasing code
        /// following the concept constraints to generate a type
    };


....

Now, thinking about this while writing it, having a way to just generate an
anonymous type that would
follow the provided concept would be useful to generate type-erasure...


End of ideas.

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

--f46d041826ec1bcf31050423224a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>=E2=80=8BHi, I think the initial idea have some merits=
 but proposing to modify the class definitions to adhere to a &quot;virtual=
 concept&quot; seems going backward to me.<div>In any way it made me realiz=
e the following, just pure ideas that might be useful to someone around her=
e.</div><div><br></div><div>Let&#39;s assume that we have=C2=A0<br>=C2=A01.=
 concepts (as defined in the last proposals from Sutton &amp; Stroustrup &a=
mp; others)</div><div>=C2=A02. reflection on concepts (at least ways to gen=
erate code from patterns depending on the properties of a concept)</div><di=
v>=C2=A03. a way to ask for a concept in a template definition (not a type =
matching the concept, an actual concept)</div><div><br></div><div>Then it w=
ould be possible to build library types that can, for example, do the same =
work as proposed here. Something like:</div><div><br></div><div>=C2=A0 =C2=
=A0void some_work( C&lt;Iterator&gt; it ); // concrete function, C&lt;Itera=
tor&gt; is a concrete type.</div><div><br></div><div>In this case C would b=
e a template class which interface would look like:</div><div><br></div><di=
v>=C2=A0 =C2=A0 template&lt; concept K &gt;</div><div>=C2=A0 =C2=A0 class C=
</div><div>=C2=A0 =C2=A0 {</div><div>=C2=A0 =C2=A0 public:</div><div>=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 // ...</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 C( K&amp=
;&amp; value ); // actually a template constructor using the concept K</div=
><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 C&amp; operator=3D( K&amp;&amp; value ); =
=C2=A0/// actually a template assignment operator using the concept K</div>=
<div><br></div><div>=C2=A0 =C2=A0 private:</div><div>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 /// code using reflection to generate the type-erasing code</div><di=
v>=C2=A0 =C2=A0 =C2=A0 =C2=A0 /// following the concept constraints to gene=
rate a type</div><div>=C2=A0 =C2=A0 };</div><div><br></div><div><br></div><=
div>...</div><div><br></div><div>Now, thinking about this while writing it,=
 having a way to just generate an anonymous type that would</div><div>follo=
w the provided concept would be useful to generate type-erasure...</div><di=
v><br></div><div><br></div><div>End of ideas.</div><div><br></div><div><br>=
</div><div><br></div><div><br></div><div><br></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />

--f46d041826ec1bcf31050423224a--

.

On 28 September 2014 20:03, Klaim - Jo=C3=ABl Lamotte <mjklaim@gmail.com> w=
rote:
>
> Hi, I think the initial idea have some merits but proposing to modify the
> class definitions to adhere to a "virtual concept" seems going backward t=
o
> me.
> In any way it made me realize the following, just pure ideas that might b=
e
> useful to someone around here.
>
> Let's assume that we have
>  1. concepts (as defined in the last proposals from Sutton & Stroustrup &
> others)
>  2. reflection on concepts (at least ways to generate code from patterns
> depending on the properties of a concept)
>  3. a way to ask for a concept in a template definition (not a type match=
ing
> the concept, an actual concept)
>
> Then it would be possible to build library types that can, for example, d=
o
> the same work as proposed here. Something like:


I don't see why this idea needs concepts or reflection of concepts. If we h=
ave
reflection, it's quite simple to create an adapter template that derives fr=
om
the interface (aka the 'virtual concept', which we probably don't need to a=
dd
as a separate facility at all), and uses reflection to call the right signa=
ture
in the target class in the adapter's overrides of the interface
virtuals. The rest of it is
wrapping the objects of the target class type in the adapters where necessa=
ry.

--=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_25_2142887148.1411928281291
Content-Type: text/plain; charset=UTF-8

@Vicente:

My post was long, so it's natural for your answer to be long as well. No
need to apologize :)

Haskell is a very different language from C++, so analogies can only go
that far. There are no "references" and "pointers" there, no modifiable
"objects", so the parallel with type classes is mostly illustrative.
However, I do believe that it makes sense to have objects "of virtual
concept type" which, as I propose, would be represented in memory as pairs
of pointers.

Honestly, the more I think about it, the more I believe the name "concept"
is quite fitting. The analogy with compile-time concepts is very strong,
and in fact I wrote another draft of the proposal that uses the same (or
very similar) syntax. Accordingly, virtual concept instantiations are now
introduced as "virtual concept maps".

Please have a look at the latest version, which you can find here:
http://bit.ly/ZgruFY.

Concerning to value semantics: deletion is necessary "under the hood",
because dynamic allocation is (often) required when passing type-erased
objects by value (module SBO). Please refer to the latest draft for the
details (section "Implementation technique").

I also considered the possibility of having a concept_ptr_ref<C> and a
concept_ptr_value<C>, but I found this unnecessary and I could not foresee
all the implications. Using C*, C&, or C is just more natural, and the
implementation I propose seems to be relatively easy (I consulted this with
a "compiler guy").
That would also allow performing pointer comparison, which (as you write)
is tempting/desirable. It also does not require different syntax for
supporting reference semantics vs. value semantics.

Kind regards,

Andy


--

---
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_25_2142887148.1411928281291
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">@Vicente:<br><br>My post was long, so it's natural for you=
r answer to be long as well. No need to apologize :)<br><br>Haskell is a ve=
ry different language from C++, so analogies can only go that far. There ar=
e no "references" and "pointers" there, no modifiable "objects", so the par=
allel with type classes is mostly illustrative. However, I do believe that =
it makes sense to have objects "of virtual concept type" which, as I propos=
e, would be represented in memory as pairs of pointers.<br><br>Honestly, th=
e more I think about it, the more I believe the name "concept" is quite fit=
ting. The analogy with compile-time concepts is very strong, and in fact I =
wrote another draft of the proposal that uses the same (or very similar) sy=
ntax. Accordingly, virtual concept instantiations are now introduced as "vi=
rtual concept maps". <br><br>Please have a look at the latest version, whic=
h you can find here:&nbsp;<a href=3D"http://bit.ly/ZgruFY" target=3D"_blank=
" style=3D"cursor: pointer; font-size: 13.3333330154419px;">http://bit.ly/<=
wbr>ZgruFY</a><span style=3D"font-size: 13px;">.</span><br><br>Concerning t=
o value semantics: deletion is necessary "under the hood", because dynamic =
allocation is (often) required when passing type-erased objects by value (m=
odule SBO). Please refer to the latest draft for the details (section "Impl=
ementation technique").<br><br>I also considered the possibility of having =
a concept_ptr_ref&lt;C&gt; and a concept_ptr_value&lt;C&gt;, but I found th=
is unnecessary and I could not foresee all the implications. Using C*, C&am=
p;, or C is just more natural, and the implementation I propose seems to be=
 relatively easy (I consulted this with a "compiler guy").<br>That would al=
so allow performing pointer comparison, which (as you write) is tempting/de=
sirable. It also does not require different syntax for supporting reference=
 semantics vs. value semantics.<br><br>Kind regards,<br><br>Andy<br><br><br=
></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_25_2142887148.1411928281291--

.

------=_Part_2218_1011511268.1411929231862
Content-Type: text/plain; charset=UTF-8

@Ville:

Thank you for sharing your thoughts.

Due to my lack of knowledge I cannot say I understand your point about
reflection, so I have a few questions:

1. Would the performance of a function call dispatch with a machinery
involving reflection be comparable to that of a call through a vtable?

2. Given "concept" (or whatever we call it) C such that "x.foo()" is valid
when "x" is instance of a model of C, would your approach allow writing
something like this?

X x;
C* c = &x;
c->foo();
assert(&c == &x);
C c = x;
c.foo();

3. Is the "adaptation" you write about something that could be written
"once and for all" and made part of the standard library (provided we have
reflection, of course), or is the user supposed to code it for their own
types/concepts? Would it require fiddling with templates and/or macros?

4. Do we have a proposal for reflection? The one I have seen one some time
ago (http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3951.pdf) did
not seem very mature to me.

Kind regards,

Andrea

--

---
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_2218_1011511268.1411929231862
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">@Ville:<br><br>Thank you for sharing your thoughts. <br><b=
r>Due to my lack of knowledge I cannot say I understand your point about re=
flection, so I have a few questions: <br><br>1. Would the performance of a =
function call dispatch with a machinery involving reflection be comparable =
to that of a call through a vtable?<br><br>2. Given "concept" (or whatever =
we call it) C such that "x.foo()" is valid when "x" is instance of a model =
of C,&nbsp;<span style=3D"font-size: 13.3333330154419px;">would your approa=
ch allow writing something like this</span>?&nbsp;<br><br><div class=3D"pre=
ttyprint" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-w=
ord; background-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><di=
v class=3D"subprettyprint"><span style=3D"font-size: 13.3333330154419px; co=
lor: rgb(0, 0, 0);"><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">X x</span></span><span style=3D"font-size: 13.3333330154419px; color: rg=
b(102, 102, 0);"><span style=3D"color: #660;" class=3D"styled-by-prettify">=
;</span></span><span style=3D"font-size: 13.3333330154419px; color: rgb(0, =
0, 0);"><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>C</sp=
an></span><font color=3D"#666600" style=3D"font-size: 13.3333330154419px;">=
<span style=3D"color: #660;" class=3D"styled-by-prettify">*</span></font><s=
pan style=3D"font-size: 13.3333330154419px; color: rgb(0, 0, 0);"><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> c </span></span><span sty=
le=3D"font-size: 13.3333330154419px; color: rgb(102, 102, 0);"><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span></span><span style=
=3D"font-size: 13.3333330154419px; color: rgb(0, 0, 0);"><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span></span><span style=3D"font-=
size: 13.3333330154419px; color: rgb(102, 102, 0);"><span style=3D"color: #=
660;" class=3D"styled-by-prettify">&amp;</span></span><span style=3D"font-s=
ize: 13.3333330154419px; color: rgb(0, 0, 0);"><span style=3D"color: #000;"=
 class=3D"styled-by-prettify">x</span></span><span style=3D"font-size: 13.3=
333330154419px; color: rgb(102, 102, 0);"><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">;</span></span><span style=3D"font-size: 13.333333=
0154419px;"><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>c=
</span><font color=3D"#666600"><span style=3D"color: #660;" class=3D"styled=
-by-prettify">-&gt;</span></font></span><span style=3D"font-size: 13.333333=
0154419px; color: rgb(0, 0, 0);"><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">foo</span></span><span style=3D"font-size: 13.3333330154419=
px; color: rgb(102, 102, 0);"><span style=3D"color: #660;" class=3D"styled-=
by-prettify">();</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br></span></span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">assert</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">(&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">c=
 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=3D</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">x</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br>C c </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> x</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br>c</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">foo</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">();</span></di=
v></code></div><br>3. Is the "adaptation" you write about something that co=
uld be written "once and for all" and made part of the standard library (pr=
ovided we have reflection, of course), or is the user supposed to code it f=
or their own types/concepts? Would it require fiddling with templates and/o=
r macros?&nbsp;<br><br>4. Do we have a proposal for reflection? The one I h=
ave seen one some time ago (<a href=3D"http://www.open-std.org/JTC1/SC22/WG=
21/docs/papers/2014/n3951.pdf">http://www.open-std.org/JTC1/SC22/WG21/docs/=
papers/2014/n3951.pdf</a>)&nbsp;<span style=3D"font-size: 13px;">did not se=
em very mature to me.</span><div><br>Kind regards,<br><br>Andrea<br><br></d=
iv></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_2218_1011511268.1411929231862--

.

------=_Part_313_1358311824.1411929616416
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

@Jo=C3=ABl:

Perhaps there has been a misunderstanding, I am not proposing to modify=20
class definitions to adhere to a "virtual concept". In fact, what I am=20
proposing is a non-intrusive mechanism for runtime polymorphism.=20

What possibly led you to think the mechanism was intrusive may have been=20
the syntax I used for introducing concept instantiations. I have changed=20
that in the last version of my draft to mirror the syntax of C++0x=20
(compile-time) concept maps. You can find the last version here:=20
http://bit.ly/ZgruFY.

For what concerns the rest of your post, I have trouble understanding the=
=20
reflection-related logic in comments it due to my lack of knowledge about=
=20
reflection, but in general I think that this feature does not require=20
reflection and can be efficiently implemented without it (see the draft).

Kind regards,

Andy

--=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_313_1358311824.1411929616416
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">@Jo<span style=3D"font-size: 13.3333330154419px;">=C3=AB</=
span>l:<br><br>Perhaps there has been a misunderstanding, I am not proposin=
g to modify class definitions to adhere to a "virtual concept". In fact, wh=
at I am proposing is a non-intrusive mechanism for runtime polymorphism. <b=
r><br>What possibly led you to think the mechanism was intrusive may have b=
een the syntax I used for introducing concept instantiations. I have change=
d that in the last version of my draft to mirror the syntax of C++0x (compi=
le-time) concept maps. You can find the last version here:&nbsp;<a href=3D"=
http://bit.ly/ZgruFY" target=3D"_blank" style=3D"cursor: pointer; font-size=
: 13.3333330154419px;">http://bit.ly/ZgruFY</a><span style=3D"font-size: 13=
px;">.</span><br><br>For what concerns the rest of your post, I have troubl=
e understanding the reflection-related logic in comments it due to my lack =
of knowledge about reflection, but in general I think that this feature doe=
s not require reflection and can be efficiently implemented without it (see=
 the draft).<br><br>Kind regards,<br><br>Andy</div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_313_1358311824.1411929616416--

.

On 28 September 2014 21:33, Andy Prowl <andy.prowl@gmail.com> wrote:
> @Ville:
> Thank you for sharing your thoughts.
> Due to my lack of knowledge I cannot say I understand your point about
> reflection, so I have a few questions:
> 1. Would the performance of a function call dispatch with a machinery
> involving reflection be comparable to that of a call through a vtable?

The call of the interface/"virtual concept" function is virtual, the forwarding
of that from the adapter is a non-virtual call that may or may not be inlined
depending on whether the function called is inline.

> 2. Given "concept" (or whatever we call it) C such that "x.foo()" is valid
> when "x" is instance of a model of C, would your approach allow writing
> something like this?
>
> X x;
> C* c = &x;
> c->foo();
> assert(&c == &x);
> C c = x;
> c.foo();

Probably not. You would need to do something like
X x;
CWrap<X> cwx{x};
C* c = &cwx;
c->foo();
// the assertion for address equality would be false
C& c2 = cwx;
c.foo();

> 3. Is the "adaptation" you write about something that could be written "once
> and for all" and made part of the standard library (provided we have
> reflection, of course), or is the user supposed to code it for their own
> types/concepts? Would it require fiddling with templates and/or macros?

We don't have a facility for generating overrides for the
interface/virtual-concept
functions, so we can't make an adapter fully generic. You don't need any
macros, and you don't have to use templates if you don't want to, but making
such adapters more generic will benefit from templates. So, unless reflection
gains the capability of being able to generate overrides for base
class functions,
you would have to adapt your own types. Reflection helps with the adaptation
and can make it more generic when combined with templates, but at least in
its proposed form it can't make it fully generic/automatic.

> 4. Do we have a proposal for reflection? The one I have seen one some time
> ago (http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3951.pdf) did
> not seem very mature to me.

See
http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4113.pdf

--

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

.

On 28 September 2014 22:10, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> Probably not. You would need to do something like
> X x;
> CWrap<X> cwx{x};
> C* c = &cwx;
> c->foo();
> // the assertion for address equality would be false
> C& c2 = cwx;
> c.foo();

That last bit should be c2.foo().

--

---
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_346_1728684418.1411932711420
Content-Type: text/plain; charset=UTF-8

@Ville: Thank you for your explanation. Please find my comments below (I'm
new to this forum so I hope I'm not screwing up formatting or something).

On Sunday, September 28, 2014 9:10:09 PM UTC+2, Ville Voutilainen wrote:
>
> On 28 September 2014 21:33, Andy Prowl <andy....@gmail.com <javascript:>>
> wrote:
> > @Ville:
> > Thank you for sharing your thoughts.
> > Due to my lack of knowledge I cannot say I understand your point about
> > reflection, so I have a few questions:
> > 1. Would the performance of a function call dispatch with a machinery
> > involving reflection be comparable to that of a call through a vtable?
>
> The call of the interface/"virtual concept" function is virtual, the
> forwarding
> of that from the adapter is a non-virtual call that may or may not be
> inlined
> depending on whether the function called is inline.
>

Are you not describing something similar to the concept/model approach
outlined here (slide 24):
http://stlab.adobe.com/wiki/images/c/c9/Boost_poly.pdf? I do realize that
this mechanism requires one virtual dispatch + one regular function call
(in fact, this is pretty much what my proposal boils down to for value
semantics, except it's all done by the compiler), but I see no reflection
involved. I am particularly concerned with run-time reflection, but perhaps
it's compile-time reflection you are talking about. If that's the case,
sorry for the misunderstanding. Always assuming we're talking about
compile-time reflection, does it mean that reflection would be used to
generate the concept/model types?


> > 2. Given "concept" (or whatever we call it) C such that "x.foo()" is
> valid
> > when "x" is instance of a model of C, would your approach allow writing
> > something like this?
> >
> > X x;
> > C* c = &x;
> > c->foo();
> > assert(&c == &x);
> > C c = x;
> > c.foo();
>
> Probably not. You would need to do something like
> X x;
> CWrap<X> cwx{x};
> C* c = &cwx;
> c->foo();
> // the assertion for address equality would be false
> C& c2 = cwx;
> c.foo();
>

OK, so it seems to me (no arrogance intended) that the solution based on
reflection is not as powerful as the mechanism I am proposing, nor as
natural/easy to use.


> > 3. Is the "adaptation" you write about something that could be written
> "once
> > and for all" and made part of the standard library (provided we have
> > reflection, of course), or is the user supposed to code it for their own
> > types/concepts? Would it require fiddling with templates and/or macros?
>
> We don't have a facility for generating overrides for the
> interface/virtual-concept
> functions, so we can't make an adapter fully generic. You don't need any
> macros, and you don't have to use templates if you don't want to, but
> making
> such adapters more generic will benefit from templates. So, unless
> reflection
> gains the capability of being able to generate overrides for base
> class functions,
> you would have to adapt your own types. Reflection helps with the
> adaptation
> and can make it more generic when combined with templates, but at least in
> its proposed form it can't make it fully generic/automatic.
>

Same observation as above: this requires the user to write some boilerplate
code. I can imagine the burden could be reduced by extracting a generic
part of this boilerplate code into some template facility, but this affects
both readability/maintainability and build times. One of the design goals
for my proposal is to have build times comparable to those that
interface-based polymorphism offers. Isn't this approach going to make
build times rather comparable with those of using a library solution like
Boost.TypeErasure?

> 4. Do we have a proposal for reflection? The one I have seen one some
> time
> > ago (http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3951.pdf)
> did
> > not seem very mature to me.
>
> See
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4113.pdf
>

Thank you,

Andy

--

---
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_346_1728684418.1411932711420
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">@Ville: Thank you for your explanation. Please find my com=
ments below (I'm new to this forum so I hope I'm not screwing up formatting=
 or something).<br><br>On Sunday, September 28, 2014 9:10:09 PM UTC+2, Vill=
e Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 28 Sept=
ember 2014 21:33, Andy Prowl &lt;<a href=3D"javascript:" target=3D"_blank" =
gdf-obfuscated-mailto=3D"QL2FQL6Ly1QJ" onmousedown=3D"this.href=3D'javascri=
pt:';return true;" onclick=3D"this.href=3D'javascript:';return true;">andy.=
....@gmail.com</a>&gt; wrote:
<br>&gt; @Ville:
<br>&gt; Thank you for sharing your thoughts.
<br>&gt; Due to my lack of knowledge I cannot say I understand your point a=
bout
<br>&gt; reflection, so I have a few questions:
<br>&gt; 1. Would the performance of a function call dispatch with a machin=
ery
<br>&gt; involving reflection be comparable to that of a call through a vta=
ble?
<br>
<br>The call of the interface/"virtual concept" function is virtual, the fo=
rwarding
<br>of that from the adapter is a non-virtual call that may or may not be i=
nlined
<br>depending on whether the function called is inline.<br></blockquote><di=
v><br></div><div>Are you not describing something similar to the concept/mo=
del approach outlined here (slide 24):&nbsp;<a href=3D"http://stlab.adobe.c=
om/wiki/images/c/c9/Boost_poly.pdf" style=3D"font-size: 13px; line-height: =
18px; text-indent: -0.25in;">http://stlab.adobe.com/wiki/images/c/c9/Boost_=
poly.pdf</a><span style=3D"font-size: 13px;">? I do realize that this mecha=
nism requires one virtual dispatch + one regular function call (in fact, th=
is is pretty much what my proposal boils down to for value semantics, excep=
t it's all done by the compiler), but I see no reflection involved. I am pa=
rticularly concerned with run-time reflection, but perhaps it's compile-tim=
e reflection you are talking about. If that's the case, sorry for the misun=
derstanding. Always assuming we're talking about compile-time reflection, d=
oes it mean that reflection would be used to generate the concept/model typ=
es?<br></span></div><div><span style=3D"font-size: 13px;">&nbsp;</span><br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; 2. Given "concept" =
(or whatever we call it) C such that "x.foo()" is valid
<br>&gt; when "x" is instance of a model of C, would your approach allow wr=
iting
<br>&gt; something like this?
<br>&gt;
<br>&gt; X x;
<br>&gt; C* c =3D &amp;x;
<br>&gt; c-&gt;foo();
<br>&gt; assert(&amp;c =3D=3D &amp;x);
<br>&gt; C c =3D x;
<br>&gt; c.foo();
<br>
<br>Probably not. You would need to do something like
<br>X x;
<br>CWrap&lt;X&gt; cwx{x};
<br>C* c =3D &amp;cwx;
<br>c-&gt;foo();
<br>// the assertion for address equality would be false
<br>C&amp; c2 =3D cwx;
<br>c.foo();
<br></blockquote><div><br>OK, so it seems to me (no arrogance intended) tha=
t the solution based on reflection is not as powerful as the mechanism I am=
 proposing, nor as natural/easy to use.<br>&nbsp;</div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;">&gt; 3. Is the "adaptation" you write about someth=
ing that could be written "once
<br>&gt; and for all" and made part of the standard library (provided we ha=
ve
<br>&gt; reflection, of course), or is the user supposed to code it for the=
ir own
<br>&gt; types/concepts? Would it require fiddling with templates and/or ma=
cros?
<br>
<br>We don't have a facility for generating overrides for the
<br>interface/virtual-concept
<br>functions, so we can't make an adapter fully generic. You don't need an=
y
<br>macros, and you don't have to use templates if you don't want to, but m=
aking
<br>such adapters more generic will benefit from templates. So, unless refl=
ection
<br>gains the capability of being able to generate overrides for base
<br>class functions,
<br>you would have to adapt your own types. Reflection helps with the adapt=
ation
<br>and can make it more generic when combined with templates, but at least=
 in
<br>its proposed form it can't make it fully generic/automatic.&nbsp;<br></=
blockquote><div>&nbsp;<br>Same observation as above: this requires the user=
 to write some boilerplate code. I can imagine the burden could be reduced =
by extracting a generic part of this boilerplate code into some template fa=
cility, but this affects both readability/maintainability and build times. =
One of the design goals for my proposal is to have build times comparable t=
o those that interface-based polymorphism offers. Isn't this approach going=
 to make build times rather comparable with those of using a library soluti=
on like Boost.TypeErasure?<br><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;">&gt; 4. Do we have a proposal for reflection? The one I have seen=
 one some time
<br>&gt; ago (<a href=3D"http://www.open-std.org/JTC1/SC22/WG21/docs/papers=
/2014/n3951.pdf" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.g=
oogle.com/url?q\75http%3A%2F%2Fwww.open-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs=
%2Fpapers%2F2014%2Fn3951.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNEFODzSx9pkR=
C933Npl4_8XIXF9Zg';return true;" onclick=3D"this.href=3D'http://www.google.=
com/url?q\75http%3A%2F%2Fwww.open-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpap=
ers%2F2014%2Fn3951.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNEFODzSx9pkRC933Np=
l4_8XIXF9Zg';return true;">http://www.open-std.org/JTC1/<wbr>SC22/WG21/docs=
/papers/2014/<wbr>n3951.pdf</a>) did
<br>&gt; not seem very mature to me.
<br>
<br>See
<br><a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4113.pd=
f" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?=
q\75http%3A%2F%2Fopen-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2014%2=
Fn4113.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNEM0iueHDjNNfJ-xavn7POXisoTAA'=
;return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3=
A%2F%2Fopen-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2014%2Fn4113.pdf=
\46sa\75D\46sntz\0751\46usg\75AFQjCNEM0iueHDjNNfJ-xavn7POXisoTAA';return tr=
ue;">http://open-std.org/JTC1/SC22/<wbr>WG21/docs/papers/2014/n4113.<wbr>pd=
f</a>
<br></blockquote><div><br>Thank you,<br><br>Andy&nbsp;</div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_346_1728684418.1411932711420--

.

On 28 September 2014 22:31, Andy Prowl <andy.prowl@gmail.com> wrote:
> Are you not describing something similar to the concept/model approach
> outlined here (slide 24):
> http://stlab.adobe.com/wiki/images/c/c9/Boost_poly.pdf? I do realize that
> this mechanism requires one virtual dispatch + one regular function call (in
> fact, this is pretty much what my proposal boils down to for value
> semantics, except it's all done by the compiler), but I see no reflection
> involved. I am particularly concerned with run-time reflection, but perhaps

Correct, as things are now, there's no reflection involved. Chances are that
reflection will cut down on the boilerplate necessary and make things more
general.

> it's compile-time reflection you are talking about. If that's the case,

Compile-time, completely.

> OK, so it seems to me (no arrogance intended) that the solution based on
> reflection is not as powerful as the mechanism I am proposing, nor as
> natural/easy to use.

The example I showed can be written today, without reflection. It's not
as powerful as your proposal, but it's nowhere close as intrusive - it
needs no additions to the language at all. Yet it covers most of the
cases such "runtime concepts" are after, which are mostly post-hoc
adaptation of existing classes into new interfaces.

> Same observation as above: this requires the user to write some boilerplate
> code. I can imagine the burden could be reduced by extracting a generic part

Sure, but even your proposal is not free of boilerplate.

--

---
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_528_145108944.1411938879301
Content-Type: text/plain; charset=UTF-8

Thank you for your comments Ville.

You're right, my proposal is "intrusive" in the sense that it requires
additions to the language, and the example you refer to can be written
today with libraries like Adobe.Poly or Boost.TypeErasure; on the other
hand, those libraries are not really easy to use, lead to higher build
times due to the template machinery, and are not as powerful as the
mechanism I am proposing.

Adobe.Poly is (AFAICT) only concerned with value semantics and not very
well-documented, whereas Boost.TypeErasure only supports duck-typing. There
is also Pyry Jahkola's Poly (https://github.com/pyrtsa/poly), which looks
good, but as the author writes, it is "a proof-of-concept, probably too
early or fragile for production use yet.".

Unless I'm overlooking something, my proposal does not suffer from these
limitations, it provides a *simple* way for users to define their own
concepts, generalizing things like std::function and std::any in a uniform
and efficient way, and it draws a nice parallel with compile-time concepts.
This is in principle a simple thing: we should have tools that make it
simple.

As a final remark, I have troubles understanding your statement that "[my]
proposal is not free of boilerplate": I think it is. The user has to
provide only minimal information in order to define virtual concepts and
their instantiations, and doesn't need to make use of anything like
"concept_ptr<C>", "poly::self", "type_erasure::self", "wrap<C>", etc. No
need to write adapters and wrappers either, no need to deal with templates,
and (quite importantly) no need to deal with obscure compiler errors when
they do something wrong.

Kind regards,

Andy



On Sunday, September 28, 2014 10:13:02 PM UTC+2, Ville Voutilainen wrote:
>
> On 28 September 2014 22:31, Andy Prowl <andy....@gmail.com <javascript:>>
> wrote:
> > Are you not describing something similar to the concept/model approach
> > outlined here (slide 24):
> > http://stlab.adobe.com/wiki/images/c/c9/Boost_poly.pdf? I do realize
> that
> > this mechanism requires one virtual dispatch + one regular function call
> (in
> > fact, this is pretty much what my proposal boils down to for value
> > semantics, except it's all done by the compiler), but I see no
> reflection
> > involved. I am particularly concerned with run-time reflection, but
> perhaps
>
> Correct, as things are now, there's no reflection involved. Chances are
> that
> reflection will cut down on the boilerplate necessary and make things more
> general.
>
> > it's compile-time reflection you are talking about. If that's the case,
>
> Compile-time, completely.
>
> > OK, so it seems to me (no arrogance intended) that the solution based on
> > reflection is not as powerful as the mechanism I am proposing, nor as
> > natural/easy to use.
>
> The example I showed can be written today, without reflection. It's not
> as powerful as your proposal, but it's nowhere close as intrusive - it
> needs no additions to the language at all. Yet it covers most of the
> cases such "runtime concepts" are after, which are mostly post-hoc
> adaptation of existing classes into new interfaces.
>
> > Same observation as above: this requires the user to write some
> boilerplate
> > code. I can imagine the burden could be reduced by extracting a generic
> part
>
> Sure, but even your proposal is not free of boilerplate.
>

--

---
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_528_145108944.1411938879301
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thank you for your comments Ville.<br><br>You're right, my=
 proposal is "intrusive" in the sense that it requires additions to the lan=
guage, and the example you refer to can be written today with libraries lik=
e Adobe.Poly or Boost.TypeErasure; on the other hand, those libraries are n=
ot really easy to use, lead to higher build times due to the template machi=
nery, and are not as powerful as the mechanism I am proposing. <br><br>Adob=
e.Poly is (AFAICT) only concerned with value semantics and not very well-do=
cumented, whereas Boost.TypeErasure only supports duck-typing. There is als=
o Pyry Jahkola's Poly (<a href=3D"https://github.com/pyrtsa/poly">https://g=
ithub.com/pyrtsa/poly</a>), which looks good, but as the author writes, it =
is "a proof-of-concept, probably too early or fragile for production use ye=
t.".<br><br>Unless I'm overlooking something, my proposal does not suffer f=
rom these limitations, it provides a *simple* way for users to define their=
 own concepts, generalizing things like std::function and std::any in a uni=
form and efficient way, and it draws a nice parallel with compile-time conc=
epts. This is in principle a simple thing: we should have tools that make i=
t simple.<br><br>As a final remark, I have troubles understanding your stat=
ement that "[my] proposal is not free of boilerplate": I think it is. The u=
ser has to provide only minimal information in order to define virtual conc=
epts and their instantiations, and doesn't need to make use of anything lik=
e "concept_ptr&lt;C&gt;", "poly::self", "type_erasure::self",&nbsp;<span st=
yle=3D"font-size: 13.3333330154419px;">"wrap&lt;C&gt;", etc. No need to wri=
te adapters and wrappers either</span>, no need to deal with templates, and=
 (quite importantly) no need to deal with obscure compiler errors when they=
 do something wrong.<br><br>Kind regards,<br><br>Andy<br><br><br><br>On Sun=
day, September 28, 2014 10:13:02 PM UTC+2, Ville Voutilainen wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;">On 28 September 2014 22:31, Andy Prowl=
 &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"v1X=
-OhafJ40J" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;">andy....@gmail.com</a>&gt; wrot=
e:
<br>&gt; Are you not describing something similar to the concept/model appr=
oach
<br>&gt; outlined here (slide 24):
<br>&gt; <a href=3D"http://stlab.adobe.com/wiki/images/c/c9/Boost_poly.pdf"=
 target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?q\=
75http%3A%2F%2Fstlab.adobe.com%2Fwiki%2Fimages%2Fc%2Fc9%2FBoost_poly.pdf\46=
sa\75D\46sntz\0751\46usg\75AFQjCNERHA_dyRTjHisvsZQ8yPUwFoSARw';return true;=
" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fstlab.=
adobe.com%2Fwiki%2Fimages%2Fc%2Fc9%2FBoost_poly.pdf\46sa\75D\46sntz\0751\46=
usg\75AFQjCNERHA_dyRTjHisvsZQ8yPUwFoSARw';return true;">http://stlab.adobe.=
com/wiki/<wbr>images/c/c9/Boost_poly.pdf</a>? I do realize that
<br>&gt; this mechanism requires one virtual dispatch + one regular functio=
n call (in
<br>&gt; fact, this is pretty much what my proposal boils down to for value
<br>&gt; semantics, except it's all done by the compiler), but I see no ref=
lection
<br>&gt; involved. I am particularly concerned with run-time reflection, bu=
t perhaps
<br>
<br>Correct, as things are now, there's no reflection involved. Chances are=
 that
<br>reflection will cut down on the boilerplate necessary and make things m=
ore
<br>general.
<br>
<br>&gt; it's compile-time reflection you are talking about. If that's the =
case,
<br>
<br>Compile-time, completely.
<br>
<br>&gt; OK, so it seems to me (no arrogance intended) that the solution ba=
sed on
<br>&gt; reflection is not as powerful as the mechanism I am proposing, nor=
 as
<br>&gt; natural/easy to use.
<br>
<br>The example I showed can be written today, without reflection. It's not
<br>as powerful as your proposal, but it's nowhere close as intrusive - it
<br>needs no additions to the language at all. Yet it covers most of the
<br>cases such "runtime concepts" are after, which are mostly post-hoc
<br>adaptation of existing classes into new interfaces.
<br>
<br>&gt; Same observation as above: this requires the user to write some bo=
ilerplate
<br>&gt; code. I can imagine the burden could be reduced by extracting a ge=
neric part
<br>
<br>Sure, but even your proposal is not free of boilerplate.
<br></blockquote></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_528_145108944.1411938879301--

.

------=_Part_2390_1561362703.1411939120031
Content-Type: text/plain; charset=UTF-8

@Vicente:

As a further element in favor of adopting the name "concept", I found two
references about "runtime concept" (pretty much the same idea).

One is a wiki page from Adobe:
http://stlab.adobe.com/wiki/index.php/Runtime_Concepts.

The other one is a paper by Bjarne Stroustrup, Sean Parent, and others:
http://www.stroustrup.com/oops08.pdf.

Kind regards,

Andy

--

---
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_2390_1561362703.1411939120031
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">@Vicente:<div><br></div><div>As a further element in favor=
 of adopting the name "concept", I found two references about "runtime conc=
ept" (pretty much the same idea).&nbsp;</div><div><br></div><div>One is a w=
iki page from Adobe:&nbsp;<a href=3D"http://stlab.adobe.com/wiki/index.php/=
Runtime_Concepts">http://stlab.adobe.com/wiki/index.php/Runtime_Concepts</a=
>.<br></div><div><br></div><div>The other one is a paper by Bjarne Stroustr=
up, Sean Parent, and others:&nbsp;<a href=3D"http://www.stroustrup.com/oops=
08.pdf">http://www.stroustrup.com/oops08.pdf</a>.</div><div><br></div><div>=
Kind regards,<br><br>Andy</div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_2390_1561362703.1411939120031--

.

On 29 September 2014 00:14, Andy Prowl <andy.prowl@gmail.com> wrote:
> Thank you for your comments Ville.
>
> You're right, my proposal is "intrusive" in the sense that it requires
> additions to the language, and the example you refer to can be written today
> with libraries like Adobe.Poly or Boost.TypeErasure; on the other hand,
> those libraries are not really easy to use, lead to higher build times due
> to the template machinery, and are not as powerful as the mechanism I am
> proposing.

The proposal might end up being more intrusive than just requiring a language
change; see the very end of this email.

> Adobe.Poly is (AFAICT) only concerned with value semantics and not very
> well-documented, whereas Boost.TypeErasure only supports duck-typing. There
> is also Pyry Jahkola's Poly (https://github.com/pyrtsa/poly), which looks
> good, but as the author writes, it is "a proof-of-concept, probably too
> early or fragile for production use yet.".
> Unless I'm overlooking something, my proposal does not suffer from these
> limitations, it provides a *simple* way for users to define their own
> concepts, generalizing things like std::function and std::any in a uniform
> and efficient way, and it draws a nice parallel with compile-time concepts.
> This is in principle a simple thing: we should have tools that make it
> simple.

No disagreement there - _as long as_ we are adding such tools for cases that
are commonly needed. I'm not sure whether run-time concepts of any kind are
so common. Note that there's nothing more to it - I'm not sure. I'm neither for
or against them, strongly, I'm just not sure. ;)

> As a final remark, I have troubles understanding your statement that "[my]
> proposal is not free of boilerplate": I think it is. The user has to provide
> only minimal information in order to define virtual concepts and their
> instantiations, and doesn't need to make use of anything like
> "concept_ptr<C>", "poly::self", "type_erasure::self", "wrap<C>", etc. No
> need to write adapters and wrappers either, no need to deal with templates,
> and (quite importantly) no need to deal with obscure compiler errors when
> they do something wrong.

The boilerplate comes in when I want to turn existing base classes that act
as abstract interfaces into these new virtual concepts. I have a
plethora of them,
and they are the things I want new classes to adapt to, somehow. So.. now I go
and turn them into virtual concepts. I have now modified the very fundamental
headers of many of my systems, and this causes a rebuild of "the
world". Furthermore,
these fundamental classes still need to work with pre-c++17 code, so I need
to macro them to be either the classes they used to be or virtual concepts.

*That* is very intrusive. With the current approaches, however less
powerful they may
be, I do not have to modify the base class at all, nor do I have to
modify the target
class, at all. All I need to write is external adaptation code. I
would much prefer a
solution that provides easy post-hoc adaptation while keeping the
adaptees intact,
without requiring intrusive modification to them.

--

---
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_2609_2020781838.1411945273038
Content-Type: text/plain; charset=UTF-8

OK, I think I need to put this in more concrete terms in order to
understand your last example - please bear with me and forgive me if it's
going to be a bit lengthy. Say we have an abstract interface IFoo and
classes A and B which implement it:

class IFoo
{
public:
    virtual ~I() = default;
    virtual void foo() = 0;
};

class A : public IFoo
{
    virtual void foo() override { /* ... whatever ... */ }
    void bar() { /* ... something else ... */ }
};

class B : public IFoo
{
    virtual void foo() override { /* ... whatever ... */ }
    void bar() { /* ... something else ... */ }
};

And a polymorphic algorithm that works with objects of type IFoo:

void poly_foo(IFoo& obj)
{
    obj.foo();
}

Now say we want to write another polymorphic algorithm, poly_bar(), that
needs to call bar() on its argument, and its argument may be an A or a B.
We have a few options, but let's assume we decide to use virtual concepts.
All we have to do is (1) define a new concept (say, "BarConcept"), (2)
provide an instantiation of BarConcept for A and one for B, possibly using
"= default" to minimize the work and enable duck-typing, and (3) let our
new poly_bar() algorithm take a BarConcept&:

template<typename T>
virtual concept bool BarConcept()
{
    return requires(T obj)
    {
        { bar(); } -> void;
    };
}

virtual concept map BarConcept<A> = default;

virtual concept map BarConcept<B> = default;

void poly_bar(BarConcept& obj)
{
    obj.bar();
}

No need to touch or recompile any of the existing code so far.

Now of course if we wanted to modify our *existing* algorithm poly_foo() to
work with concepts rather than with an abstract interface, then we will
have to modify poly_foo() and recompile its clients.

Similarly, if we wanted to *turn* our existing IFoo into a virtual concept,
we would have to modify IFoo as well as A and B and recompile all of their
clients, but I do not see how any of the library solutions we've been
referring to so far will help with that in general. Am I missing something?

Thank you,

Andy

--

---
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_2609_2020781838.1411945273038
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>OK, I think I need to put this in more concrete terms=
 in order to understand your last example - please bear with me and forgive=
 me if it's going to be a bit lengthy.&nbsp;<span style=3D"font-size: 13px;=
">Say we have an abstract interface IFoo and classes A and B which implemen=
t it:</span></div><div><br></div><div class=3D"prettyprint" style=3D"border=
: 1px solid rgb(187, 187, 187); word-wrap: break-word; background-color: rg=
b(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"subprettyprint=
"><span style=3D"color: #008;" class=3D"styled-by-prettify">class</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">IFoo</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">public</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br>&nbsp; &nbsp; </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">virtual</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">~</span><span style=3D"color: #000;" class=3D"styled-by-prettify">I</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">default</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">virtual</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">void</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> foo</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #066;" class=3D"styled-by-prettify">0</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">};</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br><br></span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">class</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> A </span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">public</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #606;" class=3D"styled-by-prettify">IFoo</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">virtual</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">void</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> foo</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">override</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800=
;" class=3D"styled-by-prettify">/* ... whatever ... */</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> bar</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #800;" class=3D"styled-by-prettify">/* ... some=
thing else ... */</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">}<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">};</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">class</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> B </span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">public</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prett=
ify">IFoo</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp=
; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">virtual<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">void</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> foo</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">()</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">override</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">/* =
.... whatever ... */</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp=
; &nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">v=
oid</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> bar</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" =
class=3D"styled-by-prettify">/* ... something else ... */</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">};</span></div></code></div><div><br></div><div>And=
 a polymorphic algorithm that works with objects of type IFoo:</div><div><b=
r></div><div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187,=
 187); word-wrap: break-word; background-color: rgb(250, 250, 250);"><code =
class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #=
008;" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> poly_foo</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">(</span><span style=3D"color: #606;" class=3D"s=
tyled-by-prettify">IFoo</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">&amp;</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> obj</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; obj<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">foo</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">();</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">}</span></div></code></div><div><br></di=
v><div>Now say we want to write another polymorphic algorithm, poly_bar(), =
that needs to call bar() on its argument, and its argument may be an A or a=
 B. We have a few options, but let's assume we <span style=3D"font-size: 13=
px;">decide to use virtual concepts. All we have to do is (1) define a new =
concept (say, "BarConcept"), (2) provide an instantiation of BarConcept for=
 A and one for B, possibly using "=3D default" to minimize the work and ena=
ble duck-typing, and (3) let our new poly_bar() algorithm take a BarConcept=
&amp;:</span></div><div><br></div><div class=3D"prettyprint" style=3D"borde=
r: 1px solid rgb(187, 187, 187); word-wrap: break-word; background-color: r=
gb(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"subprettyprin=
t"><span style=3D"color: #008;" class=3D"styled-by-prettify">template</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">typename</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">virtual</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">concept</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">bool</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">BarConce=
pt</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">return</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> requires</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">T obj</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> bar</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">();</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">-&=
gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">};</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">virtual</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">concept</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> map </span><span style=3D"color: #606;" class=3D"styled-by-pre=
ttify">BarConcept</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>A</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">default</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">virtual</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">concept</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> map </span><span style=3D"color: #606;" class=3D"styled-by-pretti=
fy">BarConcept</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">B<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">default</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br><br></span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">void</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> poly_bar</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">(</span><span style=3D"color: #606;" class=3D"styled-by-prettif=
y">BarConcept</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> o=
bj</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; obj</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">bar</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">();</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br></span></div></code></div><div><br><span style=3D"fon=
t-size: 13px;">No need to touch or recompile any of the existing code so fa=
r.<br></span><span style=3D"font-size: 13px;"><br>Now of course if we wante=
d to modify our *existing* algorithm poly_foo() to work with concepts rathe=
r than with an abstract interface, then we will have to modify poly_foo() a=
nd recompile its clients.<br><br>Similarly, if we wanted to *turn* our exis=
ting IFoo into a virtual concept, we would have to modify IFoo as well as A=
 and B and recompile all of their clients, but I do not see how any&nbsp;</=
span><span style=3D"font-size: 13px;">of the library solutions we've been r=
eferring to so far will help with that in general. Am I missing&nbsp;someth=
ing?<br><br></span></div><div>Thank you,</div><div><br></div><div>Andy</div=
></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_2609_2020781838.1411945273038--

.

------=_Part_2773_1773800132.1411980146371
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



W dniu czwartek, 25 wrze=C5=9Bnia 2014 21:40:15 UTC+2 u=C5=BCytkownik Andy =
Prowl=20
napisa=C5=82:
>
> Hello everyone,
>
> I would like to ask for feedback concerning this idea I had about=20
> non-intrusive "dynamic" polymorphism:
>
>
> https://www.dropbox.com/s/tg737sf8sj1p1ht/Virtual%20concepts%20for%20poly=
morphic%20types.pdf?dl=3D1
>
> This is just a rough sketch, please do not expect any full-blown proposal=
..=20
> My goal is to find out whether it makes sense to invest more time on it, =
or=20
> if the idea is basically bull***t.
>
> A few highlights:
>
> 1. The idea is about introducing non-intrusive support for dynamic=20
> polymorphism (similar to Haskell's typeclasses);
> 2. The idea is similar to the old C++0x "concept maps", but is *not*=20
> related to templates;
> 3. Code using a "virtual concept" can be compiled separately and does not=
=20
> need to see the definition of the instances of that concept.
>

Hi Andy,
The field of  your investigation is sure interesting and useful. This sort=
=20
of thing is definitely needed. Even if it can be acheived by other means,=
=20
adding a dedicated feature into the language might encourage people to use=
=20
it.  I am not convinced if concept maps are that useful. What is the=20
difference between defining a concept map and defining a "wrapper" class?=
=20
Also, it looks from your paper that the binding of a type to a virtual=20
concept does not work unless I explicitly declare it with a (possibly=20
defaulted) concept map. Am I right? This would be a big inconvenience. This=
=20
is what the original concepts were criticized for.

Also, inside the concept maps, how the visibility of names work? I mean,=20
does normal ADL work? Which namespaces are accessible? Can I call other=20
static member functions unqualified. Can I see fiunctions in the enclosing=
=20
namespace scope?

The paper lists the following definition

template<typename T> virtual concept bool C() { return requires(T x) {
 { x.foo(C& obj) } -> void;
}; }

Should it not read:

template<typename T> virtual concept bool C() { return requires(T x) {
 { x.foo(obj) } -> void;
}; }

ALso, the examples only talk about member functions. In contrast, both=20
Concepts Lite and other type erasure libraries allow to define the=20
interface in terms of non-member functions:

requires(T v, T w)
{
  { transform(v) } -> T;
  { cmp(v, w) } -> bool;
}

Do you intend the above to be expressible with virtual concepts?

Regards,
&rzej

--=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_2773_1773800132.1411980146371
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>W dniu czwartek, 25 wrze=C5=9Bnia 2014 21:40:15 UT=
C+2 u=C5=BCytkownik Andy Prowl napisa=C5=82:<blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr">Hello everyone,<br><br>I would like to ask f=
or feedback concerning this idea I had about non-intrusive "dynamic" polymo=
rphism:<br><br><a href=3D"https://www.dropbox.com/s/tg737sf8sj1p1ht/Virtual=
%20concepts%20for%20polymorphic%20types.pdf?dl=3D1" target=3D"_blank" onmou=
sedown=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%2Fwww.dro=
pbox.com%2Fs%2Ftg737sf8sj1p1ht%2FVirtual%2520concepts%2520for%2520polymorph=
ic%2520types.pdf%3Fdl%3D1\46sa\75D\46sntz\0751\46usg\75AFQjCNGymd7sW1a8uMwg=
4zizweWQSkl-xg';return true;" onclick=3D"this.href=3D'https://www.google.co=
m/url?q\75https%3A%2F%2Fwww.dropbox.com%2Fs%2Ftg737sf8sj1p1ht%2FVirtual%252=
0concepts%2520for%2520polymorphic%2520types.pdf%3Fdl%3D1\46sa\75D\46sntz\07=
51\46usg\75AFQjCNGymd7sW1a8uMwg4zizweWQSkl-xg';return true;">https://www.dr=
opbox.com/s/<wbr>tg737sf8sj1p1ht/Virtual%<wbr>20concepts%20for%<wbr>20polym=
orphic%20types.pdf?dl=3D1</a><br><br>This is just a rough sketch, please do=
 not expect any full-blown proposal. My goal is to find out whether it make=
s sense to invest more time on it, or if the idea is basically bull***t.<br=
><br>A few highlights:<br><br>1. The idea is about introducing non-intrusiv=
e support for dynamic polymorphism (similar to Haskell's typeclasses);<br>2=
.. The idea is similar to the old C++0x "concept maps", but is *not* related=
 to templates;<br>3. Code using a "virtual concept" can be compiled separat=
ely and does not need to see the definition of the instances of that concep=
t.<br></div></blockquote><div><br>Hi Andy,<br>The field of&nbsp; your inves=
tigation is sure interesting and useful. This sort of thing is definitely n=
eeded. Even if it can be acheived by other means, adding a dedicated featur=
e into the language might encourage people to use it.&nbsp; I am not convin=
ced if concept maps are that useful. What is the difference between definin=
g a concept map and defining a "wrapper" class? Also, it looks from your pa=
per that the binding of a type to a virtual concept does not work unless I =
explicitly declare it with a (possibly defaulted) concept map. Am I right? =
This would be a big inconvenience. This is what the original concepts were =
criticized for.<br><br>Also, inside the concept maps, how the visibility of=
 names work? I mean, does normal ADL work? Which namespaces are accessible?=
 Can I call other static member functions unqualified. Can I see fiunctions=
 in the enclosing namespace scope?<br><br>The paper lists the following def=
inition<br><br>template&lt;typename T&gt; virtual concept bool C() { return=
 requires(T x) {<br>&nbsp;{ x.foo(C&amp; obj) } -&gt; void;<br>}; }<br><br>=
Should it not read:<br><br>template&lt;typename T&gt; virtual concept bool =
C() { return requires(T x) {<br>&nbsp;{ x.foo(obj) } -&gt; void;<br>}; }<br=
><br>ALso, the examples only talk about member functions. In contrast, both=
 Concepts Lite and other type erasure libraries allow to define the interfa=
ce in terms of non-member functions:<br><br>requires(T v, T w)<br>{<br>&nbs=
p; { transform(v) } -&gt; T;<br>&nbsp; { cmp(v, w) } -&gt; bool;<br>}<br><b=
r>Do you intend the above to be expressible with virtual concepts?<br><br>R=
egards,<br>&amp;rzej<br></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_2773_1773800132.1411980146371--

.

------=_Part_209_1177924202.1411984110828
Content-Type: text/plain; charset=UTF-8

Hi Andrzej,

Thank you for sharing your thoughts. This idea I'm working on is in a very
preliminary state, and many things are still unclear to me - although I am
convinced that we should have language support for making type erasure
technically simple(r). The draft probably contains gross mistakes - like
the one you spotted with "x.foo(C& c)", thank you for that - and/or other
kinds of imprecision.

For instance, today I realized that the "requires-expression" I adopted for
concept definitions won't work for run-time concepts, because the
definitions of the satisfying types may not be visible at compile-time at
the point where a concept is used, and therefore the dispatch mechanism
requires knowing the exact signature of the concept's functions. So I made
a step back and defined concepts as a list of (member) functions to be
supported (the latest version is available here: http://bit.ly/ZgruFY).

Concerning free functions, yes I would definitely like to add support for
them, but I haven't thought through this use case deep enough, and it is
not clear to me at the moment how to implement them (I'm particularly
scared by possible interplay with stuff like multi-methods, but I'm just
hand-waving here). I would like to add support for data members too, but
I'm not sure whether that's possible either.

Regarding ADL, I would say inside a concept map ADL should work just as it
does outside of it, but I am aware that ADL is an extremely tricky topic,
and its details keeps surprising me times and times again. So for the
moment I'm making the arguably childish decision of ignoring those details
and see how far I can get :)

Finally, I think concept maps can be either desirable or annoying depending
on the use case. Duck-typing is definitely feasible and could be supported
by decorating the concept definition with a [[ducktype]] attribute, or by
any other means. That would make it unnecessary to define concept maps, and
the modeling relation between a type and a concept would be inferred by
syntactic matching of function signatures.

On the other hand, concept maps (like Haskell's type classes) allow for
more flexibility: you can freely design your types without caring about
syntactic requirements imposed by polymorphic algorithms (both the existing
ones and the ones yet to come), since you can provide adaptation when
needed. The difference between a concept map and an adapter class mostly
comes into play when using reference semantics. Say I have a concept C and
a type X that models it. My idea is to allow this:

X x;
C& c = x;
assert(addressof(c) == addressof(x));

The presence of an adapter class would make the assertion above fail, while
it would succeed with concept maps (thanks to compiler magic). Some have
commented that this is not a fundamental feature, and that might be true.
But even without it, it seems to me that concept maps reduce the amount of
boilerplate (especially template) code that users would have to write, and
improve readability.

Kind regards,

Andy

--

---
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_209_1177924202.1411984110828
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Andrzej,&nbsp;<br><br>Thank you for sharing your though=
ts.&nbsp;This idea I'm working on is in a very preliminary state, and many =
things are still unclear to me - although I am convinced that we should hav=
e language support for making type erasure technically simple(r). The draft=
 probably contains gross mistakes - like the one you spotted with "x.foo(C&=
amp; c)", thank you for that - and/or other kinds of imprecision.<br><br>Fo=
r instance, today I realized that the "requires-expression" I adopted for c=
oncept definitions won't work for run-time concepts, because the definition=
s of the satisfying types may not be visible at compile-time at the point w=
here a concept is used, and therefore the dispatch mechanism requires knowi=
ng the exact signature of the concept's functions. So I made a step back an=
d defined concepts as a list of (member) functions to be supported (the lat=
est version is available here: <a href=3D"http://bit.ly/ZgruFY">http://bit.=
ly/ZgruFY</a>).<br><br>Concerning free functions, yes I would definitely li=
ke to add support for them, but I haven't thought through this use case dee=
p enough, and it is not clear to me at the moment how to implement them (I'=
m particularly scared by possible interplay with stuff like multi-methods, =
but I'm just hand-waving here). I would like to add support for data member=
s too, but I'm not sure whether that's possible either.<br><br>Regarding AD=
L, I would say inside a concept map ADL should work just as it does outside=
 of it, but I am aware that ADL is an extremely tricky topic, and its detai=
ls keeps surprising me times and times again. So for the moment I'm making =
the arguably childish decision of ignoring those details and see how far I =
can get :)<br><br>Finally, I think concept maps can be either desirable or =
annoying depending on the use case. Duck-typing is definitely feasible and =
could be supported by decorating the concept definition with a [[ducktype]]=
 attribute, or by any other means. That would make it unnecessary to define=
 concept maps, and the modeling relation between a type and a concept would=
 be inferred by syntactic matching of function signatures.<br><br>On the ot=
her hand, concept maps (like Haskell's type classes) allow for more flexibi=
lity: you can freely design your types without caring about syntactic requi=
rements imposed by polymorphic algorithms (both the existing ones and the o=
nes yet to come), since you can provide adaptation when needed. The differe=
nce between a concept map and an adapter class mostly comes into play when =
using reference semantics. Say I have a concept C and a type X that models =
it. My idea is to allow this:<br><br><div class=3D"prettyprint" style=3D"bo=
rder: 1px solid rgb(187, 187, 187); word-wrap: break-word; background-color=
: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"subprettyp=
rint"><font color=3D"#000000"><span style=3D"color: #000;" class=3D"styled-=
by-prettify">X</span></font><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> x</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>C<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> c </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> x</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">assert</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">addressof</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>c</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span>=
<font color=3D"#666600"><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> add=
ressof</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">x</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">));</span></font></div=
></code></div><br>The presence of an adapter class would make the&nbsp;<spa=
n style=3D"font-size: 13.3333330154419px;">assertion&nbsp;</span>above fail=
, while it would succeed with concept maps (thanks to compiler magic). Some=
 have commented that this is not a fundamental feature, and that might be t=
rue. But even without it, it seems to me that concept maps reduce the amoun=
t of boilerplate (especially template)&nbsp;code that users would have to w=
rite, and improve readability.<br><br>Kind regards,<br><br>Andy</div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_209_1177924202.1411984110828--

.

Le 28/09/14 23:14, Andy Prowl a =C3=A9crit :
> Thank you for your comments Ville.
>
> You're right, my proposal is "intrusive" in the sense that it requires=20
> additions to the language, and the example you refer to can be written=20
> today with libraries like Adobe.Poly or Boost.TypeErasure; on the=20
> other hand, those libraries are not really easy to use, lead to higher=20
> build times due to the template machinery, and are not as powerful as=20
> the mechanism I am proposing.
What do you find complex to use with Adobe.Poly?
>
> Adobe.Poly is (AFAICT) only concerned with value semantics and not=20
> very well-documented, whereas Boost.TypeErasure only supports=20
> duck-typing. There is also Pyry Jahkola's Poly=20
> (https://github.com/pyrtsa/poly), which looks good, but as the author=20
> writes, it is "a proof-of-concept, probably too early or fragile for=20
> production use yet.".
>
Well I'm sure that a Poly proposal will be welcome to the standard. It=20
is far easier to make a concrete proposal of a library than changing the=20
language.
> Unless I'm overlooking something, my proposal does not suffer from=20
> these limitations, it provides a *simple* way for users to define=20
> their own concepts, generalizing things like std::function and=20
> std::any in a uniform and efficient way, and it draws a nice parallel=20
> with compile-time concepts. This is in principle a simple thing: we=20
> should have tools that make it simple.
You proposal is far from been ready ;-). Usually languages proposals=20
have a probe of concept with a specific compiler in order to see if this=20
is doable and how this could improve the performances respect to a=20
library solution.

All this doesn't mean that I'm against the idea.

Vicente

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

.

This is a multi-part message in MIME format.
--------------080302050707030804080109
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 29/09/14 10:42, Andrzej Krzemie=C5=84ski a =C3=A9crit :
>
>
> W dniu czwartek, 25 wrze=C5=9Bnia 2014 21:40:15 UTC+2 u=C5=BCytkownik And=
y Prowl=20
> napisa=C5=82:
>
>     Hello everyone,
>
>     I would like to ask for feedback concerning this idea I had about
>     non-intrusive "dynamic" polymorphism:
>
>     https://www.dropbox.com/s/tg737sf8sj1p1ht/Virtual%20concepts%20for%20=
polymorphic%20types.pdf?dl=3D1
>     <https://www.dropbox.com/s/tg737sf8sj1p1ht/Virtual%20concepts%20for%2=
0polymorphic%20types.pdf?dl=3D1>
>
>     This is just a rough sketch, please do not expect any full-blown
>     proposal. My goal is to find out whether it makes sense to invest
>     more time on it, or if the idea is basically bull***t.
>
>     A few highlights:
>
>     1. The idea is about introducing non-intrusive support for dynamic
>     polymorphism (similar to Haskell's typeclasses);
>     2. The idea is similar to the old C++0x "concept maps", but is
>     *not* related to templates;
>     3. Code using a "virtual concept" can be compiled separately and
>     does not need to see the definition of the instances of that concept.
>
>
> Hi Andy,
> The field of  your investigation is sure interesting and useful. This=20
> sort of thing is definitely needed. Even if it can be acheived by=20
> other means, adding a dedicated feature into the language might=20
> encourage people to use it.  I am not convinced if concept maps are=20
> that useful. What is the difference between defining a concept map and=20
> defining a "wrapper" class?
I would say that this it is the same as between type traits and a=20
"wrapper" class.
> Also, it looks from your paper that the binding of a type to a virtual=20
> concept does not work unless I explicitly declare it with a (possibly=20
> defaulted) concept map. Am I right? This would be a big inconvenience.=20
> This is what the original concepts were criticized for.
>
I'm absolutely for an explicit mapping. This doesn't mean that you=20
couldn't say that given a type has a concept map for C1, a concept map=20
for C2 can not be implied.
> Also, inside the concept maps, how the visibility of names work? I=20
> mean, does normal ADL work? Which namespaces are accessible? Can I=20
> call other static member functions unqualified. Can I see fiunctions=20
> in the enclosing namespace scope?
These are all valid questions a proposal should answer.
>
>
> ALso, the examples only talk about member functions. In contrast, both=20
> Concepts Lite and other type erasure libraries allow to define the=20
> interface in terms of non-member functions:
>
> requires(T v, T w)
> {
>   { transform(v) } -> T;
>   { cmp(v, w) } -> bool;
> }
>
> Do you intend the above to be expressible with virtual concepts?
>
Very good question. I don't think the proposal could take care of=20
non-member functions in general, as the parameters of the non-member=20
function could concern several types.


Vicente

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

--------------080302050707030804080109
Content-Type: text/html; charset=UTF-8
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">Le 29/09/14 10:42, Andrzej Krzemie=C5=84=
ski
      a =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote
      cite=3D"mid:945c5eb7-0fa9-415e-a20d-4597719e0cb9@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr"><br>
        <br>
        W dniu czwartek, 25 wrze=C5=9Bnia 2014 21:40:15 UTC+2 u=C5=BCytkown=
ik Andy
        Prowl napisa=C5=82:
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
          <div dir=3D"ltr">Hello everyone,<br>
            <br>
            I would like to ask for feedback concerning this idea I had
            about non-intrusive "dynamic" polymorphism:<br>
            <br>
            <a moz-do-not-send=3D"true"
href=3D"https://www.dropbox.com/s/tg737sf8sj1p1ht/Virtual%20concepts%20for%=
20polymorphic%20types.pdf?dl=3D1"
              target=3D"_blank"
              onmousedown=3D"this.href=3D'https://www.google.com/url?q\75ht=
tps%3A%2F%2Fwww.dropbox.com%2Fs%2Ftg737sf8sj1p1ht%2FVirtual%2520concepts%25=
20for%2520polymorphic%2520types.pdf%3Fdl%3D1\46sa\75D\46sntz\0751\46usg\75A=
FQjCNGymd7sW1a8uMwg4zizweWQSkl-xg';return
              true;"
              onclick=3D"this.href=3D'https://www.google.com/url?q\75https%=
3A%2F%2Fwww.dropbox.com%2Fs%2Ftg737sf8sj1p1ht%2FVirtual%2520concepts%2520fo=
r%2520polymorphic%2520types.pdf%3Fdl%3D1\46sa\75D\46sntz\0751\46usg\75AFQjC=
NGymd7sW1a8uMwg4zizweWQSkl-xg';return
              true;">https://www.dropbox.com/s/<wbr>tg737sf8sj1p1ht/Virtual=
%<wbr>20concepts%20for%<wbr>20polymorphic%20types.pdf?dl=3D1</a><br>
            <br>
            This is just a rough sketch, please do not expect any
            full-blown proposal. My goal is to find out whether it makes
            sense to invest more time on it, or if the idea is basically
            bull***t.<br>
            <br>
            A few highlights:<br>
            <br>
            1. The idea is about introducing non-intrusive support for
            dynamic polymorphism (similar to Haskell's typeclasses);<br>
            2. The idea is similar to the old C++0x "concept maps", but
            is *not* related to templates;<br>
            3. Code using a "virtual concept" can be compiled separately
            and does not need to see the definition of the instances of
            that concept.<br>
          </div>
        </blockquote>
        <div><br>
          Hi Andy,<br>
          The field of=C2=A0 your investigation is sure interesting and
          useful. This sort of thing is definitely needed. Even if it
          can be acheived by other means, adding a dedicated feature
          into the language might encourage people to use it.=C2=A0 I am no=
t
          convinced if concept maps are that useful. What is the
          difference between defining a concept map and defining a
          "wrapper" class? </div>
      </div>
    </blockquote>
    I would say that this it is the same as between type traits and a
    "wrapper" class.<br>
    <blockquote
      cite=3D"mid:945c5eb7-0fa9-415e-a20d-4597719e0cb9@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>Also, it looks from your paper that the binding of a type
          to a virtual concept does not work unless I explicitly declare
          it with a (possibly defaulted) concept map. Am I right? This
          would be a big inconvenience. This is what the original
          concepts were criticized for.<br>
          <br>
        </div>
      </div>
    </blockquote>
    I'm absolutely for an explicit mapping. This doesn't mean that you
    couldn't say that given a type has a concept map for C1, a concept
    map for C2 can not be implied.<br>
    <blockquote
      cite=3D"mid:945c5eb7-0fa9-415e-a20d-4597719e0cb9@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>Also, inside the concept maps, how the visibility of names
          work? I mean, does normal ADL work? Which namespaces are
          accessible? Can I call other static member functions
          unqualified. Can I see fiunctions in the enclosing namespace
          scope?<br>
        </div>
      </div>
    </blockquote>
    These are all valid questions a proposal should answer.<br>
    <blockquote
      cite=3D"mid:945c5eb7-0fa9-415e-a20d-4597719e0cb9@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div><br>
          <br>
          ALso, the examples only talk about member functions. In
          contrast, both Concepts Lite and other type erasure libraries
          allow to define the interface in terms of non-member
          functions:<br>
          <br>
          requires(T v, T w)<br>
          {<br>
          =C2=A0 { transform(v) } -&gt; T;<br>
          =C2=A0 { cmp(v, w) } -&gt; bool;<br>
          }<br>
          <br>
          Do you intend the above to be expressible with virtual
          concepts?<br>
          <br>
        </div>
      </div>
    </blockquote>
    Very good question. I don't think the proposal could take care of
    non-member functions in general, as the parameters of the non-member
    function could concern several types.<br>
    <br>
    <br>
    Vicente<br>
  </body>
</html>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />

--------------080302050707030804080109--

.

------=_Part_1543_253707474.1412015042693
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Vicente,

You are right about my "proposal" being far from ready (in fact, I should=
=20
rather call it an "idea"). However, with time I would like to grow it into=
=20
a proposal, and I'm trying to collect useful comments, suggestions, and=20
criticism through this discussion - which is happening. That helps me=20
figuring out if it is worth investing some serious time on it.

You're also right about the necessity of backing up words with a prototype=
=20
implementation, which is in fact one of the first things I thought of, and=
=20
it is also the reason why I worried about possible implementation=20
techniques since the beginning. At the moment, I believe hacking Clang=20
would be the simplest way of coming up with a proof of principle.=20

What I find complex about Adobe.Poly (apart from finding a good=20
documentation and the latest version of the source code) is that (1) it=20
requires defining boilerplate adaptation code (e.g. the=20
PlaceableImplementation from the paper by Marcus, Jarvi, and Parent); (2)=
=20
the user needs to deal with templates, just like with Boost.TypeErasure;=20
(3) it does not allow for duck-typing (unless I'm missing something).

Kind regards,

Andy




On Monday, September 29, 2014 7:20:03 PM UTC+2, Vicente J. Botet Escriba=20
wrote:
>
> Le 28/09/14 23:14, Andy Prowl a =C3=A9crit :=20
> > Thank you for your comments Ville.=20
> >=20
> > You're right, my proposal is "intrusive" in the sense that it requires=
=20
> > additions to the language, and the example you refer to can be written=
=20
> > today with libraries like Adobe.Poly or Boost.TypeErasure; on the=20
> > other hand, those libraries are not really easy to use, lead to higher=
=20
> > build times due to the template machinery, and are not as powerful as=
=20
> > the mechanism I am proposing.=20
> What do you find complex to use with Adobe.Poly?=20
> >=20
> > Adobe.Poly is (AFAICT) only concerned with value semantics and not=20
> > very well-documented, whereas Boost.TypeErasure only supports=20
> > duck-typing. There is also Pyry Jahkola's Poly=20
> > (https://github.com/pyrtsa/poly), which looks good, but as the author=
=20
> > writes, it is "a proof-of-concept, probably too early or fragile for=20
> > production use yet.".=20
> >=20
> Well I'm sure that a Poly proposal will be welcome to the standard. It=20
> is far easier to make a concrete proposal of a library than changing the=
=20
> language.=20
> > Unless I'm overlooking something, my proposal does not suffer from=20
> > these limitations, it provides a *simple* way for users to define=20
> > their own concepts, generalizing things like std::function and=20
> > std::any in a uniform and efficient way, and it draws a nice parallel=
=20
> > with compile-time concepts. This is in principle a simple thing: we=20
> > should have tools that make it simple.=20
> You proposal is far from been ready ;-). Usually languages proposals=20
> have a probe of concept with a specific compiler in order to see if this=
=20
> is doable and how this could improve the performances respect to a=20
> library solution.=20
>
> All this doesn't mean that I'm against the idea.=20
>
> Vicente=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_1543_253707474.1412015042693
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Vicente,<br><br>You are right about my "proposal" being fa=
r from ready (in fact, I should rather call it an "idea"). However, with ti=
me I would like to grow it into a proposal, and I'm trying to collect usefu=
l comments, suggestions, and criticism through this discussion - which is h=
appening. That helps me figuring out if it is worth investing some serious =
time on it.<br><br>You're also right about the necessity of backing up word=
s with a prototype implementation, which is in fact one of the first things=
 I thought of, and it is also the reason why I worried about possible imple=
mentation techniques since the beginning. At the moment, I believe hacking =
Clang would be the simplest way of coming up with a proof of principle.&nbs=
p;<br><br>What I find complex about Adobe.Poly (apart from finding a good d=
ocumentation and the latest version of the source code) is that (1) it requ=
ires defining boilerplate adaptation code (e.g. the PlaceableImplementation=
 from the paper by Marcus, Jarvi, and Parent); (2) the user needs to deal w=
ith templates, just like with Boost.TypeErasure; (3) it does not allow for =
duck-typing (unless I'm missing something).<br><br>Kind regards,<br><br>And=
y<br><br><br><br><br>On Monday, September 29, 2014 7:20:03 PM UTC+2, Vicent=
e J. Botet Escriba wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Le 28=
/09/14 23:14, Andy Prowl a =C3=A9crit :
<br>&gt; Thank you for your comments Ville.
<br>&gt;
<br>&gt; You're right, my proposal is "intrusive" in the sense that it requ=
ires=20
<br>&gt; additions to the language, and the example you refer to can be wri=
tten=20
<br>&gt; today with libraries like Adobe.Poly or Boost.TypeErasure; on the=
=20
<br>&gt; other hand, those libraries are not really easy to use, lead to hi=
gher=20
<br>&gt; build times due to the template machinery, and are not as powerful=
 as=20
<br>&gt; the mechanism I am proposing.
<br>What do you find complex to use with Adobe.Poly?
<br>&gt;
<br>&gt; Adobe.Poly is (AFAICT) only concerned with value semantics and not=
=20
<br>&gt; very well-documented, whereas Boost.TypeErasure only supports=20
<br>&gt; duck-typing. There is also Pyry Jahkola's Poly=20
<br>&gt; (<a href=3D"https://github.com/pyrtsa/poly" target=3D"_blank" onmo=
usedown=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%2Fgithub=
..com%2Fpyrtsa%2Fpoly\46sa\75D\46sntz\0751\46usg\75AFQjCNFKFy8IfzkXUM9YQ4EBJ=
IreGuUAWg';return true;" onclick=3D"this.href=3D'https://www.google.com/url=
?q\75https%3A%2F%2Fgithub.com%2Fpyrtsa%2Fpoly\46sa\75D\46sntz\0751\46usg\75=
AFQjCNFKFy8IfzkXUM9YQ4EBJIreGuUAWg';return true;">https://github.com/pyrtsa=
/<wbr>poly</a>), which looks good, but as the author=20
<br>&gt; writes, it is "a proof-of-concept, probably too early or fragile f=
or=20
<br>&gt; production use yet.".
<br>&gt;
<br>Well I'm sure that a Poly proposal will be welcome to the standard. It=
=20
<br>is far easier to make a concrete proposal of a library than changing th=
e=20
<br>language.
<br>&gt; Unless I'm overlooking something, my proposal does not suffer from=
=20
<br>&gt; these limitations, it provides a *simple* way for users to define=
=20
<br>&gt; their own concepts, generalizing things like std::function and=20
<br>&gt; std::any in a uniform and efficient way, and it draws a nice paral=
lel=20
<br>&gt; with compile-time concepts. This is in principle a simple thing: w=
e=20
<br>&gt; should have tools that make it simple.
<br>You proposal is far from been ready ;-). Usually languages proposals=20
<br>have a probe of concept with a specific compiler in order to see if thi=
s=20
<br>is doable and how this could improve the performances respect to a=20
<br>library solution.
<br>
<br>All this doesn't mean that I'm against the idea.
<br>
<br>Vicente
<br>
<br></blockquote></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_1543_253707474.1412015042693--

.

Le 29/09/14 20:24, Andy Prowl a =C3=A9crit :
> Vicente,
>
> You are right about my "proposal" being far from ready (in fact, I=20
> should rather call it an "idea"). However, with time I would like to=20
> grow it into a proposal, and I'm trying to collect useful comments,=20
> suggestions, and criticism through this discussion - which is=20
> happening. That helps me figuring out if it is worth investing some=20
> serious time on it.
I understand it perfectly.
>
> You're also right about the necessity of backing up words with a=20
> prototype implementation, which is in fact one of the first things I=20
> thought of, and it is also the reason why I worried about possible=20
> implementation techniques since the beginning. At the moment, I=20
> believe hacking Clang would be the simplest way of coming up with a=20
> proof of principle.
>
In case this can help. There is an old Signature feature project  in gcc=20
[1,2] that is like your virtual concept, without mapping.
> What I find complex about Adobe.Poly (apart from finding a good=20
> documentation and the latest version of the source code) is that (1)=20
> it requires defining boilerplate adaptation code (e.g. the=20
> PlaceableImplementation from the paper by Marcus, Jarvi, and Parent);=20
> (2) the user needs to deal with templates, just like with=20
> Boost.TypeErasure; (3) it does not allow for duck-typing (unless I'm=20
> missing something).
>
Yes, Adobe::Poly, while ligther than Boost.TypeErasure on what concern=20
templates, it requires yet some boilerplate code. I guess that=20
compile-time reflection would help in genrating this boilerplate code.

I have found thatHaskell/Existentially quantified types [3] are quite=20
close to the virtual concept even it it needs to 'wrap an instance'=20
using a specific type contructor

Vicente

[1] http://bit.csc.lsu.edu/~gb/Signatures/index.html
[2] http://www.emerson.emory.edu/services/gcc/html/CPP_Signatures.html.
[3] http://en.wikibooks.org/wiki/Haskell/Existentially_quantified_types

--=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_244_1739886648.1412072225395
Content-Type: text/plain; charset=UTF-8

Thank you for the references Vicente. I shall definitely look into
Signatures. Agreed on existential types, which I should probably mention in
the draft.

I am currently working on support for free functions, will link the next
version here once I'm done (for some weak definition of "done").

Kind regards,

Andy

--

---
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_244_1739886648.1412072225395
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thank you for the references Vicente. I shall definitely l=
ook into Signatures. Agreed on existential types, which I should probably m=
ention in the draft.<br><br>I am currently working on support for free func=
tions, will link the next version here once I'm done (for some weak definit=
ion of "done").<br><br>Kind regards,<br><br>Andy</div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_244_1739886648.1412072225395--

.

------=_Part_5595_1930535110.1412173561271
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



W dniu poniedzia=C5=82ek, 29 wrze=C5=9Bnia 2014 20:24:02 UTC+2 u=C5=BCytkow=
nik Andy Prowl=20
napisa=C5=82:=20

>
> What I find complex about Adobe.Poly (apart from finding a good=20
> documentation and the latest version of the source code) is that (1) it=
=20
> requires defining boilerplate adaptation code (e.g. the=20
> PlaceableImplementation from the paper by Marcus, Jarvi, and Parent); (2)=
=20
> the user needs to deal with templates, just like with Boost.TypeErasure;=
=20
> (3) it does not allow for duck-typing (unless I'm missing something).
>

FWIW, I have compiled a short tutorial showing how to use Adobe.Poly and=20
Boost.TypeErasure. They both support duck typing (as I understand it) and=
=20
free functions:

http://akrzemi1.wordpress.com/2013/12/06/type-erasure-part-ii/

Regards,
&rzej

--=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_5595_1930535110.1412173561271
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>W dniu poniedzia=C5=82ek, 29 wrze=C5=9Bnia 2014 20=
:24:02 UTC+2 u=C5=BCytkownik Andy Prowl napisa=C5=82: <br><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><br>What I find complex about =
Adobe.Poly (apart from finding a good documentation and the latest version =
of the source code) is that (1) it requires defining boilerplate adaptation=
 code (e.g. the PlaceableImplementation from the paper by Marcus, Jarvi, an=
d Parent); (2) the user needs to deal with templates, just like with Boost.=
TypeErasure; (3) it does not allow for duck-typing (unless I'm missing some=
thing).<br></div></blockquote><div><br>FWIW, I have compiled a short tutori=
al showing how to use Adobe.Poly and Boost.TypeErasure. They both support d=
uck typing (as I understand it) and free functions:<br><br>http://akrzemi1.=
wordpress.com/2013/12/06/type-erasure-part-ii/<br><br>Regards,<br>&amp;rzej=
<br></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_5595_1930535110.1412173561271--

.

------=_Part_3252_1846694885.1412192545989
Content-Type: text/plain; charset=UTF-8

Hi Andzrej,

I read your (excellent) blog post, but judging from the use case you show,
Adobe.Poly does not seem to support duck-typing: users have to write the
adaptation logic for their types themselves (i.e. Counter and CounterImpl)
- that's equivalent to using a concept map unless I'm missing something,
just with more boilerplate code.

Honestly, the more I look at the kind of sheganigans that are needed to
work out type erasure using library solutions like Adobe.Poly and
Boost.TypeErasure, the more I think that language support is fundamental.

I am now reworking my document into something more detailed, more formal,
and closer to a draft. I think I have a solution that basically does what
you suggest at the beginning of your blog post: take a concept definition
(currently, from Concepts Lite) and let the compiler do the type-erasure
magic. That means it will be possible to support free functions as well as
static member functions. Not sure about data members at the moment.

I will link the draft here once I have a readable version of it.

Kind regards,

Andy

--

---
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_3252_1846694885.1412192545989
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Andzrej,<br><br>I read your (excellent) blog post, but =
judging from the use case you show, Adobe.Poly does not seem to support duc=
k-typing: users have to write the adaptation logic for their types themselv=
es (i.e. Counter and CounterImpl) - that's equivalent to using a concept ma=
p unless I'm missing something, just with more boilerplate code.&nbsp;<br><=
br>Honestly, the more I look at the kind of sheganigans that are needed to =
work out type erasure using library solutions like Adobe.Poly and Boost.Typ=
eErasure, the more I think that language support is fundamental.<br><br>I a=
m now reworking my document into something more detailed, more formal, and =
closer to a draft. I think I have a solution that basically does what you s=
uggest at the beginning of your blog post: take a concept definition (curre=
ntly, from Concepts Lite) and let the compiler do the type-erasure magic. T=
hat means it will be possible to support free functions as well as static m=
ember functions. Not sure about data members at the moment.<br><br><div>I w=
ill link the draft here once I have a readable version of it.<br><br>Kind r=
egards,<br><br>Andy</div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_3252_1846694885.1412192545989--

.

------=_Part_6307_939773759.1412193996459
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



W dniu =C5=9Broda, 1 pa=C5=BAdziernika 2014 21:42:26 UTC+2 u=C5=BCytkownik =
Andy Prowl=20
napisa=C5=82:
>
> Hi Andzrej,
>
> I read your (excellent) blog post, but judging from the use case you show=
,=20
> Adobe.Poly does not seem to support duck-typing: users have to write the=
=20
> adaptation logic for their types themselves (i.e. Counter and CounterImpl=
)=20
> - that's equivalent to using a concept map unless I'm missing something,=
=20
> just with more boilerplate code.=20
>

No, you implement the two classes (Counter and CounterImpl) once per=20
concept. The you can use just any type with this facility w/o any=20
adaptation, as long as it has the operations defined in the concept.


> Honestly, the more I look at the kind of sheganigans that are needed to=
=20
> work out type erasure using library solutions like Adobe.Poly and=20
> Boost.TypeErasure, the more I think that language support is fundamental.
>

I share your opinion. =20

>
> I am now reworking my document into something more detailed, more formal,=
=20
> and closer to a draft. I think I have a solution that basically does what=
=20
> you suggest at the beginning of your blog post: take a concept definition=
=20
> (currently, from Concepts Lite) and let the compiler do the type-erasure=
=20
> magic. That means it will be possible to support free functions as well a=
s=20
> static member functions. Not sure about data members at the moment.
>

I wonder if it is even possible to do this for free functions that take two=
=20
or more parameters of  type T. What do you do if the erased types mismatch.=
=20
Boost.TypeErasure does it, but I have never enough patience to figure out=
=20
how.

>
> I will link the draft here once I have a readable version of it.
>
> I can't wait to see it.=20
=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_6307_939773759.1412193996459
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>W dniu =C5=9Broda, 1 pa=C5=BAdziernika 2014 21:42:=
26 UTC+2 u=C5=BCytkownik Andy Prowl napisa=C5=82:<blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div dir=3D"ltr">Hi Andzrej,<br><br>I read your (excelle=
nt) blog post, but judging from the use case you show, Adobe.Poly does not =
seem to support duck-typing: users have to write the adaptation logic for t=
heir types themselves (i.e. Counter and CounterImpl) - that's equivalent to=
 using a concept map unless I'm missing something, just with more boilerpla=
te code.&nbsp;<br></div></blockquote><div><br>No, you implement the two cla=
sses (Counter and CounterImpl) once per concept. The you can use just any t=
ype with this facility w/o any adaptation, as long as it has the operations=
 defined in the concept.<br><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div dir=3D"ltr"><br>Honestly, the more I look at the kind of shega=
nigans that are needed to work out type erasure using library solutions lik=
e Adobe.Poly and Boost.TypeErasure, the more I think that language support =
is fundamental.<br></div></blockquote><div><br>I share your opinion.&nbsp; =
<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br=
>I am now reworking my document into something more detailed, more formal, =
and closer to a draft. I think I have a solution that basically does what y=
ou suggest at the beginning of your blog post: take a concept definition (c=
urrently, from Concepts Lite) and let the compiler do the type-erasure magi=
c. That means it will be possible to support free functions as well as stat=
ic member functions. Not sure about data members at the moment.<br></div></=
blockquote><div><br>I wonder if it is even possible to do this for free fun=
ctions that take two or more parameters of&nbsp; type T. What do you do if =
the erased types mismatch. Boost.TypeErasure does it, but I have never enou=
gh patience to figure out how.<br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"ltr"><br><div>I will link the draft here once I have =
a readable version of it.<br><br></div></div></blockquote><div>I can't wait=
 to see it. <br></div><div>&nbsp;</div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_6307_939773759.1412193996459--

.

------=_Part_4152_269449504.1412199120017
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wednesday, October 1, 2014 10:06:36 PM UTC+2, Andrzej Krzemie=C5=84ski w=
rote:
>
>
>
> W dniu =C5=9Broda, 1 pa=C5=BAdziernika 2014 21:42:26 UTC+2 u=C5=BCytkowni=
k Andy Prowl=20
> napisa=C5=82:
>>
>> Hi Andzrej,
>>
>> I read your (excellent) blog post, but judging from the use case you=20
>> show, Adobe.Poly does not seem to support duck-typing: users have to wri=
te=20
>> the adaptation logic for their types themselves (i.e. Counter and=20
>> CounterImpl) - that's equivalent to using a concept map unless I'm missi=
ng=20
>> something, just with more boilerplate code.=20
>>
>
> No, you implement the two classes (Counter and CounterImpl) once per=20
> concept. The you can use just any type with this facility w/o any=20
> adaptation, as long as it has the operations defined in the concept.
>

Oh, you're right. I overlooked that.
=20

>
>> Honestly, the more I look at the kind of sheganigans that are needed to=
=20
>> work out type erasure using library solutions like Adobe.Poly and=20
>> Boost.TypeErasure, the more I think that language support is fundamental=
..
>>
>
> I share your opinion. =20
>
>>
>> I am now reworking my document into something more detailed, more formal=
,=20
>> and closer to a draft. I think I have a solution that basically does wha=
t=20
>> you suggest at the beginning of your blog post: take a concept definitio=
n=20
>> (currently, from Concepts Lite) and let the compiler do the type-erasure=
=20
>> magic. That means it will be possible to support free functions as well =
as=20
>> static member functions. Not sure about data members at the moment.
>>
>
> I wonder if it is even possible to do this for free functions that take=
=20
> two or more parameters of  type T. What do you do if the erased types=20
> mismatch. Boost.TypeErasure does it, but I have never enough patience to=
=20
> figure out how.
>

Good point. I haven't thought about multimethods and possible=20
implementations (I know there are some, at least Bjarne Stroustrup has a=20
paper on that), but so far I was concerned mostly with situations where the=
=20
two arguments of concept type are known to the compiler to be of the same=
=20
instantiating type.=20

When defining concepts I most often write this:

template<typename T>
virtual concept bool C()
{
    return requires(T x)
    {
        foo(x, x);
        // ...
    };
}

Here, function foo() is meant to accept instances of the same type. And if=
=20
I write:

void bar(C& a, C& b)
{
    foo(a, b);
}

Then C would be bound to the same type, and I won't be able to call bar(x,=
=20
y) if the compiler can't prove that x and y are of the same type.

Now if I have something like this (hypothetical template syntax for=20
non-template functions, just to make sure a and b could refer to different=
=20
types):

template<typename T, typename U>
virtual requires C<T>() && C<U>()
void bar(T& a, U& b)
{
    foo(a, b); // ERROR!
}

I will be able to call bar() with any pair of arguments that model C, but=
=20
the compiler will stop me when trying to call foo(a, b).

At the moment I'm not able to come up with an example that would require=20
multimethod-like dispatch, but I'm pretty sure there is. I shall definitely=
=20
think about this.=20

Thank you for your comments!

Andy

--=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_4152_269449504.1412199120017
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, October 1, 2014 10:06:36 PM UTC+2, Andrzej K=
rzemie=C5=84ski wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><br><br>W dniu =C5=9Broda, 1 pa=C5=BAdziernika 2014 21:42:26 UTC+2=
 u=C5=BCytkownik Andy Prowl napisa=C5=82:<blockquote class=3D"gmail_quote" =
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr">Hi Andzrej,<br><br>I read your (excellent) blog post=
, but judging from the use case you show, Adobe.Poly does not seem to suppo=
rt duck-typing: users have to write the adaptation logic for their types th=
emselves (i.e. Counter and CounterImpl) - that's equivalent to using a conc=
ept map unless I'm missing something, just with more boilerplate code.&nbsp=
;<br></div></blockquote><div><br>No, you implement the two classes (Counter=
 and CounterImpl) once per concept. The you can use just any type with this=
 facility w/o any adaptation, as long as it has the operations defined in t=
he concept.<br></div></div></blockquote><div><br>Oh, you're right. I overlo=
oked that.<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div=
 dir=3D"ltr"><div></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D=
"ltr"><br>Honestly, the more I look at the kind of sheganigans that are nee=
ded to work out type erasure using library solutions like Adobe.Poly and Bo=
ost.TypeErasure, the more I think that language support is fundamental.<br>=
</div></blockquote><div><br>I share your opinion.&nbsp; <br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>I am now reworking my d=
ocument into something more detailed, more formal, and closer to a draft. I=
 think I have a solution that basically does what you suggest at the beginn=
ing of your blog post: take a concept definition (currently, from Concepts =
Lite) and let the compiler do the type-erasure magic. That means it will be=
 possible to support free functions as well as static member functions. Not=
 sure about data members at the moment.<br></div></blockquote><div><br>I wo=
nder if it is even possible to do this for free functions that take two or =
more parameters of&nbsp; type T. What do you do if the erased types mismatc=
h. Boost.TypeErasure does it, but I have never enough patience to figure ou=
t how.</div></div></blockquote><div><br>Good point. I haven't thought about=
 multimethods and possible implementations (I know there are some, at least=
 Bjarne Stroustrup has a paper on that), but so far I was concerned mostly =
with situations where the two arguments of concept type are known to the co=
mpiler to be of the same instantiating type.&nbsp;<br><br>When defining con=
cepts I most often write this:<br><br></div><div class=3D"prettyprint" styl=
e=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; backgroun=
d-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"sub=
prettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">temp=
late</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">typename</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">virtual</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">concept</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">bool</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> C</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">return</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> requires</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">T x</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; foo</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">x</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> x</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; </span><span style=3D"color=
: #800;" class=3D"styled-by-prettify">// ...</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">};</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">}</span></div></code></div><div><br>Here, funct=
ion foo() is meant to accept instances of the same type. And if I write:<br=
><br><div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 18=
7); word-wrap: break-word; background-color: rgb(250, 250, 250);"><code cla=
ss=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008=
;" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> bar</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">C</span><font color=3D"#666600"><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">&amp;</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> a</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> C</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> b</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; foo</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">a</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> b</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">}<=
/span></font></div></code></div><br>Then C would be bound to the same type,=
 and I won't be able to call bar(x, y) if the compiler can't prove that x a=
nd y are of the same type.<br><br>Now if I have something like this (hypoth=
etical template syntax for non-template functions, just to make sure a and =
b could refer to different types):<br><br><span class=3D"styled-by-prettify=
" style=3D"font-family: monospace; font-size: 13.3333330154419px; color: rg=
b(0, 0, 136); background-color: rgb(250, 250, 250);"></span></div><div clas=
s=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap:=
 break-word; background-color: rgb(250, 250, 250);"><code class=3D"prettypr=
int"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">template</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">typename</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> T</span><font color=3D"#666600"><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">typename</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> U</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span=
></font><span style=3D"color: #008;" class=3D"styled-by-prettify">virtual</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> requires C<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">T</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">&gt;()</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">&amp;&amp;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> C</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">U</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">&gt;()</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">void</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
bar</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">T</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> a</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> U</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&amp;</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> b</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &n=
bsp; foo</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">a</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> b</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// ERROR!</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br></span></div></code></div><div><br>I will be able to call bar(=
) with any pair of arguments that model C, but the compiler will stop me wh=
en trying to call foo(a, b).</div><div><br></div><div>At the moment I'm not=
 able to come up with an example that would require multimethod-like dispat=
ch, but I'm pretty sure there is. I shall definitely think about this.&nbsp=
;<br><br>Thank you for your comments!<br><br>Andy<br><br></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_4152_269449504.1412199120017--

.

------=_Part_311_1627152584.1412251111267
Content-Type: text/plain; charset=UTF-8

So I think I came up with a reasonably simple example. Say we have concepts
C and D defined below:

template<typename T>
virtual concept bool D();

template<typename T>
virtual concept bool C()
{
    return requires(T x, D y)
    {
        foo(x, y);
        // ...
    };
}

template<typename T>
virtual concept bool D()
{
    return requires(C x, T y)
    {
        foo(x, y);
        // ...
    };
}

Also assume we have two classes, X (which models C), and Y (which models
D). This means we have:

foo(X& x, D& d) { ... } // To make X a model of C

foo(C& c, Y& y) { ... } // To make Y a model of D

Now given the following function definition, supposing that x is bound to
an X and y is bound to a Y:

void bar(C& x, D& y)
{
    foo(x, y); // WHAT TO CALL HERE?
}

Should we end up invoking foo(X, D) or rather foo(C, Y)? Clearly that
depends on which argument we perform the dispatch through.

As it is, this call is ambiguous, and I tend to believe it should result in
an error - another possibility would be to make an arbitrary choice and
leave it up to the programmer to guarantee that foo(X, D) and foo(C, Y) do
the same thing, otherwise UB will occur (but I don't like this option).

I also wonder whether it makes sense to let the user disambiguate, and what
would be a reasonable syntax.

--

---
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_311_1627152584.1412251111267
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">So I think I came up with a reasonably simple example. Say=
 we have concepts C and D defined below:<br><br><div class=3D"prettyprint" =
style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; backg=
round-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=3D=
"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">=
template</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&l=
t;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">typename=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> T</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">virtual</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">concept</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">bool</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> D</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">();</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>template</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&=
lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">typenam=
e</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> T</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">virtual</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">concept</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">bool</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> C</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &n=
bsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">retur=
n</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> requires=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">T x</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> D y</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; foo</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">x</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> y</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; </span><span style=3D"color: #800;"=
 class=3D"styled-by-prettify">// ...</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">};</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br><br></span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">template</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>typename</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">virtual</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">concept</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;"=
 class=3D"styled-by-prettify">bool</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> D</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nb=
sp; &nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>return</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> re=
quires</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">C x</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> T y</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; foo</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">x</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> y</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; </span><span style=3D"color: #=
800;" class=3D"styled-by-prettify">// ...</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">};</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br></span></div></code></div><div><br><span style=3D"font-=
size: 13px;">Also assume we have two classes, X (which models C), and Y (wh=
ich models D). This means we have:</span><br></div><div><br></div><div clas=
s=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap:=
 break-word; background-color: rgb(250, 250, 250);"><code class=3D"prettypr=
int"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">foo</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">X</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> x</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> D</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">&amp;</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> d</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">...</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;=
" class=3D"styled-by-prettify">// To make X a model of C</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br><br>foo</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">C</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">&amp;</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> c</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> Y</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> y</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">...</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">// To ma=
ke Y a model of D</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br></span></div></code></div><div><br><span style=3D"font-size: 13p=
x;">Now given the following function definition, supposing that x is bound =
to an X and y is bound to a Y:</span><br></div><div><br></div><div class=3D=
"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: bre=
ak-word; background-color: rgb(250, 250, 250);"><code class=3D"prettyprint"=
><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled=
-by-prettify">void</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> bar</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">C</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> x</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> D</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">&amp;</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> y</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nb=
sp; &nbsp; foo</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">x</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> y</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" cl=
ass=3D"styled-by-prettify">// WHAT TO CALL HERE?</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span></div></code></div><div><br></div><div>S=
hould we end up invoking foo(X, D) or rather foo(C, Y)? Clearly that depend=
s on which argument we perform the dispatch through.</div><div><br></div><d=
iv>As it is, this call is ambiguous, and I tend to believe it should result=
 in an error - another possibility would be to make an arbitrary choice and=
 leave it up to the programmer to guarantee that foo(X, D) and foo(C, Y) do=
 the same thing, otherwise UB will occur (but I don't like this option).&nb=
sp;<br><br>I also wonder whether it makes sense to let the user disambiguat=
e, and what would be a reasonable syntax.<br></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_311_1627152584.1412251111267--

.

------=_Part_904_1050046768.1412252303181
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



W dniu czwartek, 2 pa=C5=BAdziernika 2014 13:58:31 UTC+2 u=C5=BCytkownik An=
dy Prowl=20
napisa=C5=82:
>
> So I think I came up with a reasonably simple example. Say we have=20
> concepts C and D defined below:
>
> template<typename T>
> virtual concept bool D();
>
> template<typename T>
> virtual concept bool C()
> {
>     return requires(T x, D y)
>     {
>         foo(x, y);
>         // ...
>     };
> }
>
> template<typename T>
> virtual concept bool D()
> {
>     return requires(C x, T y)
>     {
>         foo(x, y);
>         // ...
>     };
> }
>
> Also assume we have two classes, X (which models C), and Y (which models=
=20
> D). This means we have:
>
> foo(X& x, D& d) { ... } // To make X a model of C
>
> foo(C& c, Y& y) { ... } // To make Y a model of D
>
> Now given the following function definition, supposing that x is bound to=
=20
> an X and y is bound to a Y:
>
> void bar(C& x, D& y)
> {
>     foo(x, y); // WHAT TO CALL HERE?
> }
>
> Should we end up invoking foo(X, D) or rather foo(C, Y)? Clearly that=20
> depends on which argument we perform the dispatch through.
>
> As it is, this call is ambiguous, and I tend to believe it should result=
=20
> in an error - another possibility would be to make an arbitrary choice an=
d=20
> leave it up to the programmer to guarantee that foo(X, D) and foo(C, Y) d=
o=20
> the same thing, otherwise UB will occur (but I don't like this option).=
=20
>
> I also wonder whether it makes sense to let the user disambiguate, and=20
> what would be a reasonable syntax.
>

Let's take a look like static polymorphism that uses templates solves this=
=20
issue. Given the following three function templates:

template <typename T, typename U>
void fun(T t, U u);

template <typename T>
void fun(T t, int i);

template <typename U>
void fun(int i, U u);

If we try to pick one with two ints:

int i, j;
fun(i, j);

We get a compile-time ambiguity error. We can disambiguate by adding a yet=
=20
another overload:

void fun(int i, int j);

Of course, in case of run-time polymorphism no compile-time error is=20
possible, but I remember the investigation for the potential addition of=20
multimethods (or open methods) showed that this ambiguity could be made a=
=20
link-time error. I mean this doc: http://www.stroustrup.com/multimethods.pd=
f

Regards,
&rzej

--=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_904_1050046768.1412252303181
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>W dniu czwartek, 2 pa=C5=BAdziernika 2014 13:58:31=
 UTC+2 u=C5=BCytkownik Andy Prowl napisa=C5=82:<blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"><div dir=3D"ltr">So I think I came up with a reasonably si=
mple example. Say we have concepts C and D defined below:<br><br><div style=
=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;background-color=
:rgb(250,250,250)"><code><div><span style=3D"color:#008">template</span><sp=
an style=3D"color:#660">&lt;</span><span style=3D"color:#008">typename</spa=
n><span style=3D"color:#000"> T</span><span style=3D"color:#660">&gt;</span=
><span style=3D"color:#000"><br></span><span style=3D"color:#008">virtual</=
span><span style=3D"color:#000"> </span><span style=3D"color:#008">concept<=
/span><span style=3D"color:#000"> </span><span style=3D"color:#008">bool</s=
pan><span style=3D"color:#000"> D</span><span style=3D"color:#660">();</spa=
n><span style=3D"color:#000"><br><br></span><span style=3D"color:#008">temp=
late</span><span style=3D"color:#660">&lt;</span><span style=3D"color:#008"=
>typename</span><span style=3D"color:#000"> T</span><span style=3D"color:#6=
60">&gt;</span><span style=3D"color:#000"><br></span><span style=3D"color:#=
008">virtual</span><span style=3D"color:#000"> </span><span style=3D"color:=
#008">concept</span><span style=3D"color:#000"> </span><span style=3D"color=
:#008">bool</span><span style=3D"color:#000"> C</span><span style=3D"color:=
#660">()</span><span style=3D"color:#000"><br></span><span style=3D"color:#=
660">{</span><span style=3D"color:#000"><br>&nbsp; &nbsp; </span><span styl=
e=3D"color:#008">return</span><span style=3D"color:#000"> requires</span><s=
pan style=3D"color:#660">(</span><span style=3D"color:#000">T x</span><span=
 style=3D"color:#660">,</span><span style=3D"color:#000"> D y</span><span s=
tyle=3D"color:#660">)</span><span style=3D"color:#000"><br>&nbsp; &nbsp; </=
span><span style=3D"color:#660">{</span><span style=3D"color:#000"><br>&nbs=
p; &nbsp; &nbsp; &nbsp; foo</span><span style=3D"color:#660">(</span><span =
style=3D"color:#000">x</span><span style=3D"color:#660">,</span><span style=
=3D"color:#000"> y</span><span style=3D"color:#660">);</span><span style=3D=
"color:#000"><br>&nbsp; &nbsp; &nbsp; &nbsp; </span><span style=3D"color:#8=
00">// ...</span><span style=3D"color:#000"><br>&nbsp; &nbsp; </span><span =
style=3D"color:#660">};</span><span style=3D"color:#000"><br></span><span s=
tyle=3D"color:#660">}</span><span style=3D"color:#000"><br><br></span><span=
 style=3D"color:#008">template</span><span style=3D"color:#660">&lt;</span>=
<span style=3D"color:#008">typename</span><span style=3D"color:#000"> T</sp=
an><span style=3D"color:#660">&gt;</span><span style=3D"color:#000"><br></s=
pan><span style=3D"color:#008">virtual</span><span style=3D"color:#000"> </=
span><span style=3D"color:#008">concept</span><span style=3D"color:#000"> <=
/span><span style=3D"color:#008">bool</span><span style=3D"color:#000"> D</=
span><span style=3D"color:#660">()</span><span style=3D"color:#000"><br></s=
pan><span style=3D"color:#660">{</span><span style=3D"color:#000"><br>&nbsp=
; &nbsp; </span><span style=3D"color:#008">return</span><span style=3D"colo=
r:#000"> requires</span><span style=3D"color:#660">(</span><span style=3D"c=
olor:#000">C x</span><span style=3D"color:#660">,</span><span style=3D"colo=
r:#000"> T y</span><span style=3D"color:#660">)</span><span style=3D"color:=
#000"><br>&nbsp; &nbsp; </span><span style=3D"color:#660">{</span><span sty=
le=3D"color:#000"><br>&nbsp; &nbsp; &nbsp; &nbsp; foo</span><span style=3D"=
color:#660">(</span><span style=3D"color:#000">x</span><span style=3D"color=
:#660">,</span><span style=3D"color:#000"> y</span><span style=3D"color:#66=
0">);</span><span style=3D"color:#000"><br>&nbsp; &nbsp; &nbsp; &nbsp; </sp=
an><span style=3D"color:#800">// ...</span><span style=3D"color:#000"><br>&=
nbsp; &nbsp; </span><span style=3D"color:#660">};</span><span style=3D"colo=
r:#000"><br></span><span style=3D"color:#660">}</span><span style=3D"color:=
#000"><br></span></div></code></div><div><br><span style=3D"font-size:13px"=
>Also assume we have two classes, X (which models C), and Y (which models D=
). This means we have:</span><br></div><div><br></div><div style=3D"border:=
1px solid rgb(187,187,187);word-wrap:break-word;background-color:rgb(250,25=
0,250)"><code><div><span style=3D"color:#000">foo</span><span style=3D"colo=
r:#660">(</span><span style=3D"color:#000">X</span><span style=3D"color:#66=
0">&amp;</span><span style=3D"color:#000"> x</span><span style=3D"color:#66=
0">,</span><span style=3D"color:#000"> D</span><span style=3D"color:#660">&=
amp;</span><span style=3D"color:#000"> d</span><span style=3D"color:#660">)=
</span><span style=3D"color:#000"> </span><span style=3D"color:#660">{</spa=
n><span style=3D"color:#000"> </span><span style=3D"color:#660">...</span><=
span style=3D"color:#000"> </span><span style=3D"color:#660">}</span><span =
style=3D"color:#000"> </span><span style=3D"color:#800">// To make X a mode=
l of C</span><span style=3D"color:#000"><br><br>foo</span><span style=3D"co=
lor:#660">(</span><span style=3D"color:#000">C</span><span style=3D"color:#=
660">&amp;</span><span style=3D"color:#000"> c</span><span style=3D"color:#=
660">,</span><span style=3D"color:#000"> Y</span><span style=3D"color:#660"=
>&amp;</span><span style=3D"color:#000"> y</span><span style=3D"color:#660"=
>)</span><span style=3D"color:#000"> </span><span style=3D"color:#660">{</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#660">...</span=
><span style=3D"color:#000"> </span><span style=3D"color:#660">}</span><spa=
n style=3D"color:#000"> </span><span style=3D"color:#800">// To make Y a mo=
del of D</span><span style=3D"color:#000"><br></span></div></code></div><di=
v><br><span style=3D"font-size:13px">Now given the following function defin=
ition, supposing that x is bound to an X and y is bound to a Y:</span><br><=
/div><div><br></div><div style=3D"border:1px solid rgb(187,187,187);word-wr=
ap:break-word;background-color:rgb(250,250,250)"><code><div><span style=3D"=
color:#008">void</span><span style=3D"color:#000"> bar</span><span style=3D=
"color:#660">(</span><span style=3D"color:#000">C</span><span style=3D"colo=
r:#660">&amp;</span><span style=3D"color:#000"> x</span><span style=3D"colo=
r:#660">,</span><span style=3D"color:#000"> D</span><span style=3D"color:#6=
60">&amp;</span><span style=3D"color:#000"> y</span><span style=3D"color:#6=
60">)</span><span style=3D"color:#000"><br></span><span style=3D"color:#660=
">{</span><span style=3D"color:#000"><br>&nbsp; &nbsp; foo</span><span styl=
e=3D"color:#660">(</span><span style=3D"color:#000">x</span><span style=3D"=
color:#660">,</span><span style=3D"color:#000"> y</span><span style=3D"colo=
r:#660">);</span><span style=3D"color:#000"> </span><span style=3D"color:#8=
00">// WHAT TO CALL HERE?</span><span style=3D"color:#000"><br></span><span=
 style=3D"color:#660">}</span><span style=3D"color:#000"><br></span></div><=
/code></div><div><br></div><div>Should we end up invoking foo(X, D) or rath=
er foo(C, Y)? Clearly that depends on which argument we perform the dispatc=
h through.</div><div><br></div><div>As it is, this call is ambiguous, and I=
 tend to believe it should result in an error - another possibility would b=
e to make an arbitrary choice and leave it up to the programmer to guarante=
e that foo(X, D) and foo(C, Y) do the same thing, otherwise UB will occur (=
but I don't like this option).&nbsp;<br><br>I also wonder whether it makes =
sense to let the user disambiguate, and what would be a reasonable syntax.<=
br></div></div></blockquote><div><br>Let's take a look like static polymorp=
hism that uses templates solves this issue. Given the following three funct=
ion templates:<br><br>template &lt;typename T, typename U&gt;<br>void fun(T=
 t, U u);<br><br>template &lt;typename T&gt;<br>void fun(T t, int i);<br><b=
r>template &lt;typename U&gt;<br>void fun(int i, U u);<br><br>If we try to =
pick one with two ints:<br><br>int i, j;<br>fun(i, j);<br><br>We get a comp=
ile-time ambiguity error. We can disambiguate by adding a yet another overl=
oad:<br><br>void fun(int i, int j);<br><br>Of course, in case of run-time p=
olymorphism no compile-time error is possible, but I remember the investiga=
tion for the potential addition of multimethods (or open methods) showed th=
at this ambiguity could be made a link-time error. I mean this doc: http://=
www.stroustrup.com/multimethods.pdf<br><br>Regards,<br>&amp;rzej<br></div><=
/div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_904_1050046768.1412252303181--

.

------=_Part_6850_410340422.1412267838696
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

The problem here is that we have to pick one argument according to which=20
the dispatch is performed, which in the template case is not necessary. In=
=20
the template case we can disambiguate by defining a method that specializes=
=20
both fun(T, int) and fun (int, T), but how would the specializing function=
=20
for virtual concepts end up in the itable for C and D? Requiring its=20
presence would be a sort of inter-concept requirement.

Attempt at an answer: we could make the entry for "foo" in the itable for=
=20
both C and D point to a compiler-generated function which would, at=20
run-time, would inspect the types of the arguments and dispatch to the most=
=20
specialized overload of "foo()" it finds. But is this most-specialized=20
overload always guaranteed to exist? I would not like detecting ambiguities=
=20
at run-time.

The example in Section 3.1 of the paper you link - which is the one I also=
=20
had in mind - is not clear to me (especially the sentence "these overriders=
=20
have a unique base-method through which the call can be dispatched =E2=80=
=93 2."),=20
but that could just be my problem. What's objectively worrying me is that=
=20
(referring to my original example again) the client code which calls=20
"foo(x,y)", the code in which X is made a model of C (i.e. when the=20
 corresponding itable is created), and the code in which Y is made a model=
=20
of D, could all be linked separately - e.g. as DLLs. My impression is that=
=20
link-time ambiguity detection wouldn't work in this case.

Anyway thank you very much for your help Andrzej.

Kind regards,

Andy

--=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_6850_410340422.1412267838696
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The problem here is that we have to pick one argument acco=
rding to which the dispatch is performed, which in the template case is not=
 necessary. In the template case we can disambiguate by defining a method t=
hat specializes both fun(T, int) and fun (int, T), but how would the specia=
lizing function for virtual concepts end up in the itable for C and D? Requ=
iring its presence would be a sort of inter-concept requirement.<br><br>Att=
empt at an answer: we could make the entry for "foo" in the itable for both=
 C and D point to a compiler-generated function which would, at run-time, w=
ould inspect the types of the arguments and dispatch to the most specialize=
d overload of "foo()" it finds. But is this most-specialized overload alway=
s guaranteed to exist? I would not like detecting ambiguities at run-time.<=
br><br>The example in Section 3.1 of the paper you link - which is the one =
I also had in mind - is not clear to me (especially the sentence "these ove=
rriders have a unique base-method&nbsp;through which the call can be dispat=
ched =E2=80=93 2."), but that could just be my problem. What's objectively =
worrying me is that (referring to my original example again) the client cod=
e which calls "foo(x,y)", the code in which X is made a model of C (i.e. wh=
en the &nbsp;corresponding itable is created), and the code in which Y is m=
ade a model of D, could all be linked separately - e.g. as DLLs. My impress=
ion is that link-time ambiguity detection wouldn't work in this case.<br><b=
r>Anyway thank you very much for your help Andrzej.<br><br>Kind regards,<br=
><br>Andy</div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_6850_410340422.1412267838696--

.

------=_Part_385_37246373.1412536914113
Content-Type: text/plain; charset=UTF-8

I created a GitHub repo for this idea/project/proposal:
https://github.com/andyprowl/virtual-concepts.

Currently, the repository contains a draft of what is meant to become a
larger document - either a proposal itself, or a document to be referenced
from a proposal. The draft is at an early stage, containing only a
motivating introduction to the problem and an overview of existing
solutions for type erasure, including:

 - Adobe.Poly
 - Boost.TypeErasure
 - Pyry Jahkola's Poly
 - Boost.Interfaces
 - Signatures

The repository also contains code examples for the first three libraries
(the last two projects have been abandoned).

Next, I plan to add one section stating the design goals and one section
showcasing virtual concept in a nutshell. I also plan to hack on Clang and
create a proof of pricinple, but this will take time - I have zero
experience with writing compilers.

Any feedback is of course very welcome. I will keep posting further
progress here.

Kind regards,

Andy

--

---
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_385_37246373.1412536914113
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I created a GitHub repo for this idea/project/proposal:&nb=
sp;<a href=3D"https://github.com/andyprowl/virtual-concepts">https://github=
..com/andyprowl/virtual-concepts</a>.<div><br>Currently, the repository cont=
ains a draft of what is meant to become a larger document - either a propos=
al itself, or a document to be referenced from a proposal. The draft is at =
an early stage, containing only a motivating introduction to the problem an=
d an overview of existing solutions for type erasure, including:<br><br>&nb=
sp;- Adobe.Poly<br>&nbsp;- Boost.TypeErasure<br>&nbsp;- Pyry Jahkola's Poly=
<br>&nbsp;- Boost.Interfaces<br>&nbsp;- Signatures<br><br>The repository al=
so contains code examples for the first three libraries (the last two proje=
cts have been abandoned).<br><br>Next, I plan to add one section stating th=
e design goals and one section showcasing virtual concept in a nutshell. I =
also plan to hack on Clang and create a proof of pricinple, but this will t=
ake time - I have zero experience with writing compilers.<br><br>Any feedba=
ck is of course very welcome.&nbsp;I will keep posting further progress her=
e.<br><br>Kind regards,<br><br>Andy</div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_385_37246373.1412536914113--

.

------=_Part_32_656905413.1412705148594
Content-Type: text/plain; charset=UTF-8

I added a "Design Goals" section (~5 pages) to the draft on the GitHub
repo. Shortcut link (still work in progress): http://bit.ly/1CSmFRl.

Kind regards,

Andy

--

---
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_32_656905413.1412705148594
Content-Type: text/html; charset=UTF-8

<div dir="ltr">I added a "Design Goals" section (~5 pages) to the draft on the GitHub repo.&nbsp;Shortcut link (still work in progress):&nbsp;<a href="http://bit.ly/1CSmFRl">http://bit.ly/1CSmFRl</a>.<br><br>Kind regards,<br><br>Andy</div>

<p></p>

-- <br />
<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 email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

------=_Part_32_656905413.1412705148594--

.

------=_Part_373_899082822.1412942614302
Content-Type: text/plain; charset=UTF-8

As an ordinary C++ developer, I really like your proposal!

Is there a typo at p 29, 3.5?

auto r = Rectangle{{1.0, 2.0}, 5.0, 6.0};
Shape& s = r;
Shape const* p = &r;
std::unique_ptr<Shape> up = std::make_unique<Rectangle>(r);
std::shared_ptr<Shape> sp = std::move(up);
assert(up.get() == &r); // SHALL NEVER FIRE
assert(sp.get() == &s); // SHALL NEVER FIRE
assert(&r == &s); // SHALL NEVER FIRE

I might be missing something, but wouldn't the first assert fire because up
has been moved from? Perhaps the line with the move and the first assert
should be swapped?


On Tuesday, 7 October 2014 20:05:48 UTC+2, Andy Prowl wrote:
>
> I added a "Design Goals" section (~5 pages) to the draft on the GitHub
> repo. Shortcut link (still work in progress): http://bit.ly/1CSmFRl.
>
> Kind regards,
>
> Andy
>

--

---
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_373_899082822.1412942614302
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">As an ordinary C++ developer, I really like your proposal!=
<div><br></div><div>Is there a typo at p 29, 3.5?<div><br></div><div class=
=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: =
break-word; background-color: rgb(250, 250, 250);"><code class=3D"prettypri=
nt"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> r </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #606;" class=3D"styled-by-prettify">Rectangle</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">{{</span><spa=
n style=3D"color: #066;" class=3D"styled-by-prettify">1.0</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" =
class=3D"styled-by-prettify">2.0</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">},</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-pre=
ttify">5.0</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #066;" class=3D"styled-by-prettify">6.0</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">};</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: =
#606;" class=3D"styled-by-prettify">Shape</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">&amp;</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> s </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> r</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><=
/span><span style=3D"color: #606;" class=3D"styled-by-prettify">Shape</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">const</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">*</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> p </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">&amp;</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">r</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>std<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">unique_ptr</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span st=
yle=3D"color: #606;" class=3D"styled-by-prettify">Shape</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> up </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">make_unique</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">&lt;</span><span style=3D"color: #606;" class=3D"styled-by=
-prettify">Rectangle</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">&gt;(</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">r</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>std</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">shared_ptr</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Shape</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> sp </span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">move</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">up</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">assert</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">up</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">.</span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">get</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=3D=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">r</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" clas=
s=3D"styled-by-prettify">// SHALL NEVER FIRE</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">assert</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">sp</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">.</span><span style=3D"color: #008;" class=3D"styled-by-prettify">ge=
t</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">=3D=3D</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">&amp;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">s</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-pre=
ttify">// SHALL NEVER FIRE</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">assert</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">(&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">r </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=3D=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">s</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" clas=
s=3D"styled-by-prettify">// SHALL NEVER FIRE</span></div></code></div><div>=
<br></div><div>I might be missing something, but wouldn't the first assert =
fire because up has been moved from? Perhaps the line with the move and the=
 first assert should be swapped?</div><div><br></div><br>On Tuesday, 7 Octo=
ber 2014 20:05:48 UTC+2, Andy Prowl  wrote:<blockquote class=3D"gmail_quote=
" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding=
-left: 1ex;"><div dir=3D"ltr">I added a "Design Goals" section (~5 pages) t=
o the draft on the GitHub repo.&nbsp;Shortcut link (still work in progress)=
:&nbsp;<a href=3D"http://bit.ly/1CSmFRl" target=3D"_blank" onmousedown=3D"t=
his.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fbit.ly%2F1CSmFRl\46s=
a\75D\46sntz\0751\46usg\75AFQjCNGjsXYvLJxJhExs3lQ04gOjPB4-lg';return true;"=
 onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fbit.ly%=
2F1CSmFRl\46sa\75D\46sntz\0751\46usg\75AFQjCNGjsXYvLJxJhExs3lQ04gOjPB4-lg';=
return true;">http://bit.ly/<wbr>1CSmFRl</a>.<br><br>Kind regards,<br><br>A=
ndy</div></blockquote></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_373_899082822.1412942614302--

.

------=_Part_417_1517069096.1412963312332
Content-Type: text/plain; charset=UTF-8

It may be interesting for you to look at traits in Rust, they are very
similar to what you propose and serve as a tool for both static and
dynamic polymorphism. Rust is much closer to C++ in its ideology, than
Haskell, so its experience may somehow assist you with your proposal.

On Thursday, September 25, 2014 11:40:15 PM UTC+4, Andy Prowl wrote:
>
> Hello everyone,
>
> I would like to ask for feedback concerning this idea I had about
> non-intrusive "dynamic" polymorphism:
>
>
> https://www.dropbox.com/s/tg737sf8sj1p1ht/Virtual%20concepts%20for%20polymorphic%20types.pdf?dl=1
>
> This is just a rough sketch, please do not expect any full-blown proposal.
> My goal is to find out whether it makes sense to invest more time on it, or
> if the idea is basically bull***t.
>
> A few highlights:
>
> 1. The idea is about introducing non-intrusive support for dynamic
> polymorphism (similar to Haskell's typeclasses);
> 2. The idea is similar to the old C++0x "concept maps", but is *not*
> related to templates;
> 3. Code using a "virtual concept" can be compiled separately and does not
> need to see the definition of the instances of that concept.
>
> Thank you,
>
> Andy
>

--

---
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_417_1517069096.1412963312332
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">It may be interesting for you to look at traits in Rust, t=
hey are very similar to what you propose and serve as a tool for both stati=
c and dynamic&nbsp;polymorphism. Rust is much closer&nbsp;<span style=3D"fo=
nt-size: 13.3953495025635px;">to C++&nbsp;</span>in its ideology, than Hask=
ell, so its experience may somehow assist you with your proposal.<br><div><=
br>On Thursday, September 25, 2014 11:40:15 PM UTC+4, Andy Prowl wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Hello everyone,<b=
r><br>I would like to ask for feedback concerning this idea I had about non=
-intrusive "dynamic" polymorphism:<br><br><a href=3D"https://www.dropbox.co=
m/s/tg737sf8sj1p1ht/Virtual%20concepts%20for%20polymorphic%20types.pdf?dl=
=3D1" target=3D"_blank" onmousedown=3D"this.href=3D'https://www.google.com/=
url?q\75https%3A%2F%2Fwww.dropbox.com%2Fs%2Ftg737sf8sj1p1ht%2FVirtual%2520c=
oncepts%2520for%2520polymorphic%2520types.pdf%3Fdl%3D1\46sa\75D\46sntz\0751=
\46usg\75AFQjCNGymd7sW1a8uMwg4zizweWQSkl-xg';return true;" onclick=3D"this.=
href=3D'https://www.google.com/url?q\75https%3A%2F%2Fwww.dropbox.com%2Fs%2F=
tg737sf8sj1p1ht%2FVirtual%2520concepts%2520for%2520polymorphic%2520types.pd=
f%3Fdl%3D1\46sa\75D\46sntz\0751\46usg\75AFQjCNGymd7sW1a8uMwg4zizweWQSkl-xg'=
;return true;">https://www.dropbox.com/s/<wbr>tg737sf8sj1p1ht/Virtual%<wbr>=
20concepts%20for%<wbr>20polymorphic%20types.pdf?dl=3D1</a><br><br>This is j=
ust a rough sketch, please do not expect any full-blown proposal. My goal i=
s to find out whether it makes sense to invest more time on it, or if the i=
dea is basically bull***t.<br><br>A few highlights:<br><br>1. The idea is a=
bout introducing non-intrusive support for dynamic polymorphism (similar to=
 Haskell's typeclasses);<br>2. The idea is similar to the old C++0x "concep=
t maps", but is *not* related to templates;<br>3. Code using a "virtual con=
cept" can be compiled separately and does not need to see the definition of=
 the instances of that concept.<br><br>Thank you,<br><br>Andy</div></blockq=
uote></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_417_1517069096.1412963312332--

.

------=_Part_723_1205539050.1412964145454
Content-Type: text/plain; charset=UTF-8

Hi Mats,

Thank you for your feedback! You're correct, I have now moved the assertion
one line up and updated the document on the GitHub repo.

I am currently working on the next section of the draft, which should give
a clearer idea of what the proposal is all about - what it allows, what it
doesn't. I will keep posting progress here.

Kind regards,

Andy

--

---
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_723_1205539050.1412964145454
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Mats,<br><br>Thank you for your feedback! You're correc=
t, I have now moved the assertion one line up and updated the document on t=
he GitHub repo. <br><br>I am currently working on the next section of the d=
raft, which should give a clearer idea of what the proposal is all about - =
what it allows, what it doesn't. I&nbsp;will keep posting progress here.<br=
><br>Kind regards,<br><br>Andy</div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_723_1205539050.1412964145454--

.

------=_Part_947_1654146269.1412964206815
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Thank you for the tip =D0=92=D0=B0=D0=B4=D0=B8=D0=BC, I do not know Rust bu=
t I shall definitely look=20
into that.

Kind regards,

Andy

--=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_947_1654146269.1412964206815
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thank you for the tip&nbsp;=D0=92=D0=B0=D0=B4=D0=B8=D0=BC,=
 I do not know Rust but&nbsp;I shall definitely look into that.<br><br>Kind=
 regards,<br><br>Andy<br><br></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_947_1654146269.1412964206815--

.

------=_Part_3554_1449111186.1413257748141
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Friday, October 10, 2014 10:48:32 AM UTC-7, =D0=92=D0=B0=D0=B4=D0=B8=D0=
=BC wrote:
>
> It may be interesting for you to look at traits in Rust, they are very=20
> similar to what you propose and serve as a tool for both static and=20
> dynamic polymorphism. Rust is much closer to C++ in its ideology, than=20
> Haskell, so its experience may somehow assist you with your proposal.
>

Or in general look at structural=20
typing: http://en.wikipedia.org/wiki/Structural_type_system

--=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_3554_1449111186.1413257748141
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, October 10, 2014 10:48:32 AM UTC-7, =D0=92=D0=
=B0=D0=B4=D0=B8=D0=BC wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr">It may be interesting for you to look at traits in Rust, the=
y are very similar to what you propose and serve as a tool for both static =
and dynamic&nbsp;polymorphism. Rust is much closer&nbsp;<span style=3D"font=
-size:13.3953495025635px">to C++&nbsp;</span>in its ideology, than Haskell,=
 so its experience may somehow assist you with your proposal.<br></div></bl=
ockquote><div><br></div><div>Or in general look at structural typing:&nbsp;=
http://en.wikipedia.org/wiki/Structural_type_system</div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_3554_1449111186.1413257748141--

.

------=_Part_2426_1886301128.1413307057535
Content-Type: text/plain; charset=UTF-8

Thank you for the pointer Sean.

I do have some notes about structural vs. nominal typing. I also found this
old proposal by Bjarne Stroustrup in which the two systems are analyzed in
the context of generic programming and concepts:
http://www.open-std.org/Jtc1/sc22/wg21/docs/papers/2009/n2906.pdf.

Soon I will upload the next section of the draft.

Kind regards,

Andy

--

---
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_2426_1886301128.1413307057535
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><span style=3D"font-size: 13.3333330154419px;">Thank you f=
or the pointer Sean. <br><br>I do have some notes about structural vs. nomi=
nal typing. I also found this old proposal by Bjarne Stroustrup in which th=
e two systems are analyzed in the context of generic programming and concep=
ts:&nbsp;</span><a href=3D"http://www.open-std.org/Jtc1/sc22/wg21/docs/pape=
rs/2009/n2906.pdf">http://www.open-std.org/Jtc1/sc22/wg21/docs/papers/2009/=
n2906.pdf</a>.<div><br>Soon I will upload the next section of the draft.<br=
><br style=3D"font-size: 13.3333330154419px;"><span style=3D"font-size: 13.=
3333330154419px;">Kind regards,</span><br style=3D"font-size: 13.3333330154=
419px;"><br style=3D"font-size: 13.3333330154419px;"><span style=3D"font-si=
ze: 13.3333330154419px;">Andy</span><br></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_2426_1886301128.1413307057535--

.

------=_Part_1511_936155907.1413628991007
Content-Type: text/plain; charset=UTF-8

I added another section ("Virtual concepts in a nutshell") to the draft.
This new section demonstrates some practical applications of virtual
concepts and provides an overview of what is allowed and what is not - e.g.
generalize std::any and std::function, solve the Expression Problem,
support freestanding functions as well as data members, support associated
types/concepts, support concept refinement, and so on.

Section 4.3 ("Expression requirements and signature requirements") also
discusses an important issue that (at least IMHO) has been overlooked in
Concepts TS.

The next section I will add, which is about the algorithm used to extract
interfaces from concept definitions, is the core of the work and probably
the most challenging part. This will require some form of implementation
and it will take time to complete it.

Apart from this, the document is getting quite long (~60 pages now without
the bulk of the work), so I do not plan to use it as a proposal, but rather
to reference it from a (much shorter) proposal as a source of more detailed
information.

I would really appreciate any kind of feedback. Here are the pertinent
links:

Draft: http://bit.ly/1CSmFRl
<http://www.google.com/url?q=http%3A%2F%2Fbit.ly%2F1CSmFRl&sa=D&sntz=1&usg=AFQjCNGjsXYvLJxJhExs3lQ04gOjPB4-lg>
Bibliography: http://bit.ly/1CAuJEf
GitHub repo: https://github.com/andyprowl/virtual-concepts

Kind regards,

Andy

--

---
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_1511_936155907.1413628991007
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I added another section ("Virtual concepts in a nutshell")=
 to the draft. This new section demonstrates some practical applications of=
 virtual concepts and provides an overview of what is allowed and what is n=
ot - e.g. generalize std::any and std::function, solve the Expression Probl=
em, support freestanding functions as well as data members, support associa=
ted types/concepts, support concept refinement, and so on.<br><br>Section 4=
..3 ("Expression requirements and signature requirements") also discusses an=
 important issue that (at least IMHO) has been overlooked in Concepts TS.<b=
r><br>The next section I will add, which is about the algorithm used to ext=
ract interfaces from concept definitions, is the core of the work and proba=
bly the most challenging part. This will require some form of implementatio=
n and it will take time to complete it.<br><br>Apart from this, the documen=
t is getting quite long (~60 pages now without the bulk of the work), so I =
do not plan to use it as a proposal, but rather to reference it from a (muc=
h shorter) proposal as a source of more detailed information.<br><br>I woul=
d really appreciate any kind of feedback. Here are the pertinent links:<br>=
<br><span style=3D"font-size: 13.3333330154419px;">Draft:&nbsp;</span><a hr=
ef=3D"http://www.google.com/url?q=3Dhttp%3A%2F%2Fbit.ly%2F1CSmFRl&amp;sa=3D=
D&amp;sntz=3D1&amp;usg=3DAFQjCNGjsXYvLJxJhExs3lQ04gOjPB4-lg" target=3D"_bla=
nk" style=3D"cursor: pointer; font-size: 13.3333330154419px;">http://bit.ly=
/<wbr>1CSmFRl<br></a><span style=3D"font-size: 13.3333330154419px;">Bibliog=
raphy:&nbsp;</span><a href=3D"http://bit.ly/1CAuJEf" style=3D"font-size: 13=
..3333330154419px;">http://bit.ly/1CAuJEf</a><div>GitHub repo:&nbsp;<a href=
=3D"https://github.com/andyprowl/virtual-concepts">https://github.com/andyp=
rowl/virtual-concepts</a><br><div><br>Kind regards,<br><br>Andy</div></div>=
</div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_1511_936155907.1413628991007--

.

------=_Part_3192_650851986.1413799763361
Content-Type: text/plain; charset=UTF-8

I'm really exited by this feature now -- it looks like it could integrate
elegantly/intuitively into C++. Also, I really like your writing style and
thorough explanations. It makes the proposal/draft easy to understand and
follow. :)

I spotted a typo: Introducing a new pair of expression templates times and
divide is trivial:

it should read Introducing a new pair of expression templates *multiply*
and divide is trivial:

On Saturday, 18 October 2014 12:43:11 UTC+2, Andy Prowl wrote:
>
> I added another section ("Virtual concepts in a nutshell") to the draft.
> This new section demonstrates some practical applications of virtual
> concepts and provides an overview of what is allowed and what is not - e.g.
> generalize std::any and std::function, solve the Expression Problem,
> support freestanding functions as well as data members, support associated
> types/concepts, support concept refinement, and so on.
>
> Section 4.3 ("Expression requirements and signature requirements") also
> discusses an important issue that (at least IMHO) has been overlooked in
> Concepts TS.
>
> The next section I will add, which is about the algorithm used to extract
> interfaces from concept definitions, is the core of the work and probably
> the most challenging part. This will require some form of implementation
> and it will take time to complete it.
>
> Apart from this, the document is getting quite long (~60 pages now without
> the bulk of the work), so I do not plan to use it as a proposal, but rather
> to reference it from a (much shorter) proposal as a source of more detailed
> information.
>
> I would really appreciate any kind of feedback. Here are the pertinent
> links:
>
> Draft: http://bit.ly/1CSmFRl
>
> <http://www.google.com/url?q=http%3A%2F%2Fbit.ly%2F1CSmFRl&sa=D&sntz=1&usg=AFQjCNGjsXYvLJxJhExs3lQ04gOjPB4-lg>
> Bibliography: http://bit.ly/1CAuJEf
> GitHub repo: https://github.com/andyprowl/virtual-concepts
>
> Kind regards,
>
> Andy
>

--

---
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_3192_650851986.1413799763361
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I'm really exited by this feature now -- it looks like it =
could integrate elegantly/intuitively into C++. Also,&nbsp;I really like yo=
ur writing style and thorough explanations. It makes the proposal/draft eas=
y to understand and follow.&nbsp;:)<div><br></div><div>I spotted a typo:&nb=
sp;Introducing a new pair of expression templates times and divide is trivi=
al:&nbsp;</div><div><br></div><div>it should read&nbsp;Introducing a new pa=
ir of expression templates <b>multiply</b> and divide is trivial:&nbsp;<br>=
<div><br>On Saturday, 18 October 2014 12:43:11 UTC+2, Andy Prowl  wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">I added another =
section ("Virtual concepts in a nutshell") to the draft. This new section d=
emonstrates some practical applications of virtual concepts and provides an=
 overview of what is allowed and what is not - e.g. generalize std::any and=
 std::function, solve the Expression Problem, support freestanding function=
s as well as data members, support associated types/concepts, support conce=
pt refinement, and so on.<br><br>Section 4.3 ("Expression requirements and =
signature requirements") also discusses an important issue that (at least I=
MHO) has been overlooked in Concepts TS.<br><br>The next section I will add=
, which is about the algorithm used to extract interfaces from concept defi=
nitions, is the core of the work and probably the most challenging part. Th=
is will require some form of implementation and it will take time to comple=
te it.<br><br>Apart from this, the document is getting quite long (~60 page=
s now without the bulk of the work), so I do not plan to use it as a propos=
al, but rather to reference it from a (much shorter) proposal as a source o=
f more detailed information.<br><br>I would really appreciate any kind of f=
eedback. Here are the pertinent links:<br><br><span style=3D"font-size:13.3=
333330154419px">Draft:&nbsp;</span><a href=3D"http://www.google.com/url?q=
=3Dhttp%3A%2F%2Fbit.ly%2F1CSmFRl&amp;sa=3DD&amp;sntz=3D1&amp;usg=3DAFQjCNGj=
sXYvLJxJhExs3lQ04gOjPB4-lg" style=3D"font-size:13.3333330154419px" target=
=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%=
3A%2F%2Fbit.ly%2F1CSmFRl\46sa\75D\46sntz\0751\46usg\75AFQjCNGjsXYvLJxJhExs3=
lQ04gOjPB4-lg';return true;" onclick=3D"this.href=3D'http://www.google.com/=
url?q\75http%3A%2F%2Fbit.ly%2F1CSmFRl\46sa\75D\46sntz\0751\46usg\75AFQjCNGj=
sXYvLJxJhExs3lQ04gOjPB4-lg';return true;">http://bit.ly/1CSmFRl<br></a><spa=
n style=3D"font-size:13.3333330154419px">Bibliography:&nbsp;</span><a href=
=3D"http://bit.ly/1CAuJEf" style=3D"font-size:13.3333330154419px" target=3D=
"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%=
2F%2Fbit.ly%2F1CAuJEf\46sa\75D\46sntz\0751\46usg\75AFQjCNGZ5iLV5wynn-DP_zVh=
bvCIC-7umQ';return true;" onclick=3D"this.href=3D'http://www.google.com/url=
?q\75http%3A%2F%2Fbit.ly%2F1CAuJEf\46sa\75D\46sntz\0751\46usg\75AFQjCNGZ5iL=
V5wynn-DP_zVhbvCIC-7umQ';return true;">http://bit.ly/<wbr>1CAuJEf</a><div>G=
itHub repo:&nbsp;<a href=3D"https://github.com/andyprowl/virtual-concepts" =
target=3D"_blank" onmousedown=3D"this.href=3D'https://www.google.com/url?q\=
75https%3A%2F%2Fgithub.com%2Fandyprowl%2Fvirtual-concepts\46sa\75D\46sntz\0=
751\46usg\75AFQjCNFsARjNVgB0dY5aU6QGHQpQuWPlfQ';return true;" onclick=3D"th=
is.href=3D'https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fandypr=
owl%2Fvirtual-concepts\46sa\75D\46sntz\0751\46usg\75AFQjCNFsARjNVgB0dY5aU6Q=
GHQpQuWPlfQ';return true;">https://github.com/<wbr>andyprowl/virtual-concep=
ts</a><br><div><br>Kind regards,<br><br>Andy</div></div></div></blockquote>=
</div></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_3192_650851986.1413799763361--

.

------=_Part_3165_1028129240.1413801351732
Content-Type: text/plain; charset=UTF-8

Hi Mats,

Thank you for your positive feedback and for spotting the typo: fixed :)

Kind regards,

Andy

--

---
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_3165_1028129240.1413801351732
Content-Type: text/html; charset=UTF-8

<div dir="ltr">Hi Mats,<br><br>Thank you for your positive feedback and for spotting the typo: fixed :)<br><br>Kind regards,<br><br>Andy</div>

<p></p>

-- <br />
<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 email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

------=_Part_3165_1028129240.1413801351732--

.

------=_Part_1235_128709627.1457655030856
Content-Type: multipart/alternative;
 boundary="----=_Part_1236_334855968.1457655030856"

------=_Part_1236_334855968.1457655030856
Content-Type: text/plain; charset=UTF-8

Hi Andy, I read your paper and I think a feature like this is a great
direction for C++. Especially since it integrates so well with the syntax
static concepts.

One limitation I don't quite understand, on page 33 of the paper you
present a function like this:

void foo(virtual const Shape& l, virtual const Shape& r);

You state that l and r must bind to the same type, just like in static
concepts. In otherwords I could not call foo(Circle(), Rectangle()). Can
you elaborate on why this restriction is really necessary?

For static concepts, it makes sense because outside of the function "Shape"
is a constrained template parameter (i.e. a static concept) but once inside
the function "Shape" becomes a concrete type. If l and r could be different
types then the meaning of Shape inside the function would become ambiguous
and this clashes with the normal way we expect template parameters to work
inside of template classes and functions. Because this restriction is
maintained I can say sizeof(Shape), std::forward<Shape>(l), etc.. The way I
use a constrained template parameter (i.e. concept) matches exactly the way
I use a normal unconstrained template parameter T.

For dynamic concepts, no such ambiguity exists because "Shape" is already a
type. Since the dynamic types have been erased there is no ambiguity when I
reference "Shape" itself. Once I'm inside of foo(), all the compiler and I
know is that we have 2 abstract Shapes. Also when using plain old
inheritance I can have a function taking 2 pointers/references to base
classes and pass them 2 different child classes. Why am I allowed to do
easily do this inheritance but not dynamic concepts? A dynamic concepts
feature should try to match the semantics of inheritance in this fashion
since its really generalization of that type erasure technique.

Also borrowing function template syntax to define a function which is not a
template seems really confusing. Its a little bit scary that static
concepts let us define things that look like normal functions which are
actually templates. Being able to define things which look like templates
but in reality aren't seems much worse. I can't imagine teaching all of
these rules of when something is and is not a template to someone learning
the language.


--
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/36b52143-0141-43ee-b279-28a2c79043db%40isocpp.org.

------=_Part_1236_334855968.1457655030856
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Andy, I read your paper and I think a feature like this=
 is a great direction for C++. Especially since it integrates so well with =
the syntax static concepts.<div><br></div><div>One limitation I don&#39;t q=
uite understand, on page 33 of the paper you present a function like this:<=
/div><div><br></div><div>void foo(virtual const Shape&amp; l, virtual const=
 Shape&amp; r);</div><div><br></div><div>You state that l and r must bind t=
o the same type, just like in static concepts. In otherwords I could not ca=
ll foo(Circle(), Rectangle()). Can you elaborate on why this restriction is=
 really necessary?</div><div><br></div><div>For static concepts, it makes s=
ense because outside of the function &quot;Shape&quot; is a constrained tem=
plate parameter (i.e. a static concept) but once inside the function &quot;=
Shape&quot; becomes a concrete type. If l and r could be different types th=
en the meaning of Shape inside the function would become ambiguous and this=
 clashes with the normal way we expect template parameters to work inside o=
f template classes and functions. Because this restriction is maintained I =
can say sizeof(Shape), std::forward&lt;Shape&gt;(l), etc.. The way I use a =
constrained template parameter (i.e. concept) matches exactly the way I use=
 a normal unconstrained template parameter T.</div><div><br></div><div>For =
dynamic concepts, no such ambiguity exists because &quot;Shape&quot; is alr=
eady a type. Since the dynamic types have been erased there is no ambiguity=
 when I reference &quot;Shape&quot; itself. Once I&#39;m inside of foo(), a=
ll the compiler and I know is that we have 2 abstract Shapes. Also when usi=
ng plain old inheritance I can have a function taking 2 pointers/references=
 to base classes and pass them 2 different child classes. Why am I allowed =
to do easily do this inheritance but not dynamic concepts? A dynamic concep=
ts feature should try to match the semantics of inheritance in this fashion=
 since its really generalization of that type erasure technique.=C2=A0</div=
><div><br></div><div>Also borrowing function template syntax to define a fu=
nction which is not a template seems really confusing. Its a little bit sca=
ry that static concepts let us define things that look like normal function=
s which are actually templates. Being able to define things which look like=
 templates but in reality aren&#39;t seems much worse. I can&#39;t imagine =
teaching all of these rules of when something is and is not a template to s=
omeone learning the language.</div><div><br></div><div><br></div></div>

<p></p>

-- <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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/36b52143-0141-43ee-b279-28a2c79043db%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/36b52143-0141-43ee-b279-28a2c79043db=
%40isocpp.org</a>.<br />

------=_Part_1236_334855968.1457655030856--
------=_Part_1235_128709627.1457655030856--

.

--001a1143798a870a92052dc0db98
Content-Type: text/plain; charset=UTF-8

2016-03-11 1:10 GMT+01:00 Matthew Fioravante <fmatthew5876@gmail.com>:

>
> One limitation I don't quite understand, on page 33 of the paper you
> present a function like this:
>
> void foo(virtual const Shape& l, virtual const Shape& r);
>
> You state that l and r must bind to the same type, just like in static
> concepts. In otherwords I could not call foo(Circle(), Rectangle()). Can
> you elaborate on why this restriction is really necessary?
>

[snip]


> For dynamic concepts, no such ambiguity exists because "Shape" is already
> a type. Since the dynamic types have been erased there is no ambiguity when
> I reference "Shape" itself. Once I'm inside of foo(), all the compiler and
> I know is that we have 2 abstract Shapes. Also when using plain old
> inheritance I can have a function taking 2 pointers/references to base
> classes and pass them 2 different child classes. Why am I allowed to do
> easily do this inheritance but not dynamic concepts? A dynamic concepts
> feature should try to match the semantics of inheritance in this fashion
> since its really generalization of that type erasure technique.
>

Hi Matthew.
I want to address one of the concerns you raised. Andy's paper forbids it,
because it is not clear how the feature should behave in this case. It
would be not implementable.

When you are performing an operation on two Shapes, you are in fact doing a
dynamic-dispatch on two virtual tables. You need to solve the same problem
as multi-methods solve.

With Andy's restriction, when you get two Shape-s, you extract their
dynamic type:

```
void use(Shape s1, Shape s2)
{
  intersect(s1, s2);
}
```

You check that s1 is of type Circle, s2 is of type circle, so you know what
to do: you call:

bool intersect(Circle const&, Circle const);

(which is probably part of the interface.) But if you figure out that s1's
dynamic type is Library1::Polygon and s2's type is
Library2::ShapeOfAustralia, to what function do you dispatch?

I hope this explanation helps.

Regards,
&rzej

--
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/CAOenAXg7CZLNeg%2BfjiE6oP5AQZ%3DZs1YPe2Nn1ORs5kdxFdvEHw%40mail.gmail.com.

--001a1143798a870a92052dc0db98
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">2016-03-11 1:10 GMT+01:00 Matthew Fioravante <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:fmatthew5876@gmail.com" target=3D"_blank">fmatthew5876@gmail.=
com</a>&gt;</span>:<br><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=
><br></div><div>One limitation I don&#39;t quite understand, on page 33 of =
the paper you present a function like this:</div><div><br></div><div>void f=
oo(virtual const Shape&amp; l, virtual const Shape&amp; r);</div><div><br><=
/div><div>You state that l and r must bind to the same type, just like in s=
tatic concepts. In otherwords I could not call foo(Circle(), Rectangle()). =
Can you elaborate on why this restriction is really necessary?</div></div><=
/blockquote><div><br></div><div>[snip]<br>=C2=A0<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div>For dynamic concepts, no such ambiguity=
 exists because &quot;Shape&quot; is already a type. Since the dynamic type=
s have been erased there is no ambiguity when I reference &quot;Shape&quot;=
 itself. Once I&#39;m inside of foo(), all the compiler and I know is that =
we have 2 abstract Shapes. Also when using plain old inheritance I can have=
 a function taking 2 pointers/references to base classes and pass them 2 di=
fferent child classes. Why am I allowed to do easily do this inheritance bu=
t not dynamic concepts? A dynamic concepts feature should try to match the =
semantics of inheritance in this fashion since its really generalization of=
 that type erasure technique.=C2=A0</div></div></blockquote><div><br></div>=
<div>Hi Matthew.<br></div><div>I want to address one of the concerns you ra=
ised. Andy&#39;s paper forbids it, because it is not clear how the feature =
should behave in this case. It would be not implementable.<br><br></div><di=
v>When you are performing an operation on two Shapes, you are in fact doing=
 a dynamic-dispatch on two virtual tables. You need to solve the same probl=
em as multi-methods solve.<br><br></div><div>With Andy&#39;s restriction, w=
hen you get two Shape-s, you extract their dynamic type:<br><br>```<br></di=
v><div>void use(Shape s1, Shape s2)<br>{<br></div><div>=C2=A0 intersect(s1,=
 s2);<br></div><div>}<br>```<br></div><div dir=3D"ltr"><br></div><div>You c=
heck that s1 is of type Circle, s2 is of type circle, so you know what to d=
o: you call:<br><br></div><div>bool intersect(Circle const&amp;, Circle con=
st); <br></div><div dir=3D"ltr"><br></div><div>(which is probably part of t=
he interface.) But if you figure out that s1&#39;s dynamic type is Library1=
::Polygon and s2&#39;s type is Library2::ShapeOfAustralia, to what function=
 do you dispatch?<br><br></div><div>I hope this explanation helps.<br><br><=
/div><div>Regards,<br></div><div>&amp;rzej<br></div><div dir=3D"ltr"><br>
</div></div><br></div></div>

<p></p>

-- <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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOenAXg7CZLNeg%2BfjiE6oP5AQZ%3DZs1YP=
e2Nn1ORs5kdxFdvEHw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOenAXg7CZLN=
eg%2BfjiE6oP5AQZ%3DZs1YPe2Nn1ORs5kdxFdvEHw%40mail.gmail.com</a>.<br />

--001a1143798a870a92052dc0db98--

.

------=_Part_1553_1765245065.1457688112548
Content-Type: multipart/alternative;
 boundary="----=_Part_1554_1870858928.1457688112548"

------=_Part_1554_1870858928.1457688112548
Content-Type: text/plain; charset=UTF-8

Hi Matthew,

Thank you for your feedback.

Concerning your question about repeated occurrences of a (virtual) concept
name, there's more than one reason that led me to this choice.

The main reason is that, in general, both scenarios are useful. Sometimes
you want to express the fact that two erased objects must have the same
type, and sometimes you want to allow them being independent. For example,
imagine a concept SomeConcept modeling CopyConstructible and CopyAssignable
(or just, say, Regular), and the following function:

    void foo(SomeConcept& c, SomeConcept& d)
    {
        auto e = c;
        c = d;
    }

The body of foo() makes sense only because "c" and "d" are known to be of
the same (erased) type. Models of SomeConcept are only required to be
CopyConstructible and CopyAssignable, i.e. constructible and assignable
from another instance *of the same type*, not constructible/assignable from
any instance of *any* other type modeling SomeConcept.

Let's also assume SomeConcept models DefaultConstructible, and consider
this:

    void foo(SomeConcept& c)
    {
        SomeConcept d;
        // ...
    }

How do we know what type should be default-constructed in the first line?
If all occurrences of the same concept name imply that the erased type is
the same, then we know what to instantiate here: the same type erased by
parameter "c". Otherwise, we're at a loss and the first line does not make
sense (if you're wondering how can we achieve virtual dispatch on a default
constructor, the latest version of the draft
at https://github.com/andyprowl/virtual-concepts contains the answer in
Section 5).

Certainly we also want to be able to specify that two concept variables may
erase objects of different types (for the good parallel you draw with
inheritance-based use cases). But what syntax to use? To me (but I see the
controversy), the most natural choice was to use template syntax, where
different type identifiers imply independent erasure:

    template<typename T, typename U>
        requires SomeConcept<T> && SomeConcept<U>
    void foo(SomeConcept& c, SomeConcept& d)
    {
        // ...
    }


Now I do understand your concern of this being counter-intuitive. I agree
with it. However, defining syntax was not a priority for me. I liked the
symmetry of this solution and my reasoning was sort of: "in Concepts TS
non-template syntax can define function templates, which means syntax
doesn't decide whether something is a template or not; but if that's the
case, why not allowing template syntax to define non-function templates?".
I do agree this is counter-intuitive and confusing: I just needed to pick
some syntax and postpone bike-shedding (if we can call it like that).

Finally, consistency with Concepts TS just strengthened my decision of
having repeated concept identifiers mean "same erased type".

Does this answer your question?

Andy

P.S.: People started to show interest for this proposal again, and there is
now another thread in the SG8 - Concepts mailing list:
https://groups.google.com/a/isocpp.org/forum/#!topic/concepts/241lmpRP28I.

--
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/2a0b4b0c-c29b-4801-a90d-405b6e8b04e1%40isocpp.org.

------=_Part_1554_1870858928.1457688112548
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Matthew,</div><div><br></div><div>Thank you for yo=
ur feedback.</div><div><br></div>Concerning your question about repeated oc=
currences of a (virtual) concept name, there&#39;s more than one reason tha=
t led me to this choice.<div><br></div><div>The main reason is that, in gen=
eral, both scenarios are useful. Sometimes you want to express the fact tha=
t two erased objects must have the same type, and sometimes you want to all=
ow them being independent. For example, imagine a concept SomeConcept model=
ing CopyConstructible and CopyAssignable (or just, say, Regular), and the f=
ollowing function:<br><br><div class=3D"prettyprint" style=3D"border: 1px s=
olid rgb(187, 187, 187); word-wrap: break-word; background-color: rgb(250, =
250, 250);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span=
 style=3D"color: #000;" class=3D"styled-by-prettify">=C2=A0 =C2=A0 </span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> foo</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #606;" class=3D"styled-by-prettify">SomeConcept</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">&amp;</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> c</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-pr=
ettify">SomeConcept</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">&amp;</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> d</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =
=C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> e </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> c</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0=
 =C2=A0 c </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> d</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span></div></=
code></div></div><div><br>The body of foo() makes sense only because &quot;=
c&quot; and &quot;d&quot; are known to be of the same (erased) type. Models=
 of SomeConcept are only required to be CopyConstructible and CopyAssignabl=
e, i.e. constructible and assignable from another instance *of the same typ=
e*, not constructible/assignable from any instance of *any* other type mode=
ling SomeConcept.<br><br>Let&#39;s also assume SomeConcept models DefaultCo=
nstructible, and consider this:</div><div><br><div class=3D"prettyprint" st=
yle=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; backgro=
und-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"s=
ubprettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">=
=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">void</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> f=
oo</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span>=
<span style=3D"color: #606;" class=3D"styled-by-prettify">SomeConcept</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> c</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </spa=
n><span style=3D"color: #606;" class=3D"styled-by-prettify">SomeConcept</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> d</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 </span><span style=3D"color: #800;" class=3D"styled-by-prettify">// ...</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =
=C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</=
span></div></code></div><br>How do we know what type should be default-cons=
tructed in the first line? If all occurrences of the same concept name impl=
y that the erased type is the same, then we know what to instantiate here: =
the same type erased by parameter &quot;c&quot;. Otherwise, we&#39;re at a =
loss and the first line does not make sense (if you&#39;re wondering how ca=
n we achieve virtual dispatch on a default constructor, the latest version =
of the draft at=C2=A0https://github.com/andyprowl/virtual-concepts contains=
 the answer in Section 5).<br><br>Certainly we also want to be able to spec=
ify that two concept variables may erase objects of different types (for th=
e good parallel you draw with inheritance-based use cases). But what syntax=
 to use? To me (but I see the controversy), the most natural choice was to =
use template syntax, where different type identifiers imply independent era=
sure:</div><div><br></div><div class=3D"prettyprint" style=3D"border: 1px s=
olid rgb(187, 187, 187); word-wrap: break-word; background-color: rgb(250, =
250, 250);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span=
 style=3D"color: #000;" class=3D"styled-by-prettify">=C2=A0 =C2=A0 </span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">template</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">typename</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">typename</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> U</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 requires </span><span style=3D"color: =
#606;" class=3D"styled-by-prettify">SomeConcept</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">&amp;&amp;</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">=
SomeConcept</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">U</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> foo</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"c=
olor: #606;" class=3D"styled-by-prettify">SomeConcept</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">&amp;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> c</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-b=
y-prettify">SomeConcept</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">&amp;</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> d</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=
=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 </span><font color=3D"#000088"><span style=3D"colo=
r: #800;" class=3D"styled-by-prettify">// ...</span></font><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br><br></span></div></code></div>=
<div><br></div><div>Now I do understand your concern of this being counter-=
intuitive. I agree with it. However, defining syntax was not a priority for=
 me. I liked the symmetry of this solution and my reasoning was sort of: &q=
uot;in Concepts TS non-template syntax can define function templates, which=
 means syntax doesn&#39;t decide whether something is a template or not; bu=
t if that&#39;s the case, why not allowing template syntax to define non-fu=
nction templates?&quot;. I do agree this is counter-intuitive and confusing=
: I just needed to pick some syntax and postpone bike-shedding (if we can c=
all it like that).<br><br>Finally, consistency with Concepts TS just streng=
thened my decision of having repeated concept identifiers mean &quot;same e=
rased type&quot;.<br><br>Does this answer your question?<br><br>Andy<br><br=
>P.S.: People started to show interest for this proposal again, and there i=
s now another thread in the SG8 - Concepts mailing list:=C2=A0<a href=3D"ht=
tps://groups.google.com/a/isocpp.org/forum/#!topic/concepts/241lmpRP28I">ht=
tps://groups.google.com/a/isocpp.org/forum/#!topic/concepts/241lmpRP28I</a>=
..</div><div><br></div></div>

<p></p>

-- <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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2a0b4b0c-c29b-4801-a90d-405b6e8b04e1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2a0b4b0c-c29b-4801-a90d-405b6e8b04e1=
%40isocpp.org</a>.<br />

------=_Part_1554_1870858928.1457688112548--
------=_Part_1553_1765245065.1457688112548--

.

------=_Part_1466_1830263085.1457688270500
Content-Type: multipart/alternative;
 boundary="----=_Part_1467_865201273.1457688270500"

------=_Part_1467_865201273.1457688270500
Content-Type: text/plain; charset=UTF-8

Erm, I made a mistake in the example for independent erasure: the function
parameters should have type T and U, obviously, and not SomeConcept. This
is the correct snippet:

    template<typename T, typename U>
        requires SomeConcept<T> && SomeConcept<U>
    void foo(T& c, U& d)
    {
        // ...
    }





On Friday, March 11, 2016 at 10:21:52 AM UTC+1, Andy Prowl wrote:
>
> Hi Matthew,
>
> Thank you for your feedback.
>
> Concerning your question about repeated occurrences of a (virtual) concept
> name, there's more than one reason that led me to this choice.
>
> The main reason is that, in general, both scenarios are useful. Sometimes
> you want to express the fact that two erased objects must have the same
> type, and sometimes you want to allow them being independent. For example,
> imagine a concept SomeConcept modeling CopyConstructible and CopyAssignable
> (or just, say, Regular), and the following function:
>
>     void foo(SomeConcept& c, SomeConcept& d)
>     {
>         auto e = c;
>         c = d;
>     }
>
> The body of foo() makes sense only because "c" and "d" are known to be of
> the same (erased) type. Models of SomeConcept are only required to be
> CopyConstructible and CopyAssignable, i.e. constructible and assignable
> from another instance *of the same type*, not constructible/assignable from
> any instance of *any* other type modeling SomeConcept.
>
> Let's also assume SomeConcept models DefaultConstructible, and consider
> this:
>
>     void foo(SomeConcept& c)
>     {
>         SomeConcept d;
>         // ...
>     }
>
> How do we know what type should be default-constructed in the first line?
> If all occurrences of the same concept name imply that the erased type is
> the same, then we know what to instantiate here: the same type erased by
> parameter "c". Otherwise, we're at a loss and the first line does not make
> sense (if you're wondering how can we achieve virtual dispatch on a default
> constructor, the latest version of the draft at
> https://github.com/andyprowl/virtual-concepts contains the answer in
> Section 5).
>
> Certainly we also want to be able to specify that two concept variables
> may erase objects of different types (for the good parallel you draw with
> inheritance-based use cases). But what syntax to use? To me (but I see the
> controversy), the most natural choice was to use template syntax, where
> different type identifiers imply independent erasure:
>
>     template<typename T, typename U>
>         requires SomeConcept<T> && SomeConcept<U>
>     void foo(SomeConcept& c, SomeConcept& d)
>     {
>         // ...
>     }
>
>
> Now I do understand your concern of this being counter-intuitive. I agree
> with it. However, defining syntax was not a priority for me. I liked the
> symmetry of this solution and my reasoning was sort of: "in Concepts TS
> non-template syntax can define function templates, which means syntax
> doesn't decide whether something is a template or not; but if that's the
> case, why not allowing template syntax to define non-function templates?".
> I do agree this is counter-intuitive and confusing: I just needed to pick
> some syntax and postpone bike-shedding (if we can call it like that).
>
> Finally, consistency with Concepts TS just strengthened my decision of
> having repeated concept identifiers mean "same erased type".
>
> Does this answer your question?
>
> Andy
>
> P.S.: People started to show interest for this proposal again, and there
> is now another thread in the SG8 - Concepts mailing list:
> https://groups.google.com/a/isocpp.org/forum/#!topic/concepts/241lmpRP28I.
>
>

--
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/9385c676-cebd-4dff-a695-586fc92ccf52%40isocpp.org.

------=_Part_1467_865201273.1457688270500
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Erm, I made a mistake in the example for independent erasu=
re: the function parameters should have type T and U, obviously, and not So=
meConcept. This is the correct snippet:<br><br><div class=3D"prettyprint" s=
tyle=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; backgr=
ound-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"=
subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">=
=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">template</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">type=
name</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> T</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">typename</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> U</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 requires </span>=
<span style=3D"color: #606;" class=3D"styled-by-prettify">SomeConcept</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify">T</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">&amp;&amp;</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"=
styled-by-prettify">SomeConcept</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">U</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">void</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> foo</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">T</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> c</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> U</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&amp;</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> d</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// ...</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">}</span></div></code></div><span style=3D"font-=
family: monospace; color: rgb(102, 102, 0); background-color: rgb(250, 250,=
 250);"><br></span><span style=3D"font-family: monospace; color: rgb(0, 0, =
0); background-color: rgb(250, 250, 250);"><br></span><br><br><br>On Friday=
, March 11, 2016 at 10:21:52 AM UTC+1, Andy Prowl wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Hi Matthew,</div><div><br=
></div><div>Thank you for your feedback.</div><div><br></div>Concerning you=
r question about repeated occurrences of a (virtual) concept name, there&#3=
9;s more than one reason that led me to this choice.<div><br></div><div>The=
 main reason is that, in general, both scenarios are useful. Sometimes you =
want to express the fact that two erased objects must have the same type, a=
nd sometimes you want to allow them being independent. For example, imagine=
 a concept SomeConcept modeling CopyConstructible and CopyAssignable (or ju=
st, say, Regular), and the following function:<br><br><div style=3D"border:=
1px solid rgb(187,187,187);word-wrap:break-word;background-color:rgb(250,25=
0,250)"><code><div><span style=3D"color:#000">=C2=A0 =C2=A0 </span><span st=
yle=3D"color:#008">void</span><span style=3D"color:#000"> foo</span><span s=
tyle=3D"color:#660">(</span><span style=3D"color:#606">SomeConcept</span><s=
pan style=3D"color:#660">&amp;</span><span style=3D"color:#000"> c</span><s=
pan style=3D"color:#660">,</span><span style=3D"color:#000"> </span><span s=
tyle=3D"color:#606">SomeConcept</span><span style=3D"color:#660">&amp;</spa=
n><span style=3D"color:#000"> d</span><span style=3D"color:#660">)</span><s=
pan style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#660=
">{</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span=
><span style=3D"color:#008">auto</span><span style=3D"color:#000"> e </span=
><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> c</span><=
span style=3D"color:#660">;</span><span style=3D"color:#000"><br>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 c </span><span style=3D"color:#660">=3D</span><span style=
=3D"color:#000"> d</span><span style=3D"color:#660">;</span><span style=3D"=
color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#660">}</span></d=
iv></code></div></div><div><br>The body of foo() makes sense only because &=
quot;c&quot; and &quot;d&quot; are known to be of the same (erased) type. M=
odels of SomeConcept are only required to be CopyConstructible and CopyAssi=
gnable, i.e. constructible and assignable from another instance *of the sam=
e type*, not constructible/assignable from any instance of *any* other type=
 modeling SomeConcept.<br><br>Let&#39;s also assume SomeConcept models Defa=
ultConstructible, and consider this:</div><div><br><div style=3D"border:1px=
 solid rgb(187,187,187);word-wrap:break-word;background-color:rgb(250,250,2=
50)"><code><div><span style=3D"color:#000">=C2=A0 =C2=A0 </span><span style=
=3D"color:#008">void</span><span style=3D"color:#000"> foo</span><span styl=
e=3D"color:#660">(</span><span style=3D"color:#606">SomeConcept</span><span=
 style=3D"color:#660">&amp;</span><span style=3D"color:#000"> c</span><span=
 style=3D"color:#660">)</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =
</span><span style=3D"color:#660">{</span><span style=3D"color:#000"><br>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#606">SomeConcept</=
span><span style=3D"color:#000"> d</span><span style=3D"color:#660">;</span=
><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span st=
yle=3D"color:#800">// ...</span><span style=3D"color:#000"><br>=C2=A0 =C2=
=A0 </span><span style=3D"color:#660">}</span></div></code></div><br>How do=
 we know what type should be default-constructed in the first line? If all =
occurrences of the same concept name imply that the erased type is the same=
, then we know what to instantiate here: the same type erased by parameter =
&quot;c&quot;. Otherwise, we&#39;re at a loss and the first line does not m=
ake sense (if you&#39;re wondering how can we achieve virtual dispatch on a=
 default constructor, the latest version of the draft at=C2=A0<a href=3D"ht=
tps://github.com/andyprowl/virtual-concepts" target=3D"_blank" rel=3D"nofol=
low" onmousedown=3D"this.href=3D&#39;https://www.google.com/url?q\75https%3=
A%2F%2Fgithub.com%2Fandyprowl%2Fvirtual-concepts\46sa\75D\46sntz\0751\46usg=
\75AFQjCNFsARjNVgB0dY5aU6QGHQpQuWPlfQ&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fandypro=
wl%2Fvirtual-concepts\46sa\75D\46sntz\0751\46usg\75AFQjCNFsARjNVgB0dY5aU6QG=
HQpQuWPlfQ&#39;;return true;">https://github.com/<wbr>andyprowl/virtual-con=
cepts</a> contains the answer in Section 5).<br><br>Certainly we also want =
to be able to specify that two concept variables may erase objects of diffe=
rent types (for the good parallel you draw with inheritance-based use cases=
). But what syntax to use? To me (but I see the controversy), the most natu=
ral choice was to use template syntax, where different type identifiers imp=
ly independent erasure:</div><div><br></div><div style=3D"border:1px solid =
rgb(187,187,187);word-wrap:break-word;background-color:rgb(250,250,250)"><c=
ode><div><span style=3D"color:#000">=C2=A0 =C2=A0 </span><span style=3D"col=
or:#008">template</span><span style=3D"color:#660">&lt;</span><span style=
=3D"color:#008">typename</span><span style=3D"color:#000"> T</span><span st=
yle=3D"color:#660">,</span><span style=3D"color:#000"> </span><span style=
=3D"color:#008">typename</span><span style=3D"color:#000"> U</span><span st=
yle=3D"color:#660">&gt;</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 requires </span><span style=3D"color:#606">SomeConcept</span>=
<span style=3D"color:#660">&lt;</span><span style=3D"color:#000">T</span><s=
pan style=3D"color:#660">&gt;</span><span style=3D"color:#000"> </span><spa=
n style=3D"color:#660">&amp;&amp;</span><span style=3D"color:#000"> </span>=
<span style=3D"color:#606">SomeConcept</span><span style=3D"color:#660">&lt=
;</span><span style=3D"color:#000">U</span><span style=3D"color:#660">&gt;<=
/span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"co=
lor:#008">void</span><span style=3D"color:#000"> foo</span><span style=3D"c=
olor:#660">(</span><span style=3D"color:#606">SomeConcept</span><span style=
=3D"color:#660">&amp;</span><span style=3D"color:#000"> c</span><span style=
=3D"color:#660">,</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#606">SomeConcept</span><span style=3D"color:#660">&amp;</span><span s=
tyle=3D"color:#000"> d</span><span style=3D"color:#660">)</span><span style=
=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#660">{</span=
><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><font co=
lor=3D"#000088"><span style=3D"color:#800">// ...</span></font><span style=
=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#660">}</span=
><span style=3D"color:#000"><br><br></span></div></code></div><div><br></di=
v><div>Now I do understand your concern of this being counter-intuitive. I =
agree with it. However, defining syntax was not a priority for me. I liked =
the symmetry of this solution and my reasoning was sort of: &quot;in Concep=
ts TS non-template syntax can define function templates, which means syntax=
 doesn&#39;t decide whether something is a template or not; but if that&#39=
;s the case, why not allowing template syntax to define non-function templa=
tes?&quot;. I do agree this is counter-intuitive and confusing: I just need=
ed to pick some syntax and postpone bike-shedding (if we can call it like t=
hat).<br><br>Finally, consistency with Concepts TS just strengthened my dec=
ision of having repeated concept identifiers mean &quot;same erased type&qu=
ot;.<br><br>Does this answer your question?<br><br>Andy<br><br>P.S.: People=
 started to show interest for this proposal again, and there is now another=
 thread in the SG8 - Concepts mailing list:=C2=A0<a href=3D"https://groups.=
google.com/a/isocpp.org/forum/#!topic/concepts/241lmpRP28I" target=3D"_blan=
k" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://groups.google.c=
om/a/isocpp.org/forum/#!topic/concepts/241lmpRP28I&#39;;return true;" oncli=
ck=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/forum/#!topic=
/concepts/241lmpRP28I&#39;;return true;">https://groups.google.<wbr>com/a/i=
socpp.org/forum/#!<wbr>topic/concepts/241lmpRP28I</a>.</div><div><br></div>=
</div></blockquote></div>

<p></p>

-- <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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9385c676-cebd-4dff-a695-586fc92ccf52%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9385c676-cebd-4dff-a695-586fc92ccf52=
%40isocpp.org</a>.<br />

------=_Part_1467_865201273.1457688270500--
------=_Part_1466_1830263085.1457688270500--

.