------=_Part_2409_24007733.1373047209443
Content-Type: text/plain; charset=ISO-8859-1

Hi,

There's something that concerns me about the progress of the upcoming C++
standards. I'm concerned that the currently proposed way of introducing
concepts into C++ will rule out an opportunity of seamlessly merging
concepts with a very closely related idea, that is type erasure and
archetypes.

Let's take the following example :

template<typename T>
constexpr bool Incrementable()
{
   return requires (T a) {
      {++a};
   };
}

This constraint simultaneously defines an archetype for the Incrementable
concept. The archetype could be explicitly defined as the following class:

class Incrementable_archetype {
public:
   virtual operator++() = 0;
   virtual ~Incrementable_archetype();
};

Now, if we also define a class that wraps any Incrementable type and
exposes it as an Incrementable_archetype:

template <Incrementable I>
class Incrementable_wrapper: public Incrementable_archetype {
   I & i;
public:
   Incrementable_wrapper(I & i):i(i){}
   operator++() {i++;}
};

We can pass instances of this wrapper to a function that expects a type
satisfying the Incrementable concept. This is basically type erasure.

Suppose that we have a template function:

template<Incrementable I>
void just_increment(I & i) { i++;}

We can define another function to accept an Incrementable instance, wrap it
as the archetype and pass it with the type erased:

template<Incrementable I>
void just_increment_call_with_archetype(I & i) {
   Incrementable_archetype inc_arch = Incrementable_wrapper<I>(i);
   just_increment(inc_arch);
}

What did we gain by this? Now we can actually call the template
just_increment function without including its definition.

--just_increment.h--
template<Incrementable I>
void just_increment(I & i);

template<Incrementable I>
void just_increment_call_with_archetype(I & i) {
   Incrementable_archetype inc_arch = Incrementable_wrapper<I>(i);
   just_increment(inc_arch);
}

--just_increment.cpp--

template<Incrementable I>
void just_increment(I & i) { i++;}

template void
just_increment<Incrementable_archetype>(Incrementable_archetype &); //
Explicit instantiation

--main.cpp--
#include<just_increment.h>

int main() {
   int i;
   just_increment_call_with_archetype(i);
}



I think, with the proper syntax for the specification of constraints, the
compiler could theoretically auto-generate the classes
Incrementable_archetype and Incrementable_wrapper as well as the template
function just_increment_call_with_archetype. Such a feature would pave the
way for new uses for template functions, such as the ability to pass around
"pointers" for them. It would also enable a way to decouple the definition
and declaration of template functions, greatly improving compile times for
projects that make heavy use of templates.

For instance, it is conceivable that the developer compiles the code with
the call with archetype strategy during rapid development iterations for
the code that he's working on, but then he switches to the traditional
template instantiation for release.

I don't want to enumerate the possibilities enabled by type erasure as this
message is already quite long. Those who are familiar with the
boost.type_erasure library probably already know the benefits, and I
recommend the others who are not familiar to familiarize themselves with
the library, especially if they're interested in concepts. As I've
expressed in the beginning of this message; I think concepts and type
erasure are naturally very closely linked.

Coming to the conclusion, I dare not propose an alternative syntax for the
definition of constraints in C++ as I don't think I'm wise enough for that.
Nor am I proposing that this automatic archetype generation should become a
part of C++ by C++14 or C++17. All I'm saying is that I think this is a
natural extension of the concepts idea, and we might one day want this to
be a core C++ feature. I'm just concerned that the current proposal for
concepts lite is too generic and it might simply make the auto-generation
of archetypes impossible for all eternity.

Note finally that even though the example I've provided is quite trivial,
you can apply the same steps for a concept that's arbitrarily complex, and
obtain a "call_with_archetype" variant. I can provide a moderately
complicated example if you decide that I'm not crazy and that this idea
isn't totally worthless.

--

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

<div>Hi,</div><div><br></div><div>There's something that concerns me about =
the progress of the upcoming C++ standards. I'm concerned that the currentl=
y proposed way of introducing concepts into C++ will rule out an opportunit=
y of seamlessly merging concepts with a very closely related idea, that is =
type erasure and archetypes.</div><div><br></div><div>Let's take the follow=
ing example :</div><div><br></div><div>template&lt;typename T&gt;<br></div>=
<div>constexpr bool Incrementable()</div><div>{</div><div>&nbsp; &nbsp;retu=
rn requires (T a) {</div><div>&nbsp; &nbsp; &nbsp; {++a};</div><div>&nbsp; =
&nbsp;};<br></div><div>}</div><div><br></div><div>This constraint simultane=
ously defines an archetype for the Incrementable concept. The archetype cou=
ld be explicitly defined as the following class:</div><div><br></div><div>c=
lass Incrementable_archetype {</div><div>public:</div><div>&nbsp; &nbsp;vir=
tual operator++() =3D 0;</div><div>&nbsp; &nbsp;virtual ~Incrementable_arch=
etype();</div><div>};</div><div><br></div><div>Now, if we also define a cla=
ss that wraps any Incrementable type and exposes it as an Incrementable_arc=
hetype:</div><div><br></div><div>template &lt;Incrementable I&gt;</div><div=
>class Incrementable_wrapper: public Incrementable_archetype {</div><div>&n=
bsp; &nbsp;I &amp; i;</div><div>public:</div><div>&nbsp; &nbsp;Incrementabl=
e_wrapper(I &amp; i):i(i){}</div><div>&nbsp; &nbsp;operator++() {i++;}</div=
><div>};</div><div><br></div><div>We can pass instances of this wrapper to =
a function that expects a type satisfying the Incrementable concept. This i=
s basically type erasure.</div><div><br></div><div>Suppose that we have a t=
emplate function:</div><div><br></div><div>template&lt;Incrementable I&gt;<=
/div><div>void just_increment(I &amp; i) { i++;}</div><div><br></div><div>W=
e can define another function to accept an Incrementable instance, wrap it =
as the archetype and pass it with the type erased:</div><div><br></div><div=
>template&lt;Incrementable I&gt;</div><div>void just_increment_call_with_ar=
chetype(I &amp; i) {</div><div>&nbsp; &nbsp;Incrementable_archetype inc_arc=
h =3D Incrementable_wrapper&lt;I&gt;(i);</div><div>&nbsp; &nbsp;just_increm=
ent(inc_arch);</div><div>}</div><div><br></div><div>What did we gain by thi=
s? Now we can actually call the template just_increment function without in=
cluding its definition.</div><div><br></div><div>--just_increment.h--</div>=
<div><div>template&lt;Incrementable I&gt;</div><div>void just_increment(I &=
amp; i);</div></div><div><br></div><div><div>template&lt;Incrementable I&gt=
;</div><div>void just_increment_call_with_archetype(I &amp; i) {</div><div>=
&nbsp; &nbsp;Incrementable_archetype inc_arch =3D Incrementable_wrapper&lt;=
I&gt;(i);</div><div>&nbsp; &nbsp;just_increment(inc_arch);</div><div>}</div=
></div><div><br></div><div>--just_increment.cpp--</div><div><br></div><div>=
<div>template&lt;Incrementable I&gt;</div><div>void just_increment(I &amp; =
i) { i++;}</div></div><div><br></div><div>template void just_increment&lt;I=
ncrementable_archetype&gt;(Incrementable_archetype &amp;); // Explicit inst=
antiation</div><div><br></div><div>--main.cpp--</div><div>#include&lt;just_=
increment.h&gt;</div><div><br></div><div>int main() {</div><div>&nbsp; &nbs=
p;int i;</div><div>&nbsp; &nbsp;just_increment_call_with_archetype(i);</div=
><div>}</div><div><br></div><div><br></div><div><br></div><div>I think, wit=
h the proper syntax for the specification of constraints, the compiler coul=
d theoretically auto-generate the classes Incrementable_archetype and Incre=
mentable_wrapper as well as the template function just_increment_call_with_=
archetype. Such a feature would pave the way for new uses for template func=
tions, such as the ability to pass around "pointers" for them. It would als=
o enable a way to decouple the definition and declaration of template funct=
ions, greatly improving compile times for projects that make heavy use of t=
emplates.</div><div><br></div><div>For instance, it is conceivable that the=
 developer compiles the code with the call with archetype strategy during r=
apid development iterations for the code that he's working on, but then he =
switches to the traditional template instantiation for release.</div><div><=
br></div><div>I don't want to enumerate the possibilities enabled by type e=
rasure as this message is already quite long. Those who are familiar with t=
he boost.type_erasure library probably already know the benefits, and I rec=
ommend the others who are not familiar to familiarize themselves with the l=
ibrary, especially if they're interested in concepts. As I've expressed in =
the beginning of this message; I think concepts and type erasure are natura=
lly very closely linked.</div><div><br></div><div>Coming to the conclusion,=
 I dare not propose an alternative syntax for the definition of constraints=
 in C++ as I don't think I'm wise enough for that. Nor am I proposing that =
this automatic archetype generation should become a part of C++ by C++14 or=
 C++17. All I'm saying is that I think this is a natural extension of the c=
oncepts idea, and we might one day want this to be a core C++ feature. I'm =
just concerned that the current proposal for concepts lite is too generic a=
nd it might simply make the auto-generation of archetypes impossible for al=
l eternity.</div><div><br></div><div>Note finally that even though the exam=
ple I've provided is quite trivial, you can apply the same steps for a conc=
ept that's arbitrarily complex, and obtain a "call_with_archetype" variant.=
 I can provide a moderately complicated example if you decide that I'm not =
crazy and that this idea isn't totally worthless.</div>

<p></p>

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

------=_Part_2409_24007733.1373047209443--

.

enisbayramoglu@gmail.com writes:

| Hi,
|
| There's something that concerns me about the progress of the upcoming C++
| standards. I'm concerned that the currently proposed way of introducing
| concepts into C++ will rule out an opportunity of seamlessly merging concepts
| with a very closely related idea, that is type erasure and archetypes.

It was a conscious design decision, based on past experience, not to use
archetypes (and by implication "concept maps") as either operational model
or implementation model.

-- Gaby

|
| Let's take the following example :
|
| template<typename T>
| constexpr bool Incrementable()
| {
|    return requires (T a) {
|       {++a};
|    };
| }
|
| This constraint simultaneously defines an archetype for the Incrementable
| concept. The archetype could be explicitly defined as the following class:
|
| class Incrementable_archetype {
| public:
|    virtual operator++() = 0;
|    virtual ~Incrementable_archetype();
| };
|
| Now, if we also define a class that wraps any Incrementable type and exposes it
| as an Incrementable_archetype:
|
| template <Incrementable I>
| class Incrementable_wrapper: public Incrementable_archetype {
|    I & i;
| public:
|    Incrementable_wrapper(I & i):i(i){}
|    operator++() {i++;}
| };
|
| We can pass instances of this wrapper to a function that expects a type
| satisfying the Incrementable concept. This is basically type erasure.
|
| Suppose that we have a template function:
|
| template<Incrementable I>
| void just_increment(I & i) { i++;}
|
| We can define another function to accept an Incrementable instance, wrap it as
| the archetype and pass it with the type erased:
|
| template<Incrementable I>
| void just_increment_call_with_archetype(I & i) {
|    Incrementable_archetype inc_arch = Incrementable_wrapper<I>(i);
|    just_increment(inc_arch);
| }
|
| What did we gain by this? Now we can actually call the template just_increment
| function without including its definition.
|
| --just_increment.h--
| template<Incrementable I>
| void just_increment(I & i);
|
| template<Incrementable I>
| void just_increment_call_with_archetype(I & i) {
|    Incrementable_archetype inc_arch = Incrementable_wrapper<I>(i);
|    just_increment(inc_arch);
| }
|
| --just_increment.cpp--
|
| template<Incrementable I>
| void just_increment(I & i) { i++;}
|
| template void just_increment<Incrementable_archetype>(Incrementable_archetype
| &); // Explicit instantiation
|
| --main.cpp--
| #include<just_increment.h>
|
| int main() {
|    int i;
|    just_increment_call_with_archetype(i);
| }
|
|
|
| I think, with the proper syntax for the specification of constraints, the
| compiler could theoretically auto-generate the classes Incrementable_archetype
| and Incrementable_wrapper as well as the template function
| just_increment_call_with_archetype. Such a feature would pave the way for new
| uses for template functions, such as the ability to pass around "pointers" for
| them. It would also enable a way to decouple the definition and declaration of
| template functions, greatly improving compile times for projects that make
| heavy use of templates.
|
| For instance, it is conceivable that the developer compiles the code with the
| call with archetype strategy during rapid development iterations for the code
| that he's working on, but then he switches to the traditional template
| instantiation for release.
|
| I don't want to enumerate the possibilities enabled by type erasure as this
| message is already quite long. Those who are familiar with the
| boost.type_erasure library probably already know the benefits, and I recommend
| the others who are not familiar to familiarize themselves with the library,
| especially if they're interested in concepts. As I've expressed in the
| beginning of this message; I think concepts and type erasure are naturally very
| closely linked.
|
| Coming to the conclusion, I dare not propose an alternative syntax for the
| definition of constraints in C++ as I don't think I'm wise enough for that. Nor
| am I proposing that this automatic archetype generation should become a part of
| C++ by C++14 or C++17. All I'm saying is that I think this is a natural
| extension of the concepts idea, and we might one day want this to be a core C++
| feature. I'm just concerned that the current proposal for concepts lite is too
| generic and it might simply make the auto-generation of archetypes impossible
| for all eternity.
|
| Note finally that even though the example I've provided is quite trivial, you
| can apply the same steps for a concept that's arbitrarily complex, and obtain a
| "call_with_archetype" variant. I can provide a moderately complicated example
| if you decide that I'm not crazy and that this idea isn't totally worthless.
|
| --
|
| ---
| 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/.



.