Topic: Re: [std-proposals] Re: Adding the Keyword interf
Author: Christopher Di Bella <cjdb.ns@gmail.com>
Date: Mon, 08 May 2017 06:03:05 +0000
Raw View
--f403045eb91ac148f4054efcfe48
Content-Type: text/plain; charset=UTF-8
If I understand correctly, this is an appropriate summary:
`interface` is syntactic sugar for specifying a concept where object
instantiation will deduce
some_ptr<C> foo = make_some<T>(...);
Or, more concretely:
shared_ptr<Invocable<int, int>> foo = make_shared<less<int>>();
------
How would the instantiation proceed?
The best I can think is:
Callable foo = less<int>{};
------
I am also not a fan of rejecting C because both A and B require a function
f with the same signature.
As you're specifying an interface, common interfaces should be allowed.
Cheers,
Chris
On Mon., 8 May 2017, 15:29 Mingxin Wang, <wmx16835vv@163.com> wrote:
> The implementation for the *Callable *interface was incorrect, and should
> be as follows:
>
> template <class R, class... Args>
> class Callable {
> public:
> template <class Data>
> Callable(Data data) requires
> requires(Data data, Args... args) { { data(std::move(args)...) } ->
> R; }
> : data_(new Implementation<Data>(std::move(data))) {}
> Callable() = default;
> Callable(Callable&&) = default;
> Callable(const Callable&) = default;
> Callable& operator=(Callable&&) = default;
> Callable& operator=(const Callable&) = default;
>
> *R operator()(Args... args) { return data_->op_0(std::move(args)...); }*
>
> private:
> class Abstraction {
> public:
> *virtual R op_0(Args&&...) = 0;*
> virtual ~Abstraction() {}
> };
>
> template <class Data>
> class Implementation final : public Abstraction {
> public:
> Implementation(Data&& data) : data_(std::forward<Data>(data)) {}
> *R op_0(Args&&... args) override { return
> data_(std::forward<Args>(args)...); }*
>
> private:
> Data data_;
> };
>
> std::shared_ptr<Abstraction> data_;
> };
>
> --
> 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/e700af7e-aee3-4ba9-b899-2f603fed1e72%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e700af7e-aee3-4ba9-b899-2f603fed1e72%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
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/CACL3gUXPSVdsT0Z77igxGVtHU9ALGPcN%3D7hwKKKfBmt8eQmXtA%40mail.gmail.com.
--f403045eb91ac148f4054efcfe48
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">If I understand correctly, this is an appropriate summary:=
</div><span>
</span><p dir=3D"ltr">`interface` is syntactic sugar for specifying a conce=
pt where object instantiation will deduce</p><span>
</span><p dir=3D"ltr">some_ptr<C> foo =3D make_some<T>(...);</p=
><span>
</span><p dir=3D"ltr">Or, more concretely:</p><span>
</span><p dir=3D"ltr">shared_ptr<Invocable<int, int>> foo =3D m=
ake_shared<less<int>>();</p><p dir=3D"ltr"><span style=3D"font-=
size:13px">------</span></p><p dir=3D"ltr"><span style=3D"font-size:13px">H=
ow would the instantiation proceed?</span></p><p dir=3D"ltr">
The best I can think is:</p><span>
</span><p dir=3D"ltr">Callable foo =3D less<int>{};<br>
------<br>
I am also not a fan of rejecting C because both A and B require a function =
f with the same signature.</p><span>
</span><p dir=3D"ltr">As you're specifying an interface, common interfa=
ces should be allowed.</p><p dir=3D"ltr">Cheers,</p><p dir=3D"ltr">Chris</p=
><span>
</span><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon., 8 May 2017,=
15:29 Mingxin Wang, <<a href=3D"mailto:wmx16835vv@163.com" target=3D"_b=
lank">wmx16835vv@163.com</a>> wrote:<br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr"><font face=3D"georgia, serif">The implementation for =
the <b>Callable </b>interface was incorrect, and should be as follows:</fon=
t><div><font face=3D"georgia, serif"><br></font></div><div><div class=3D"m_=
7214766348534025787m_3388546097108341696prettyprint" style=3D"border:1px so=
lid rgb(187,187,187);word-wrap:break-word;background-color:rgb(250,250,250)=
"><code class=3D"m_7214766348534025787m_3388546097108341696prettyprint"><di=
v class=3D"m_7214766348534025787m_3388546097108341696subprettyprint"><font =
color=3D"#660066"></font></div></code></div></div></div><div dir=3D"ltr"><d=
iv><div class=3D"m_7214766348534025787m_3388546097108341696prettyprint" sty=
le=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;background-col=
or:rgb(250,250,250)"><code class=3D"m_7214766348534025787m_3388546097108341=
696prettyprint"><div class=3D"m_7214766348534025787m_3388546097108341696sub=
prettyprint"><font color=3D"#660066"><div class=3D"m_7214766348534025787m_3=
388546097108341696subprettyprint">template <class R, class... Args></=
div><div class=3D"m_7214766348534025787m_3388546097108341696subprettyprint"=
>class Callable {</div><div class=3D"m_7214766348534025787m_338854609710834=
1696subprettyprint">=C2=A0public:</div><div class=3D"m_7214766348534025787m=
_3388546097108341696subprettyprint">=C2=A0 template <class Data></div=
><div class=3D"m_7214766348534025787m_3388546097108341696subprettyprint">=
=C2=A0 Callable(Data data) requires</div><div class=3D"m_721476634853402578=
7m_3388546097108341696subprettyprint">=C2=A0 =C2=A0 =C2=A0 requires(Data da=
ta, Args... args) { { data(std::move(args)...) } -> R; }</div><div class=
=3D"m_7214766348534025787m_3388546097108341696subprettyprint">=C2=A0 =C2=A0=
=C2=A0 : data_(new Implementation<Data>(std::move(data))) {}</div><d=
iv class=3D"m_7214766348534025787m_3388546097108341696subprettyprint">=C2=
=A0 Callable() =3D default;</div><div class=3D"m_7214766348534025787m_33885=
46097108341696subprettyprint">=C2=A0 Callable(Callable&&) =3D defau=
lt;</div><div class=3D"m_7214766348534025787m_3388546097108341696subprettyp=
rint">=C2=A0 Callable(const Callable&) =3D default;</div><div class=3D"=
m_7214766348534025787m_3388546097108341696subprettyprint">=C2=A0 Callable&a=
mp; operator=3D(Callable&&) =3D default;</div><div class=3D"m_72147=
66348534025787m_3388546097108341696subprettyprint">=C2=A0 Callable& ope=
rator=3D(const Callable&) =3D default;</div><div class=3D"m_72147663485=
34025787m_3388546097108341696subprettyprint"><br></div></font></div></code>=
</div></div></div><div dir=3D"ltr"><div><div class=3D"m_7214766348534025787=
m_3388546097108341696prettyprint" style=3D"border:1px solid rgb(187,187,187=
);word-wrap:break-word;background-color:rgb(250,250,250)"><code class=3D"m_=
7214766348534025787m_3388546097108341696prettyprint"><div class=3D"m_721476=
6348534025787m_3388546097108341696subprettyprint"><font color=3D"#660066"><=
div class=3D"m_7214766348534025787m_3388546097108341696subprettyprint">=C2=
=A0 <b>R operator()(Args... args) { return data_->op_0(std::move(args)..=
..); }</b></div><div class=3D"m_7214766348534025787m_3388546097108341696subp=
rettyprint"><br></div><div class=3D"m_7214766348534025787m_3388546097108341=
696subprettyprint">=C2=A0private:</div><div class=3D"m_7214766348534025787m=
_3388546097108341696subprettyprint">=C2=A0 class Abstraction {</div><div cl=
ass=3D"m_7214766348534025787m_3388546097108341696subprettyprint">=C2=A0 =C2=
=A0public:</div><div class=3D"m_7214766348534025787m_3388546097108341696sub=
prettyprint">=C2=A0 =C2=A0 <b>virtual R op_0(Args&&...) =3D 0;</b><=
/div></font></div></code></div></div></div><div dir=3D"ltr"><div><div class=
=3D"m_7214766348534025787m_3388546097108341696prettyprint" style=3D"border:=
1px solid rgb(187,187,187);word-wrap:break-word;background-color:rgb(250,25=
0,250)"><code class=3D"m_7214766348534025787m_3388546097108341696prettyprin=
t"><div class=3D"m_7214766348534025787m_3388546097108341696subprettyprint">=
<font color=3D"#660066"><div class=3D"m_7214766348534025787m_33885460971083=
41696subprettyprint">=C2=A0 =C2=A0 virtual ~Abstraction() {}</div><div clas=
s=3D"m_7214766348534025787m_3388546097108341696subprettyprint">=C2=A0 };</d=
iv><div class=3D"m_7214766348534025787m_3388546097108341696subprettyprint">=
<br></div><div class=3D"m_7214766348534025787m_3388546097108341696subpretty=
print">=C2=A0 template <class Data></div><div class=3D"m_721476634853=
4025787m_3388546097108341696subprettyprint">=C2=A0 class Implementation fin=
al : public Abstraction {</div><div class=3D"m_7214766348534025787m_3388546=
097108341696subprettyprint">=C2=A0 =C2=A0public:</div><div class=3D"m_72147=
66348534025787m_3388546097108341696subprettyprint">=C2=A0 =C2=A0 Implementa=
tion(Data&& data) : data_(std::forward<Data>(data)) {}</div><=
/font></div></code></div></div></div><div dir=3D"ltr"><div><div class=3D"m_=
7214766348534025787m_3388546097108341696prettyprint" style=3D"border:1px so=
lid rgb(187,187,187);word-wrap:break-word;background-color:rgb(250,250,250)=
"><code class=3D"m_7214766348534025787m_3388546097108341696prettyprint"><di=
v class=3D"m_7214766348534025787m_3388546097108341696subprettyprint"><font =
color=3D"#660066"><div class=3D"m_7214766348534025787m_3388546097108341696s=
ubprettyprint">=C2=A0 =C2=A0 <b>R op_0(Args&&... args) override { r=
eturn data_(std::forward<Args>(args)...); }</b></div></font></div></c=
ode></div></div></div><div dir=3D"ltr"><div><div class=3D"m_721476634853402=
5787m_3388546097108341696prettyprint" style=3D"border:1px solid rgb(187,187=
,187);word-wrap:break-word;background-color:rgb(250,250,250)"><code class=
=3D"m_7214766348534025787m_3388546097108341696prettyprint"><div class=3D"m_=
7214766348534025787m_3388546097108341696subprettyprint"><font color=3D"#660=
066"><div class=3D"m_7214766348534025787m_3388546097108341696subprettyprint=
"><br></div><div class=3D"m_7214766348534025787m_3388546097108341696subpret=
typrint">=C2=A0 =C2=A0private:</div><div class=3D"m_7214766348534025787m_33=
88546097108341696subprettyprint">=C2=A0 =C2=A0 Data data_;</div><div class=
=3D"m_7214766348534025787m_3388546097108341696subprettyprint">=C2=A0 };</di=
v><div class=3D"m_7214766348534025787m_3388546097108341696subprettyprint"><=
br></div><div class=3D"m_7214766348534025787m_3388546097108341696subprettyp=
rint">=C2=A0 std::shared_ptr<Abstraction> data_;</div><div class=3D"m=
_7214766348534025787m_3388546097108341696subprettyprint">};</div></font></d=
iv></code></div></div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e700af7e-aee3-4ba9-b899-2f603fed1e72%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e700af7e-aee3-=
4ba9-b899-2f603fed1e72%40isocpp.org</a>.<br>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CACL3gUXPSVdsT0Z77igxGVtHU9ALGPcN%3D7=
hwKKKfBmt8eQmXtA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACL3gUXPSVdsT0=
Z77igxGVtHU9ALGPcN%3D7hwKKKfBmt8eQmXtA%40mail.gmail.com</a>.<br />
--f403045eb91ac148f4054efcfe48--
.
Author: Mingxin Wang <wmx16835vv@163.com>
Date: Mon, 8 May 2017 00:30:58 -0700 (PDT)
Raw View
------=_Part_2298_1052276866.1494228658752
Content-Type: multipart/alternative;
boundary="----=_Part_2299_1687278531.1494228658752"
------=_Part_2299_1687278531.1494228658752
Content-Type: text/plain; charset=UTF-8
The "*Interfaces*" is more like a wrapper for the types needed to be
managed at runtime. Unlike the "*Concespts*" that work at compile time, the
"*Interfaces*" work at runtime mostly. In essence, it is not only
a syntactic sugar, but a style of implementation for *polymorphism*:
virtual functions are only generated when required at runtime, and the
types which are able to be determined at compile time are recommended to be
implemented with "*templates*" and "*concepts*".
We can write the following code with "*Interfaces*":
using iterator = std::vector<int>::iterator;
thread_pool.submit([] { puts("Lambda"); });
thread_pool.submit(bind_simple(std::copy<iterator, iterator>, src.begin(),
src.end(), dest.begin()));
thread_pool.submit(std::packaged_task<void()>(bind_simple(std::sort<iterator>,
vec.begin(), vec.end())));
Callable<void> foo(std::less<int>());
providing "*interface Runnable*" and "*interface template Callable*" is
defined:
interface Runnable {
void operator()();
};
template <class R, class... Args>
interface Callable {
R operator()(Args...);
};
"*interface C*" in the example is not encouraged because any overloads of
member functions usually associate with *unique semantics*, which are
supposed to be well documented, e.g.:
<https://lh3.googleusercontent.com/-Kzcp_qvSH0g/WRAWmnIBikI/AAAAAAAAADQ/LeNSxqUfmB430luh4S_uHagz-7BhRt7xgCLcB/s1600/Untitled.png>
Thank you!
Mingxin Wang
On Monday, May 8, 2017 at 2:03:18 PM UTC+8, Christopher Di Bella wrote:
>
> If I understand correctly, this is an appropriate summary:
>
> `interface` is syntactic sugar for specifying a concept where object
> instantiation will deduce
>
> some_ptr<C> foo = make_some<T>(...);
>
> Or, more concretely:
>
> shared_ptr<Invocable<int, int>> foo = make_shared<less<int>>();
>
> ------
>
> How would the instantiation proceed?
>
> The best I can think is:
>
> Callable foo = less<int>{};
> ------
> I am also not a fan of rejecting C because both A and B require a function
> f with the same signature.
>
> As you're specifying an interface, common interfaces should be allowed.
>
> Cheers,
>
> Chris
>
> On Mon., 8 May 2017, 15:29 Mingxin Wang, <wmx16...@163.com <javascript:>>
> wrote:
>
>> The implementation for the *Callable *interface was incorrect, and
>> should be as follows:
>>
>> template <class R, class... Args>
>> class Callable {
>> public:
>> template <class Data>
>> Callable(Data data) requires
>> requires(Data data, Args... args) { { data(std::move(args)...) } ->
>> R; }
>> : data_(new Implementation<Data>(std::move(data))) {}
>> Callable() = default;
>> Callable(Callable&&) = default;
>> Callable(const Callable&) = default;
>> Callable& operator=(Callable&&) = default;
>> Callable& operator=(const Callable&) = default;
>>
>> *R operator()(Args... args) { return data_->op_0(std::move(args)...);
>> }*
>>
>> private:
>> class Abstraction {
>> public:
>> *virtual R op_0(Args&&...) = 0;*
>> virtual ~Abstraction() {}
>> };
>>
>> template <class Data>
>> class Implementation final : public Abstraction {
>> public:
>> Implementation(Data&& data) : data_(std::forward<Data>(data)) {}
>> *R op_0(Args&&... args) override { return
>> data_(std::forward<Args>(args)...); }*
>>
>> private:
>> Data data_;
>> };
>>
>> std::shared_ptr<Abstraction> data_;
>> };
>>
>> --
>> 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-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e700af7e-aee3-4ba9-b899-2f603fed1e72%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e700af7e-aee3-4ba9-b899-2f603fed1e72%40isocpp.org?utm_medium=email&utm_source=footer>
>> .
>>
>
--
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/9ee212eb-4037-40c4-94c3-57a9a170a4c3%40isocpp.org.
------=_Part_2299_1687278531.1494228658752
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><span style=3D"font-family: georgia, serif;">The &quo=
t;</span><b style=3D"font-family: georgia, serif;">Interfaces</b><span styl=
e=3D"font-family: georgia, serif;">" is more like a wrapper for the ty=
pes needed to be managed at runtime. Unlike the "</span><b style=3D"fo=
nt-family: georgia, serif;">Concespts</b><span style=3D"font-family: georgi=
a, serif;">" that work at compile time, the "</span><b style=3D"f=
ont-family: georgia, serif;">Interfaces</b><span style=3D"font-family: geor=
gia, serif;">" work at runtime mostly.=C2=A0In essence, it</span><span=
style=3D"font-family: georgia, serif;">=C2=A0is not only a=C2=A0syntactic =
sugar, but a style of implementation for=C2=A0</span><b style=3D"font-famil=
y: georgia, serif;">polymorphism</b><span style=3D"font-family: georgia, se=
rif;">: virtual functions are only generated when required at runtime, and =
the types which are able to be determined at compile time are recommended t=
o be implemented with "</span><b style=3D"font-family: georgia, serif;=
">templates</b><span style=3D"font-family: georgia, serif;">" and &quo=
t;</span><b style=3D"font-family: georgia, serif;">concepts</b><span style=
=3D"font-family: georgia, serif;">".</span><br></div><div><font face=
=3D"georgia, serif"><br></font></div><div><font face=3D"georgia, serif">We =
can write the following code with "<b>Interfaces</b>":</font></di=
v><div><font face=3D"georgia, serif"><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"><div class=3D"subprettyprint"><div class=3D"subprettyprint"><div clas=
s=3D"subprettyprint">using iterator =3D std::vector<int>::iterator;</=
div><div class=3D"subprettyprint"><div class=3D"subprettyprint">thread_pool=
..submit([] { puts("Lambda"); });</div><div class=3D"subprettyprin=
t">thread_pool.submit(bind_simple(std::copy<iterator, iterator>, src.=
begin(), src.end(), dest.begin()));</div><div class=3D"subprettyprint">thre=
ad_pool.submit(std::packaged_task<void()>(bind_simple(std::sort<it=
erator>, vec.begin(), vec.end())));</div><div class=3D"subprettyprint">C=
allable<void> foo(std::less<int>());</div></div></div></div></d=
iv></code></div>providing "<b>interface Runnable</b>" and "<=
b>interface template Callable</b>" is defined:</font></div><div><font =
face=3D"georgia, serif"><br></font></div><div><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"><font color=3D"#660066"><div class=3D"subprettyprint">interf=
ace Runnable {</div><div class=3D"subprettyprint">=C2=A0 void operator()();=
</div><div class=3D"subprettyprint">};</div><div class=3D"subprettyprint"><=
br></div><div class=3D"subprettyprint">template <class R, class... Args&=
gt;</div><div class=3D"subprettyprint">interface Callable {</div><div class=
=3D"subprettyprint">=C2=A0 R operator()(Args...);</div><div class=3D"subpre=
ttyprint">};</div></font></div></code></div><br></div><div><font face=3D"ge=
orgia, serif">"<b>interface C</b>" in the example is not encourag=
ed because any overloads of member functions usually associate=C2=A0with <b=
>unique semantics</b>, which are supposed to be well documented, e.g.:</fon=
t></div><div><font face=3D"georgia, serif"><br></font><p class=3D"separator=
" style=3D"text-align: center; clear: both;"><a imageanchor=3D"1" href=3D"h=
ttps://lh3.googleusercontent.com/-Kzcp_qvSH0g/WRAWmnIBikI/AAAAAAAAADQ/LeNSx=
qUfmB430luh4S_uHagz-7BhRt7xgCLcB/s1600/Untitled.png" style=3D"margin-left: =
1em; margin-right: 1em;"><img src=3D"https://lh3.googleusercontent.com/-Kzc=
p_qvSH0g/WRAWmnIBikI/AAAAAAAAADQ/LeNSxqUfmB430luh4S_uHagz-7BhRt7xgCLcB/s400=
/Untitled.png" border=3D"0" width=3D"400" height=3D"131"></a></p><div><br><=
/div><div><font face=3D"georgia, serif">Thank you!</font></div><div><font f=
ace=3D"georgia, serif"><br></font></div><div><font face=3D"georgia, serif">=
Mingxin Wang</font></div><div><br>On Monday, May 8, 2017 at 2:03:18 PM UTC+=
8, Christopher Di Bella wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div dir=3D"ltr">If I understand correctly, this is an appropriate summary:=
</div><span>
</span><p dir=3D"ltr">`interface` is syntactic sugar for specifying a conce=
pt where object instantiation will deduce</p><span>
</span><p dir=3D"ltr">some_ptr<C> foo =3D make_some<T>(...);</p=
><span>
</span><p dir=3D"ltr">Or, more concretely:</p><span>
</span><p dir=3D"ltr">shared_ptr<Invocable<int, int>> foo =3D m=
ake_shared<less<int>>();</p><p dir=3D"ltr"><span style=3D"font-=
size:13px">------</span></p><p dir=3D"ltr"><span style=3D"font-size:13px">H=
ow would the instantiation proceed?</span></p><p dir=3D"ltr">
The best I can think is:</p><span>
</span><p dir=3D"ltr">Callable foo =3D less<int>{};<br>
------<br>
I am also not a fan of rejecting C because both A and B require a function =
f with the same signature.</p><span>
</span><p dir=3D"ltr">As you're specifying an interface, common interfa=
ces should be allowed.</p><p dir=3D"ltr">Cheers,</p><p dir=3D"ltr">Chris</p=
><span>
</span><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon., 8 May 2017,=
15:29 Mingxin Wang, <<a href=3D"javascript:" target=3D"_blank" gdf-obfu=
scated-mailto=3D"8dWhkk2eBQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D=
'javascript:';return true;" onclick=3D"this.href=3D'javascript:=
';return true;">wmx16...@163.com</a>> wrote:<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><font face=3D"georgia, serif">The impleme=
ntation for the <b>Callable </b>interface was incorrect, and should be as f=
ollows:</font><div><font face=3D"georgia, serif"><br></font></div><div><div=
style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;background=
-color:rgb(250,250,250)"><code><div><font color=3D"#660066"></font></div></=
code></div></div></div><div dir=3D"ltr"><div><div style=3D"border:1px solid=
rgb(187,187,187);word-wrap:break-word;background-color:rgb(250,250,250)"><=
code><div><font color=3D"#660066"><div>template <class R, class... Args&=
gt;</div><div>class Callable {</div><div>=C2=A0public:</div><div>=C2=A0 tem=
plate <class Data></div><div>=C2=A0 Callable(Data data) requires</div=
><div>=C2=A0 =C2=A0 =C2=A0 requires(Data data, Args... args) { { data(std::=
move(args)...) } -> R; }</div><div>=C2=A0 =C2=A0 =C2=A0 : data_(new Impl=
ementation<Data>(std::<wbr>move(data))) {}</div><div>=C2=A0 Callable(=
) =3D default;</div><div>=C2=A0 Callable(Callable&&) =3D default;</=
div><div>=C2=A0 Callable(const Callable&) =3D default;</div><div>=C2=A0=
Callable& operator=3D(Callable&&) =3D default;</div><div>=C2=
=A0 Callable& operator=3D(const Callable&) =3D default;</div><div><=
br></div></font></div></code></div></div></div><div dir=3D"ltr"><div><div s=
tyle=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;background-c=
olor:rgb(250,250,250)"><code><div><font color=3D"#660066"><div>=C2=A0 <b>R =
operator()(Args... args) { return data_->op_0(std::move(args)...<wbr>); =
}</b></div><div><br></div><div>=C2=A0private:</div><div>=C2=A0 class Abstra=
ction {</div><div>=C2=A0 =C2=A0public:</div><div>=C2=A0 =C2=A0 <b>virtual R=
op_0(Args&&...) =3D 0;</b></div></font></div></code></div></div></=
div><div dir=3D"ltr"><div><div style=3D"border:1px solid rgb(187,187,187);w=
ord-wrap:break-word;background-color:rgb(250,250,250)"><code><div><font col=
or=3D"#660066"><div>=C2=A0 =C2=A0 virtual ~Abstraction() {}</div><div>=C2=
=A0 };</div><div><br></div><div>=C2=A0 template <class Data></div><di=
v>=C2=A0 class Implementation final : public Abstraction {</div><div>=C2=A0=
=C2=A0public:</div><div>=C2=A0 =C2=A0 Implementation(Data&& data) =
: data_(std::forward<Data>(data)<wbr>) {}</div></font></div></code></=
div></div></div><div dir=3D"ltr"><div><div style=3D"border:1px solid rgb(18=
7,187,187);word-wrap:break-word;background-color:rgb(250,250,250)"><code><d=
iv><font color=3D"#660066"><div>=C2=A0 =C2=A0 <b>R op_0(Args&&... a=
rgs) override { return data_(std::forward<Args>(args)<wbr>...); }</b>=
</div></font></div></code></div></div></div><div dir=3D"ltr"><div><div styl=
e=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;background-colo=
r:rgb(250,250,250)"><code><div><font color=3D"#660066"><div><br></div><div>=
=C2=A0 =C2=A0private:</div><div>=C2=A0 =C2=A0 Data data_;</div><div>=C2=A0 =
};</div><div><br></div><div>=C2=A0 std::shared_ptr<Abstraction> data_=
;</div><div>};</div></font></div></code></div></div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
8dWhkk2eBQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"8dWhkk2eBQAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@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/e700af7e-aee3-4ba9-b899-2f603fed1e72%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/e700af7e-aee3-4ba9-b899-2f603fed1e72%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/e700af7e-aee3-4ba9-b899-2f603fed1e72%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/e700af7e-aee3-4ba9-<wbr>b899-=
2f603fed1e72%40isocpp.org</a><wbr>.<br>
</blockquote></div>
</blockquote></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/9ee212eb-4037-40c4-94c3-57a9a170a4c3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9ee212eb-4037-40c4-94c3-57a9a170a4c3=
%40isocpp.org</a>.<br />
------=_Part_2299_1687278531.1494228658752--
------=_Part_2298_1052276866.1494228658752--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 08 May 2017 07:54:07 -0700
Raw View
On Monday, 8 May 2017 00:30:58 PDT Mingxin Wang wrote:
> Unlike the "*Concespts*" that work at compile time, the
> "*Interfaces*" work at runtime mostly. In essence, it is not only
> a syntactic sugar, but a style of implementation for *polymorphism*:
> virtual functions are only generated when required at runtime
"virtual functions generated at runtime" needs A LOT of explanation. Please
explain how the compiler would implement such a thing.
i also recommend finding another name for your feature. "interface" is a widely
known term and means something else: it means a base class with virtuals that
need to be overridden.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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/1765502.4y06pMOS3s%40tjmaciei-mobl1.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 8 May 2017 08:16:23 -0700 (PDT)
Raw View
------=_Part_3882_756654383.1494256584134
Content-Type: multipart/alternative;
boundary="----=_Part_3883_1322722543.1494256584134"
------=_Part_3883_1322722543.1494256584134
Content-Type: text/plain; charset=UTF-8
On Monday, May 8, 2017 at 10:54:13 AM UTC-4, Thiago Macieira wrote:
>
> On Monday, 8 May 2017 00:30:58 PDT Mingxin Wang wrote:
> > Unlike the "*Concespts*" that work at compile time, the
> > "*Interfaces*" work at runtime mostly. In essence, it is not only
> > a syntactic sugar, but a style of implementation for *polymorphism*:
> > virtual functions are only generated when required at runtime
>
> "virtual functions generated at runtime" needs A LOT of explanation.
> Please
> explain how the compiler would implement such a thing.
>
> i also recommend finding another name for your feature. "interface" is a
> widely
> known term and means something else: it means a base class with virtuals
> that
> need to be overridden.
>
I think the idea that he's trying to get across is the following.
An `interface` is a class which is implicitly convertible from any type
which matches some concept. The implicit conversion effectively works by
storing a type-erased pointer/reference to the object it is converted from.
The concept it matches is defined by the set of member functions in the
`interface`. The `interface` class will automatically generate matching
member functions which forward calls to the type-erased pointer/reference.
So it's not a "virtual" call in the language sense; it's a virtual call in
the polymorphic sense.
I like the idea of being able to take a concept and turn it into a type
that can type-erase any type that matches the concept. This allows you to
turn a compile-time polymorphism tool into a runtime polymorphism tool. But
if you want to do it directly through concepts, then this should include
more than just member functions. The type-erasure/code generation now needs
to include any operations specified by the concept, including overloaded
operators, global ADL functions, and the like.
I would also want to see some way of defining copy/move behavior. That is,
whether the conversion to the "interface" type will create its own object
(like `any` or `function`) or whether it will just reference an existing
one, as well as specifying whether the type is move-only or copyable.
--
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/e8fb03f4-8c94-46c2-a612-acab81117998%40isocpp.org.
------=_Part_3883_1322722543.1494256584134
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, May 8, 2017 at 10:54:13 AM UTC-4, Thiago Maciei=
ra wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Monday, 8 May 2017=
00:30:58 PDT Mingxin Wang wrote:
<br>> Unlike the "*Concespts*" that work at compile time, the
<br>> "*Interfaces*" work at runtime mostly. In essence, it is=
not only
<br>> a syntactic sugar, but a style of implementation for *polymorphism=
*:
<br>> virtual functions are only generated when required at runtime
<br>
<br>"virtual functions generated at runtime" needs A LOT of expla=
nation. Please=20
<br>explain how the compiler would implement such a thing.
<br>
<br>i also recommend finding another name for your feature. "interface=
" is a widely=20
<br>known term and means something else: it means a base class with virtual=
s that=20
<br>need to be overridden.<br></blockquote><div><br>I think the idea that h=
e's trying to get across is the following.<br><br>An `interface` is a c=
lass which is implicitly convertible from any type which matches some conce=
pt. The implicit conversion effectively works by storing a type-erased poin=
ter/reference to the object it is converted from.<br><br>The concept it mat=
ches is defined by the set of member functions in the `interface`. The `int=
erface` class will automatically generate matching member functions which f=
orward calls to the type-erased pointer/reference.<br><br>So it's not a=
"virtual" call in the language sense; it's a virtual call in=
the polymorphic sense.<br><br>I like the idea of being able to take a conc=
ept and turn it into a type that can type-erase any type that matches the c=
oncept. This allows you to turn a compile-time polymorphism tool into a run=
time polymorphism tool. But if you want to do it directly through concepts,=
then this should include more than just member functions. The type-erasure=
/code generation now needs to include any operations specified by the conce=
pt, including overloaded operators, global ADL functions, and the like.<br>=
<br>I would also want to see some way of defining copy/move behavior. That =
is, whether the conversion to the "interface" type will create it=
s own object (like `any` or `function`) or whether it will just reference a=
n existing one, as well as specifying whether the type is move-only or copy=
able.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/e8fb03f4-8c94-46c2-a612-acab81117998%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e8fb03f4-8c94-46c2-a612-acab81117998=
%40isocpp.org</a>.<br />
------=_Part_3883_1322722543.1494256584134--
------=_Part_3882_756654383.1494256584134--
.
Author: Mingxin Wang <wmx16835vv@163.com>
Date: Mon, 8 May 2017 09:41:02 -0700 (PDT)
Raw View
------=_Part_1158_532019526.1494261663031
Content-Type: multipart/alternative;
boundary="----=_Part_1159_1316095975.1494261663031"
------=_Part_1159_1316095975.1494261663031
Content-Type: text/plain; charset=UTF-8
Thanks for your concise explanation!
Overloads are allowed in interfaces, but different overloads may access the
same actual member function in an implementation. For example:
interface Foo {
void f();
int f(int);
};
class FooImpl {
public:
char f(double = 0.0);
};
Thus an interface *only requires the expressions to be well-formed*, and
does not restrict the definitions of implementations. *That is how the
standard defines type requirements.*
Besides, *there are two optional and specific expressions* (which is not
included in my initial post), one is "*[[interface]] copy()*", the other is
"*[[interface]] move()*", as is shown below:
interface Foo {
Foo copy();
Foo move();
};
The two expressions correspond to the copy constructor and the move
constructor in the implementations, respectively. Similar with member
functions, declarations of the two expressions may also introduce extra
runtime overhead.
Any type shall be *MoveConstructible* when converting to an interface.
Every instantiated interfaces copy-constructed from one (with the copy
constructor of the interface, rather than the "copy" expression) share a
same entity.
Thank you!
Mingxin Wang
On Monday, May 8, 2017 at 11:16:24 PM UTC+8, Nicol Bolas wrote:
>
> On Monday, May 8, 2017 at 10:54:13 AM UTC-4, Thiago Macieira wrote:
>>
>> On Monday, 8 May 2017 00:30:58 PDT Mingxin Wang wrote:
>> > Unlike the "*Concespts*" that work at compile time, the
>> > "*Interfaces*" work at runtime mostly. In essence, it is not only
>> > a syntactic sugar, but a style of implementation for *polymorphism*:
>> > virtual functions are only generated when required at runtime
>>
>> "virtual functions generated at runtime" needs A LOT of explanation.
>> Please
>> explain how the compiler would implement such a thing.
>>
>> i also recommend finding another name for your feature. "interface" is a
>> widely
>> known term and means something else: it means a base class with virtuals
>> that
>> need to be overridden.
>>
>
> I think the idea that he's trying to get across is the following.
>
> An `interface` is a class which is implicitly convertible from any type
> which matches some concept. The implicit conversion effectively works by
> storing a type-erased pointer/reference to the object it is converted from.
>
> The concept it matches is defined by the set of member functions in the
> `interface`. The `interface` class will automatically generate matching
> member functions which forward calls to the type-erased pointer/reference.
>
> So it's not a "virtual" call in the language sense; it's a virtual call in
> the polymorphic sense.
>
> I like the idea of being able to take a concept and turn it into a type
> that can type-erase any type that matches the concept. This allows you to
> turn a compile-time polymorphism tool into a runtime polymorphism tool. But
> if you want to do it directly through concepts, then this should include
> more than just member functions. The type-erasure/code generation now needs
> to include any operations specified by the concept, including overloaded
> operators, global ADL functions, and the like.
>
> I would also want to see some way of defining copy/move behavior. That is,
> whether the conversion to the "interface" type will create its own object
> (like `any` or `function`) or whether it will just reference an existing
> one, as well as specifying whether the type is move-only or copyable.
>
--
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/6140e709-d4ba-4038-85bc-329d5f04a5f5%40isocpp.org.
------=_Part_1159_1316095975.1494261663031
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><font face=3D"georgia, serif">Thanks for your=C2=A0co=
ncise</font><span style=3D"font-family: georgia, serif;">=C2=A0explanation!=
</span></div><div><font face=3D"georgia, serif"><br></font></div><div><font=
face=3D"georgia, serif">Overloads are allowed in interfaces, but different=
overloads may access the same actual member function in an implementation.=
For example:</font></div><div><font face=3D"georgia, serif"><br></font></d=
iv><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"><font color=3D"#660066"=
><div class=3D"subprettyprint">interface Foo {</div><div class=3D"subpretty=
print">=C2=A0 void f();</div><div class=3D"subprettyprint">=C2=A0 int f(int=
);</div><div class=3D"subprettyprint">};</div><div class=3D"subprettyprint"=
><br></div><div class=3D"subprettyprint">class FooImpl {</div><div class=3D=
"subprettyprint">=C2=A0public:</div><div class=3D"subprettyprint">=C2=A0 ch=
ar f(double =3D 0.0);</div><div class=3D"subprettyprint">};</div></font></d=
iv></code></div><font face=3D"georgia, serif"><br>Thus an interface <b>only=
requires the expressions to be well-formed</b>, and does not=C2=A0restrict=
=C2=A0the definitions of implementations. <b>That is how the standard defin=
es type requirements.</b></font></div><div><font face=3D"georgia, serif"><b=
r></font></div><font face=3D"georgia, serif">Besides, <b>there are two=C2=
=A0optional and specific=C2=A0expressions</b> (which is not included in my =
initial post), one is "<b>[[interface]] copy()</b>", the other is=
"<b>[[interface]] move()</b>", as is shown below:</font><div><fo=
nt face=3D"georgia, serif"><br></font></div><div><font face=3D"georgia, ser=
if"><div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187=
); word-wrap: break-word; background-color: rgb(250, 250, 250);"><code clas=
s=3D"prettyprint"><div class=3D"subprettyprint"><div class=3D"subprettyprin=
t">interface Foo {</div><div class=3D"subprettyprint">=C2=A0 Foo copy();</d=
iv><div class=3D"subprettyprint">=C2=A0 Foo move();</div><div class=3D"subp=
rettyprint">};</div></div></code></div><br>The two expressions correspond t=
o the copy constructor and the move constructor in the implementations, res=
pectively. Similar with member functions, declarations of the two expressio=
ns may also introduce extra runtime overhead.</font></div><div><div><font f=
ace=3D"georgia, serif"><br></font></div><div><font face=3D"georgia, serif">=
Any type shall be=C2=A0<b>MoveConstructible</b>=C2=A0when converting to an =
interface. Every instantiated=C2=A0</font><span style=3D"font-family: georg=
ia, serif;">interfaces copy-constructed from one (with the copy constructor=
of the interface, rather than the "copy" expression) share a sam=
e entity.</span></div><div><span style=3D"font-family: georgia, serif;"><br=
></span></div><div><span style=3D"font-family: georgia, serif;">Thank you!<=
/span></div><div><span style=3D"font-family: georgia, serif;"><br></span></=
div><div><span style=3D"font-family: georgia, serif;">Mingxin Wang</span></=
div><div><br>On Monday, May 8, 2017 at 11:16:24 PM UTC+8, Nicol Bolas wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Monday, M=
ay 8, 2017 at 10:54:13 AM UTC-4, Thiago Macieira wrote:<blockquote class=3D=
"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex">On Monday, 8 May 2017 00:30:58 PDT Mingxin Wang wrote:
<br>> Unlike the "*Concespts*" that work at compile time, the
<br>> "*Interfaces*" work at runtime mostly. In essence, it is=
not only
<br>> a syntactic sugar, but a style of implementation for *polymorphism=
*:
<br>> virtual functions are only generated when required at runtime
<br>
<br>"virtual functions generated at runtime" needs A LOT of expla=
nation. Please=20
<br>explain how the compiler would implement such a thing.
<br>
<br>i also recommend finding another name for your feature. "interface=
" is a widely=20
<br>known term and means something else: it means a base class with virtual=
s that=20
<br>need to be overridden.<br></blockquote><div><br>I think the idea that h=
e's trying to get across is the following.<br><br>An `interface` is a c=
lass which is implicitly convertible from any type which matches some conce=
pt. The implicit conversion effectively works by storing a type-erased poin=
ter/reference to the object it is converted from.<br><br>The concept it mat=
ches is defined by the set of member functions in the `interface`. The `int=
erface` class will automatically generate matching member functions which f=
orward calls to the type-erased pointer/reference.<br><br>So it's not a=
"virtual" call in the language sense; it's a virtual call in=
the polymorphic sense.<br><br>I like the idea of being able to take a conc=
ept and turn it into a type that can type-erase any type that matches the c=
oncept. This allows you to turn a compile-time polymorphism tool into a run=
time polymorphism tool. But if you want to do it directly through concepts,=
then this should include more than just member functions. The type-erasure=
/code generation now needs to include any operations specified by the conce=
pt, including overloaded operators, global ADL functions, and the like.<br>=
<br>I would also want to see some way of defining copy/move behavior. That =
is, whether the conversion to the "interface" type will create it=
s own object (like `any` or `function`) or whether it will just reference a=
n existing one, as well as specifying whether the type is move-only or copy=
able.<br></div></div></blockquote></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/6140e709-d4ba-4038-85bc-329d5f04a5f5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6140e709-d4ba-4038-85bc-329d5f04a5f5=
%40isocpp.org</a>.<br />
------=_Part_1159_1316095975.1494261663031--
------=_Part_1158_532019526.1494261663031--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Mon, 8 May 2017 16:11:35 -0400
Raw View
--f403045f2ed6a0c634054f08d81f
Content-Type: text/plain; charset="UTF-8"
On Mon, May 8, 2017 at 11:16 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Monday, May 8, 2017 at 10:54:13 AM UTC-4, Thiago Macieira wrote:
>>
>> On Monday, 8 May 2017 00:30:58 PDT Mingxin Wang wrote:
>> > Unlike the "*Concespts*" that work at compile time, the
>> > "*Interfaces*" work at runtime mostly. In essence, it is not only
>> > a syntactic sugar, but a style of implementation for *polymorphism*:
>> > virtual functions are only generated when required at runtime
>>
>> "virtual functions generated at runtime" needs A LOT of explanation.
>> Please
>> explain how the compiler would implement such a thing.
>>
>> i also recommend finding another name for your feature. "interface" is a
>> widely
>> known term and means something else: it means a base class with virtuals
>> that
>> need to be overridden.
>>
>
> I think the idea that he's trying to get across is the following.
>
> An `interface` is a class which is implicitly convertible from any type
> which matches some concept. The implicit conversion effectively works by
> storing a type-erased pointer/reference to the object it is converted from.
>
Yep, I think we are talking about automatic type-erasure here.
Sean Parent has done a lot of work with type-erasure and polymorphic values
types based on "concepts" (pre Concepts concepts).
I wonder if Concepts + reflection might allow someone to write:
Foo foo; // foo happens to model Concept
std::erased<Concept> efoo = foo;
func(efoo); // Not a templatized function
Tony
>
> The concept it matches is defined by the set of member functions in the
> `interface`. The `interface` class will automatically generate matching
> member functions which forward calls to the type-erased pointer/reference.
>
> So it's not a "virtual" call in the language sense; it's a virtual call in
> the polymorphic sense.
>
> I like the idea of being able to take a concept and turn it into a type
> that can type-erase any type that matches the concept. This allows you to
> turn a compile-time polymorphism tool into a runtime polymorphism tool. But
> if you want to do it directly through concepts, then this should include
> more than just member functions. The type-erasure/code generation now needs
> to include any operations specified by the concept, including overloaded
> operators, global ADL functions, and the like.
>
> I would also want to see some way of defining copy/move behavior. That is,
> whether the conversion to the "interface" type will create its own object
> (like `any` or `function`) or whether it will just reference an existing
> one, as well as specifying whether the type is move-only or copyable.
>
> --
> 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/e8fb03f4-8c94-46c2-
> a612-acab81117998%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e8fb03f4-8c94-46c2-a612-acab81117998%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
Be seeing you,
Tony
--
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/CAOHCbiswurpbE6tG3igWTsFfpJ%3DLAeT9PoTUZBNsrnMOhEwSxQ%40mail.gmail.com.
--f403045f2ed6a0c634054f08d81f
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">On Mon, May 8, 2017 at 11:16 AM, Nicol Bolas <span dir=3D"ltr"><<a h=
ref=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a=
>></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"><spa=
n class=3D"">On Monday, May 8, 2017 at 10:54:13 AM UTC-4, Thiago Macieira w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;=
border-left:1px #ccc solid;padding-left:1ex">On Monday, 8 May 2017 00:30:58=
PDT Mingxin Wang wrote:
<br>> Unlike the "*Concespts*" that work at compile time, the
<br>> "*Interfaces*" work at runtime mostly. In essence, it is=
not only
<br>> a syntactic sugar, but a style of implementation for *polymorphism=
*:
<br>> virtual functions are only generated when required at runtime
<br>
<br>"virtual functions generated at runtime" needs A LOT of expla=
nation. Please=20
<br>explain how the compiler would implement such a thing.
<br>
<br>i also recommend finding another name for your feature. "interface=
" is a widely=20
<br>known term and means something else: it means a base class with virtual=
s that=20
<br>need to be overridden.<br></blockquote></span><div><br>I think the idea=
that he's trying to get across is the following.<br><br>An `interface`=
is a class which is implicitly convertible from any type which matches som=
e concept. The implicit conversion effectively works by storing a type-eras=
ed pointer/reference to the object it is converted from.<br></div></div></b=
lockquote><div><br><br></div><div>Yep, I think we are talking about automat=
ic type-erasure here.<br><br></div><div>Sean Parent has done a lot of work =
with type-erasure and polymorphic values types based on "concepts"=
; (pre Concepts concepts).<br><br></div><div>I wonder if Concepts + reflect=
ion might allow someone to write:<br><br></div><div>Foo foo; // foo happens=
to model Concept<br></div><div>std::erased<Concept> efoo =3D foo;<br=
></div><div>func(efoo);=C2=A0 // Not a templatized function<br></div><div><=
br></div><div>Tony<br></div><div>=C2=A0<br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr"><div><br>The concept it matches is defined by the set=
of member functions in the `interface`. The `interface` class will automat=
ically generate matching member functions which forward calls to the type-e=
rased pointer/reference.<br><br>So it's not a "virtual" call =
in the language sense; it's a virtual call in the polymorphic sense.<br=
><br>I like the idea of being able to take a concept and turn it into a typ=
e that can type-erase any type that matches the concept. This allows you to=
turn a compile-time polymorphism tool into a runtime polymorphism tool. Bu=
t if you want to do it directly through concepts, then this should include =
more than just member functions. The type-erasure/code generation now needs=
to include any operations specified by the concept, including overloaded o=
perators, global ADL functions, and the like.<br><br>I would also want to s=
ee some way of defining copy/move behavior. That is, whether the conversion=
to the "interface" type will create its own object (like `any` o=
r `function`) or whether it will just reference an existing one, as well as=
specifying whether the type is move-only or copyable.<br></div></div><span=
class=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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@<wbr>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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e8fb03f4-8c94-46c2-a612-acab81117998%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/e8fb=
03f4-8c94-46c2-<wbr>a612-acab81117998%40isocpp.org</a><wbr>.<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
nature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div>Be seeing =
you,<br></div>Tony<br></div></div>
</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CAOHCbiswurpbE6tG3igWTsFfpJ%3DLAeT9Po=
TUZBNsrnMOhEwSxQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiswurpbE6=
tG3igWTsFfpJ%3DLAeT9PoTUZBNsrnMOhEwSxQ%40mail.gmail.com</a>.<br />
--f403045f2ed6a0c634054f08d81f--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 8 May 2017 13:44:58 -0700 (PDT)
Raw View
------=_Part_4619_1861128834.1494276299009
Content-Type: multipart/alternative;
boundary="----=_Part_4620_753737676.1494276299009"
------=_Part_4620_753737676.1494276299009
Content-Type: text/plain; charset=UTF-8
On Monday, May 8, 2017 at 4:11:38 PM UTC-4, Tony V E wrote:
>
> On Mon, May 8, 2017 at 11:16 AM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> On Monday, May 8, 2017 at 10:54:13 AM UTC-4, Thiago Macieira wrote:
>>>
>>> On Monday, 8 May 2017 00:30:58 PDT Mingxin Wang wrote:
>>> > Unlike the "*Concespts*" that work at compile time, the
>>> > "*Interfaces*" work at runtime mostly. In essence, it is not only
>>> > a syntactic sugar, but a style of implementation for *polymorphism*:
>>> > virtual functions are only generated when required at runtime
>>>
>>> "virtual functions generated at runtime" needs A LOT of explanation.
>>> Please
>>> explain how the compiler would implement such a thing.
>>>
>>> i also recommend finding another name for your feature. "interface" is a
>>> widely
>>> known term and means something else: it means a base class with virtuals
>>> that
>>> need to be overridden.
>>>
>>
>> I think the idea that he's trying to get across is the following.
>>
>> An `interface` is a class which is implicitly convertible from any type
>> which matches some concept. The implicit conversion effectively works by
>> storing a type-erased pointer/reference to the object it is converted from.
>>
>
>
> Yep, I think we are talking about automatic type-erasure here.
>
> Sean Parent has done a lot of work with type-erasure and polymorphic
> values types based on "concepts" (pre Concepts concepts).
>
> I wonder if Concepts + reflection might allow someone to write:
>
> Foo foo; // foo happens to model Concept
> std::erased<Concept> efoo = foo;
> func(efoo); // Not a templatized function
>
> Tony
>
That would require lots of things that don't exist at present:
1: Reflection to be able to introspect concepts, being able to iterate over
their constituent expressions.
2: Reflection would need to be able to *generate* code. Otherwise,
`std::erased` wouldn't be able to generate non-member functions to handle
non-members of the `Concept`.
3: Concepts would have to be able to be passed as template parameters.
--
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/6bfa8a30-a2c4-46d5-8ac2-c0353408a041%40isocpp.org.
------=_Part_4620_753737676.1494276299009
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, May 8, 2017 at 4:11:38 PM UTC-4, Tony V E wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div cl=
ass=3D"gmail_quote">On Mon, May 8, 2017 at 11:16 AM, Nicol Bolas <span dir=
=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"LK3lovSECAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascr=
ipt:';return true;" onclick=3D"this.href=3D'javascript:';return=
true;">jmck...@gmail.com</a>></span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><span>On Monday, May 8, 2017 at 10:54:13 AM UTC-4, =
Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;m=
argin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On Monday, 8 =
May 2017 00:30:58 PDT Mingxin Wang wrote:
<br>> Unlike the "*Concespts*" that work at compile time, the
<br>> "*Interfaces*" work at runtime mostly. In essence, it is=
not only
<br>> a syntactic sugar, but a style of implementation for *polymorphism=
*:
<br>> virtual functions are only generated when required at runtime
<br>
<br>"virtual functions generated at runtime" needs A LOT of expla=
nation. Please=20
<br>explain how the compiler would implement such a thing.
<br>
<br>i also recommend finding another name for your feature. "interface=
" is a widely=20
<br>known term and means something else: it means a base class with virtual=
s that=20
<br>need to be overridden.<br></blockquote></span><div><br>I think the idea=
that he's trying to get across is the following.<br><br>An `interface`=
is a class which is implicitly convertible from any type which matches som=
e concept. The implicit conversion effectively works by storing a type-eras=
ed pointer/reference to the object it is converted from.<br></div></div></b=
lockquote><div><br><br></div><div>Yep, I think we are talking about automat=
ic type-erasure here.<br><br></div><div>Sean Parent has done a lot of work =
with type-erasure and polymorphic values types based on "concepts"=
; (pre Concepts concepts).<br><br></div><div>I wonder if Concepts + reflect=
ion might allow someone to write:<br><br></div><div>Foo foo; // foo happens=
to model Concept<br></div><div>std::erased<Concept> efoo =3D foo;<br=
></div><div>func(efoo);=C2=A0 // Not a templatized function<br></div><div><=
br></div><div>Tony<br></div></div></div></div></blockquote><div><br>That wo=
uld require lots of things that don't exist at present:<br><br>1: Refle=
ction to be able to introspect concepts, being able to iterate over their c=
onstituent expressions.<br><br>2: Reflection would need to be able to <i>ge=
nerate</i> code. Otherwise, `std::erased` wouldn't be able to generate =
non-member functions to handle non-members of the `Concept`.<br><br>3: Conc=
epts would have to be able to be passed as template parameters.<br></div></=
div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/6bfa8a30-a2c4-46d5-8ac2-c0353408a041%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6bfa8a30-a2c4-46d5-8ac2-c0353408a041=
%40isocpp.org</a>.<br />
------=_Part_4620_753737676.1494276299009--
------=_Part_4619_1861128834.1494276299009--
.
Author: Jakob Riedle <jakob.riedle@gmail.com>
Date: Mon, 8 May 2017 13:48:54 -0700 (PDT)
Raw View
------=_Part_2457_1611138434.1494276534876
Content-Type: multipart/alternative;
boundary="----=_Part_2458_1204108005.1494276534876"
------=_Part_2458_1204108005.1494276534876
Content-Type: text/plain; charset=UTF-8
At first I was very skeptical of the proposal to add something that I
though to be already in the language.
The topic being discussed here now seems to me the missing link between
concepts and type erasure!!
Thank you Mingxin Wang!
Foo foo; // foo happens to model Concept
> std::erased<Concept> efoo = foo;
> func(efoo); // Not a templatized function
>
Nice idea!
Can we make that even more awesome?? YES!!
How about this:
void func(){
// ...
}
int main(){
// Here the concept 'Callable' is used at a non-deduced context (where no
deduction happens)
// Therefore, the Concept will automatically be interpreted as an abstract
class to which other types can be type erased to.
std::vector<Callable> myVec;
myVec.emplace( &func );
}
class MyClass{
std::vector<Callable> myVec; // same applies here since we are in an
undeduced context
void set_vector( std::vector<Callable> newVec ){ // This is still a
function template where Callable might be deduced as std::function<void()>
myVec = std::move(newVec); // Here an implicit conversion happens from
the potentially specialized vector (e.g.
std::vector<std::function<void()>>) to the vector of type erased Callables
}
}
Whenever compile time type deduction *can *happen, it will, *analog to
contextpr*.
This is both very efficient and intuitive if you think about it.
Another example might be helpful:
void do_something( std::vector<Callable> vec ){
// ...
}
std::vector<Callable> foo1;
std::vector<std::function<void()>> foo2;
do_something( foo1 ); // 'vec' will stay a vector of type erased Callables
do_something( foo2 ); // 'vec' will be deduced to
std::vector<std::function<void()>>
Again: Everything that can be deduced at compile time will and everything
that cannot will be deferred to run time.
Since this interpretation of concepts as implicit base classes only happens
in undeduced contexts (this is currently not allowed), its not breaking
code.
How 'bout that???
Cheers,
Jakob
--
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/45a81e95-d352-49ab-9c6e-7375aa41413c%40isocpp.org.
------=_Part_2458_1204108005.1494276534876
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>At first I was very skeptical of the proposal to add =
something that I though to be already in the language.<br></div><div>The to=
pic being discussed here now seems to me the missing link between concepts =
and type erasure!!</div><div><br></div><div>Thank you Mingxin Wang!</div><d=
iv><b><br></b></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><div><div dir=3D"ltr"><div>Foo foo; // foo happens to model C=
oncept<br></div><div>std::erased<Concept> efoo =3D foo;<br></div><div=
>func(efoo);=C2=A0 // Not a templatized function</div></div></div></div></d=
iv></blockquote><div>Nice idea!</div><div><br></div><div>Can we make that e=
ven more awesome?? YES!!</div><div><br></div><div>How about this:</div><div=
><br></div><div class=3D"prettyprint" style=3D"background-color: rgb(250, 2=
50, 250); border-color: rgb(187, 187, 187); border-style: solid; border-wid=
th: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"=
subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">v=
oid</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> func</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">(){</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0</span><s=
pan style=3D"color: #800;" 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;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> main</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(){</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br></span><span style=3D"color: #800;" class=3D"styled-by=
-prettify">// Here the concept 'Callable' is used at a non-deduced =
context (where no deduction happens)</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br></span><span style=3D"color: #800;" class=3D"=
styled-by-prettify">// Therefore, the Concept will automatically be interpr=
eted as an abstract class to which other types can be type erased to.</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>std</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">vector</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify"><</span><span style=3D"color=
: #606;" class=3D"styled-by-prettify">Callable</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">></span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> myVec</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br>myVec</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">emplace</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">&</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">func </span><span s=
tyle=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;" c=
lass=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">class</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-b=
y-prettify">MyClass</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br>=C2=A0std</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">vecto=
r</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><</spa=
n><span style=3D"color: #606;" class=3D"styled-by-prettify">Callable</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">></span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> myVec</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;"=
class=3D"styled-by-prettify">// same applies here since we are in an unded=
uced context</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br><br>=C2=A0</span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">void</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
set_vector</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>(</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify">vector</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=3D"=
color: #606;" class=3D"styled-by-prettify">Callable</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">></span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> newVec </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">){</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"styl=
ed-by-prettify">// This is still a function template where Callable might b=
e deduced as std::function<void()></span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"><br>=C2=A0 myVec </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"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">move</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>newVec</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #800;" class=3D"styled-by-prettify">// Here an implicit =
conversion happens from the potentially specialized vector (e.g. std::vecto=
r<std::function<void()>>) to the vector of type erased Callable=
s</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=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></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>Whenever compile time type deduction <b>can </b>happen, =
it will, <b>analog to contextpr</b>.</div><div>This is both very efficient =
and intuitive if you think about it.</div><div>Another example might be hel=
pful:</div><div><br></div><div class=3D"prettyprint" style=3D"background-co=
lor: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: so=
lid; border-width: 1px; word-wrap: break-word;"><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"> do_something</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">vector</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span=
style=3D"color: #606;" class=3D"styled-by-prettify">Callable</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">></span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> vec </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: #800;" c=
lass=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><br>std</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">vector</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&l=
t;</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Callable=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">></span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> foo1</span><spa=
n 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><span style=3D"color: =
#000;" class=3D"styled-by-prettify">vector</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify"><</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">std</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">::</span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">function</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify"><</span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">void</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()&=
gt;></span><span style=3D"color: #000;" class=3D"styled-by-prettify"> fo=
o2</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>do_someth=
ing</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> foo1 </span><sp=
an 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">// 'vec' will stay a vector o=
f type erased Callables</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br>do_something</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> foo2 </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #800;" class=3D"styled-by-prettify">// 'vec=
' will be deduced to std::vector<std::function<void()>></sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></d=
iv></code></div><div><br></div>Again: Everything that can be deduced at com=
pile time will and everything that cannot will be deferred to run time.<div=
>Since this interpretation of concepts as implicit base classes only happen=
s in undeduced contexts (this is currently not allowed), its not breaking c=
ode.</div><div><br></div><div>How 'bout that???</div><div><br></div><di=
v>Cheers,</div><div>Jakob</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/45a81e95-d352-49ab-9c6e-7375aa41413c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/45a81e95-d352-49ab-9c6e-7375aa41413c=
%40isocpp.org</a>.<br />
------=_Part_2458_1204108005.1494276534876--
------=_Part_2457_1611138434.1494276534876--
.
Author: Jakob Riedle <jakob.riedle@gmail.com>
Date: Mon, 8 May 2017 13:56:40 -0700 (PDT)
Raw View
------=_Part_2492_46489696.1494277000366
Content-Type: multipart/alternative;
boundary="----=_Part_2493_820509099.1494277000366"
------=_Part_2493_820509099.1494277000366
Content-Type: text/plain; charset=UTF-8
Sorry, I forgot, that all 'Callable' should be written as
'Callable<void()>'. Still, all points made here hold.
Further detail:
// Example for a templated class
template<typename T>
shared_ptr{
// ...
};
shared_ptr<Callable<void()>> myPtr; // Callable<void()> happens to be in an
undeduced context, so it can function as an actual type!! Yay!
--
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/ef9b6397-89f7-4122-9963-69cdb92c337c%40isocpp.org.
------=_Part_2493_820509099.1494277000366
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Sorry, I forgot, that all 'Callable' should be wri=
tten as 'Callable<void()>'. Still, all points made here hold.=
<div><br></div><div>Further detail:</div><div class=3D"prettyprint" style=
=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187);=
border-style: solid; border-width: 1px; word-wrap: break-word;"><code clas=
s=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #800;=
" class=3D"styled-by-prettify">// Example for a templated class</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">template</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">typename</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> T</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">></span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br>shared_ptr</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</span><span style=3D"color: #800;" class=3D"=
styled-by-prettify">// ...</span><span style=3D"color: #000;" class=3D"styl=
ed-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><br>shared_ptr</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify"><</span><span style=3D"color: #606;" class=3D"styled-by-pr=
ettify">Callable</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify"><</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"> myPtr=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">// Callable<void()> ha=
ppens to be in an undeduced context, so it can function as an actual type!!=
Yay!</span></div></code></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" 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/ef9b6397-89f7-4122-9963-69cdb92c337c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ef9b6397-89f7-4122-9963-69cdb92c337c=
%40isocpp.org</a>.<br />
------=_Part_2493_820509099.1494277000366--
------=_Part_2492_46489696.1494277000366--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 08 May 2017 14:19:53 -0700
Raw View
Em segunda-feira, 8 de maio de 2017, =C3=A0s 13:44:58 PDT, Nicol Bolas escr=
eveu:
> That would require lots of things that don't exist at present:
>=20
> 1: Reflection to be able to introspect concepts, being able to iterate ov=
er
> their constituent expressions.
>=20
> 2: Reflection would need to be able to *generate* code. Otherwise,
> `std::erased` wouldn't be able to generate non-member functions to handle
> non-members of the `Concept`.
>=20
> 3: Concepts would have to be able to be passed as template parameters.
You're probably right.
The question is: is this the direction to go? If not or if any of the above=
is=20
not likely to ever happen, do we need a different solution to the request?
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/2854090.YvNT7KsjMe%40tjmaciei-mobl1.
.
Author: Barry Revzin <barry.revzin@gmail.com>
Date: Mon, 8 May 2017 14:27:33 -0700 (PDT)
Raw View
------=_Part_461_1955525736.1494278854028
Content-Type: multipart/alternative;
boundary="----=_Part_462_819523458.1494278854028"
------=_Part_462_819523458.1494278854028
Content-Type: text/plain; charset=UTF-8
>
> Yep, I think we are talking about automatic type-erasure here.
>>
>> Sean Parent has done a lot of work with type-erasure and polymorphic
>> values types based on "concepts" (pre Concepts concepts).
>>
>> I wonder if Concepts + reflection might allow someone to write:
>>
>> Foo foo; // foo happens to model Concept
>> std::erased<Concept> efoo = foo;
>> func(efoo); // Not a templatized function
>>
>> Tony
>>
>
> That would require lots of things that don't exist at present:
>
> 1: Reflection to be able to introspect concepts, being able to iterate
> over their constituent expressions.
>
> 2: Reflection would need to be able to *generate* code. Otherwise,
> `std::erased` wouldn't be able to generate non-member functions to handle
> non-members of the `Concept`.
>
> 3: Concepts would have to be able to be passed as template parameters.
>
Yeah, but I'd argue it's really what you want. Type erasure is extremely
useful, Concepts already express the desired interface, so it's really
natural to stick them together. It'd be pretty valuable to either:
(1) be able to write a library that works like erased<Concept> (e.g. Rust's
Box)
(2) provide a mechanism in the language to implicitly generate such a
thing, whether by
(2a) reappropriating the abbreviated function syntax to do type erasure
instead, or
(2b) providing a new syntax like void foo(Concept^ )
Any of those approaches requires a lot of stuff that we don't have today,
and won't have on day 1 on any of these TSes hitting, but I think are worth
considering longer term as next steps for cool problems to solve with
Concepts.
--
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/9ef42c60-5709-4472-97f0-e68fb9960840%40isocpp.org.
------=_Part_462_819523458.1494278854028
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"=
><div>Yep, I think we are talking about automatic type-erasure here.<br></d=
iv><div><br></div><div>Sean Parent has done a lot of work with type-erasure=
and polymorphic values types based on "concepts" (pre Concepts c=
oncepts).<br><br></div><div>I wonder if Concepts + reflection might allow s=
omeone to write:<br><br></div><div>Foo foo; // foo happens to model Concept=
<br></div><div>std::erased<Concept> efoo =3D foo;<br></div><div>func(=
efoo);=C2=A0 // Not a templatized function<br></div><div><br></div><div>Ton=
y<br></div></div></div></div></blockquote><div><br>That would require lots =
of things that don't exist at present:<br><br>1: Reflection to be able =
to introspect concepts, being able to iterate over their constituent expres=
sions.<br><br>2: Reflection would need to be able to <i>generate</i> code. =
Otherwise, `std::erased` wouldn't be able to generate non-member functi=
ons to handle non-members of the `Concept`.<br><br>3: Concepts would have t=
o be able to be passed as template parameters.<br></div></div></blockquote>=
<div><br></div><div>Yeah, but I'd argue it's really what you want. =
Type erasure is extremely useful, Concepts already express the desired inte=
rface, so it's really natural to stick them together. It'd be prett=
y valuable to either:</div><div><br></div><div>(1) be able to write a libra=
ry that works like erased<Concept> (e.g. Rust's Box)</div><div>(2=
) provide a mechanism in the language to implicitly generate such a thing, =
whether by</div><div>(2a) reappropriating the abbreviated function syntax t=
o do type erasure instead, or=C2=A0</div><div>(2b) providing a new syntax l=
ike void foo(Concept^ )=C2=A0</div><div><br></div><div>Any of those approac=
hes requires a lot of stuff that we don't have today, and won't hav=
e on day 1 on any of these TSes hitting, but I think are worth considering =
longer term as next steps for cool problems to solve with Concepts.</div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/9ef42c60-5709-4472-97f0-e68fb9960840%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9ef42c60-5709-4472-97f0-e68fb9960840=
%40isocpp.org</a>.<br />
------=_Part_462_819523458.1494278854028--
------=_Part_461_1955525736.1494278854028--
.
Author: Myriachan <myriachan@gmail.com>
Date: Mon, 8 May 2017 15:20:32 -0700 (PDT)
Raw View
------=_Part_2072_1819407438.1494282033024
Content-Type: multipart/alternative;
boundary="----=_Part_2073_587365658.1494282033025"
------=_Part_2073_587365658.1494282033025
Content-Type: text/plain; charset=UTF-8
On Monday, May 8, 2017 at 2:27:34 PM UTC-7, Barry Revzin wrote:
>
> (2a) reappropriating the abbreviated function syntax to do type erasure
> instead, or
> (2b) providing a new syntax like void foo(Concept^ )
>
I think you'll get a lot of resistance from Microsoft about adding either
an "interface" keyword or a caret pointer-like syntax. Microsoft uses
both, like it or not.
--
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/d2292627-81b3-4973-a7c8-32082901ec8d%40isocpp.org.
------=_Part_2073_587365658.1494282033025
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, May 8, 2017 at 2:27:34 PM UTC-7, Barry Revzin w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">(2a) reappropriating the =
abbreviated function syntax to do type erasure instead, or=C2=A0<div>(2b) p=
roviding a new syntax like void foo(Concept^ )=C2=A0</div></blockquote><br>=
I think you'll get a lot of resistance from Microsoft about adding eith=
er an "interface" keyword or a caret pointer-like syntax.=C2=A0 M=
icrosoft uses both, like it or not.<br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/d2292627-81b3-4973-a7c8-32082901ec8d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d2292627-81b3-4973-a7c8-32082901ec8d=
%40isocpp.org</a>.<br />
------=_Part_2073_587365658.1494282033025--
------=_Part_2072_1819407438.1494282033024--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 8 May 2017 19:34:42 -0700 (PDT)
Raw View
------=_Part_6350_194552734.1494297282631
Content-Type: multipart/alternative;
boundary="----=_Part_6351_919357046.1494297282631"
------=_Part_6351_919357046.1494297282631
Content-Type: text/plain; charset=UTF-8
I do not like the idea of having a concept name be used to implicitly
invoke runtime polymorphism of this nature. After all, we're talking about
the generation of a *specific type* which has specific behavior.
`vector<Callable<void()>>::value_type` needs to be a specific type (one
that is the same in all translation units), and it's probably best that
this type have a well-defined name. And that name can't be
`Callable<void()>`.
Or to put it another way, let's not confuse people about when we're using
runtime polymorphism and compile-time polymorphism. If you want
compile-time polymorphism, you use the concept. If you want runtime, then
you use a type that is generated by the concept.
--
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/522f7362-6ab9-4bf2-b634-b584c0ee62c3%40isocpp.org.
------=_Part_6351_919357046.1494297282631
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I do not like the idea of having a concept name be used to=
implicitly invoke runtime polymorphism of this nature. After all, we'r=
e talking about the generation of a <i>specific type</i> which has specific=
behavior. `vector<Callable<void()>>::value_type` needs to be a=
specific type (one that is the same in all translation units), and it'=
s probably best that this type have a well-defined name. And that name can&=
#39;t be `Callable<void()>`.<br><br>Or to put it another way, let'=
;s not confuse people about when we're using runtime polymorphism and c=
ompile-time polymorphism. If you want compile-time polymorphism, you use th=
e concept. If you want runtime, then you use a type that is generated by th=
e concept.<br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/522f7362-6ab9-4bf2-b634-b584c0ee62c3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/522f7362-6ab9-4bf2-b634-b584c0ee62c3=
%40isocpp.org</a>.<br />
------=_Part_6351_919357046.1494297282631--
------=_Part_6350_194552734.1494297282631--
.
Author: Magnus Fromreide <magfr@lysator.liu.se>
Date: Tue, 9 May 2017 07:00:57 +0200
Raw View
On Mon, May 08, 2017 at 08:16:23AM -0700, Nicol Bolas wrote:
> On Monday, May 8, 2017 at 10:54:13 AM UTC-4, Thiago Macieira wrote:
> >
> > On Monday, 8 May 2017 00:30:58 PDT Mingxin Wang wrote:
> > > Unlike the "*Concespts*" that work at compile time, the
> > > "*Interfaces*" work at runtime mostly. In essence, it is not only
> > > a syntactic sugar, but a style of implementation for *polymorphism*:
> > > virtual functions are only generated when required at runtime
> >
> > "virtual functions generated at runtime" needs A LOT of explanation.
> > Please
> > explain how the compiler would implement such a thing.
> >
> > i also recommend finding another name for your feature. "interface" is a
> > widely
> > known term and means something else: it means a base class with virtuals
> > that
> > need to be overridden.
> >
>
> I think the idea that he's trying to get across is the following.
>
> An `interface` is a class which is implicitly convertible from any type
> which matches some concept. The implicit conversion effectively works by
> storing a type-erased pointer/reference to the object it is converted from.
>
> The concept it matches is defined by the set of member functions in the
> `interface`. The `interface` class will automatically generate matching
> member functions which forward calls to the type-erased pointer/reference.
>
> So it's not a "virtual" call in the language sense; it's a virtual call in
> the polymorphic sense.
So, is this yet another reinvention of the old "signature" extension of G++?
https://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC112
/MF
--
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/20170509050057.GA1227%40noemi.
.
Author: Mingxin Wang <wmx16835vv@163.com>
Date: Mon, 8 May 2017 23:10:15 -0700 (PDT)
Raw View
------=_Part_758_274165352.1494310215176
Content-Type: multipart/alternative;
boundary="----=_Part_759_1725561650.1494310215177"
------=_Part_759_1725561650.1494310215177
Content-Type: text/plain; charset=UTF-8
Dear Mr. Riedle,
Thank you for your recognition!
I have thought about the idea you posted about possible compile-time
deduction, and I found it is *positive *for compiler optimization, but it
shall not be abused. For example:
Callable<void()> a([] { puts("Lambda"); });
a();
is OK to be compiled (after compiler optimization) as
puts("Lambda");
But
std::vector<function<void()>> a;
std::vector<Callable<void()>> b(a);
is ill-formed.
An interface is a type, like integral types, classes, lambda expressions,
etc. The reason why the code above is ill-formed is similar with the code
below (also ill-formed):
std::vector<int> a;
std::vector<double> b(a);
Thank you!
Mingxin Wang
On Tuesday, May 9, 2017 at 4:48:55 AM UTC+8, Jakob Riedle wrote:
>
> At first I was very skeptical of the proposal to add something that I
> though to be already in the language.
> The topic being discussed here now seems to me the missing link between
> concepts and type erasure!!
>
> Thank you Mingxin Wang!
>
> Foo foo; // foo happens to model Concept
>> std::erased<Concept> efoo = foo;
>> func(efoo); // Not a templatized function
>>
> Nice idea!
>
> Can we make that even more awesome?? YES!!
>
> How about this:
>
> void func(){
> // ...
> }
>
> int main(){
> // Here the concept 'Callable' is used at a non-deduced context (where no
> deduction happens)
> // Therefore, the Concept will automatically be interpreted as an abstract
> class to which other types can be type erased to.
> std::vector<Callable> myVec;
> myVec.emplace( &func );
> }
>
> class MyClass{
> std::vector<Callable> myVec; // same applies here since we are in an
> undeduced context
>
> void set_vector( std::vector<Callable> newVec ){ // This is still a
> function template where Callable might be deduced as std::function<void()>
> myVec = std::move(newVec); // Here an implicit conversion happens from
> the potentially specialized vector (e.g.
> std::vector<std::function<void()>>) to the vector of type erased Callables
> }
> }
>
> Whenever compile time type deduction *can *happen, it will, *analog to
> contextpr*.
> This is both very efficient and intuitive if you think about it.
> Another example might be helpful:
>
> void do_something( std::vector<Callable> vec ){
> // ...
> }
>
> std::vector<Callable> foo1;
> std::vector<std::function<void()>> foo2;
>
> do_something( foo1 ); // 'vec' will stay a vector of type erased Callables
> do_something( foo2 ); // 'vec' will be deduced to
> std::vector<std::function<void()>>
>
> Again: Everything that can be deduced at compile time will and everything
> that cannot will be deferred to run time.
> Since this interpretation of concepts as implicit base classes only
> happens in undeduced contexts (this is currently not allowed), its not
> breaking code.
>
> How 'bout that???
>
> Cheers,
> Jakob
>
--
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/d832c461-fa3e-429e-a36b-1d0b11eb634f%40isocpp.org.
------=_Part_759_1725561650.1494310215177
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><font face=3D"georgia, serif">Dear Mr.=C2=A0Riedle,</=
font></div><div><font face=3D"georgia, serif"><br></font></div><div><font f=
ace=3D"georgia, serif">Thank you for your recognition!</font><br></div><div=
><font face=3D"georgia, serif"><br></font></div><div><font face=3D"georgia,=
serif">I have thought about the idea</font><span style=3D"font-family: geo=
rgia, serif;">=C2=A0you posted</span><span style=3D"font-family: georgia, s=
erif;">=C2=A0</span><span style=3D"font-family: georgia, serif;">about=C2=
=A0possible compile-time deduction</span><span style=3D"font-family: georgi=
a, serif;">, and I found it is=C2=A0</span><span style=3D"font-family: geor=
gia, serif; line-height: 17px;"><b>positive </b>for=C2=A0compiler optimizat=
ion, but it shall not be abused. For example:</span></div><div><span style=
=3D"font-family: georgia, serif; line-height: 17px;"><br></span></div><div>=
<span style=3D"font-family: georgia, serif; line-height: 17px;"><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"><div class=3D"subprettyprint">Callable<=
;void()> a([] { puts("Lambda"); });</div><div class=3D"subpret=
typrint">a();</div></div></code></div><br>is OK to be compiled</span><span =
style=3D"font-family: georgia, serif; line-height: 17px;">=C2=A0(after=C2=
=A0</span><span style=3D"font-family: georgia, serif; line-height: 17px;">c=
ompiler optimization</span><span style=3D"font-family: georgia, serif; line=
-height: 17px;">)</span><span style=3D"font-family: georgia, serif; line-he=
ight: 17px;">=C2=A0as</span></div><div><span style=3D"font-family: georgia,=
serif; line-height: 17px;"><br></span></div><div><div class=3D"prettyprint=
" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; bac=
kground-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><font color=3D"#660066"><span style=3D"line-height: 17p=
x;">puts("Lambda");</span></font><br></div></code></div><br><font=
face=3D"georgia, serif">But</font></div><div><font face=3D"georgia, serif"=
><br></font></div><div><font face=3D"georgia, serif"><div class=3D"prettypr=
int" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; =
background-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div cla=
ss=3D"subprettyprint"><div class=3D"subprettyprint">std::vector<function=
<void()>> a;</div><div class=3D"subprettyprint">std::vector<Cal=
lable<void()>> b(a);</div></div></code></div><br>is=C2=A0ill-forme=
d.</font></div><div><font face=3D"georgia, serif"><br></font></div><font fa=
ce=3D"georgia, serif">An interface is a type, like=C2=A0integral types,=C2=
=A0classes, lambda expressions, etc. The reason why the code above is=C2=A0=
</font><span style=3D"font-family: georgia, serif;">ill-formed</span><font =
face=3D"georgia, serif">=C2=A0is similar with the code below (also ill-form=
ed):</font><div><font face=3D"georgia, serif"><br></font></div><div><font f=
ace=3D"georgia, serif"><div class=3D"prettyprint" style=3D"border: 1px soli=
d rgb(187, 187, 187); word-wrap: break-word; background-color: rgb(250, 250=
, 250);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><div cla=
ss=3D"subprettyprint">std::vector<int> a;</div><div class=3D"subprett=
yprint">std::vector<double> b(a);</div></div></code></div><div><font =
face=3D"georgia, serif"><br></font></div>Thank you!</font></div><div><font =
face=3D"georgia, serif"><br></font></div><div><font face=3D"georgia, serif"=
>Mingxin Wang<br></font><br>On Tuesday, May 9, 2017 at 4:48:55 AM UTC+8, Ja=
kob Riedle wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div>At first I was very skeptical of the proposal to add something tha=
t I though to be already in the language.<br></div><div>The topic being dis=
cussed here now seems to me the missing link between concepts and type eras=
ure!!</div><div><br></div><div>Thank you Mingxin Wang!</div><div><b><br></b=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div><=
div dir=3D"ltr"><div>Foo foo; // foo happens to model Concept<br></div><div=
>std::erased<Concept> efoo =3D foo;<br></div><div>func(efoo);=C2=A0 /=
/ Not a templatized function</div></div></div></div></div></blockquote><div=
>Nice idea!</div><div><br></div><div>Can we make that even more awesome?? Y=
ES!!</div><div><br></div><div>How about this:</div><div><br></div><div styl=
e=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);border=
-style:solid;border-width:1px;word-wrap:break-word"><code><div><span style=
=3D"color:#008">void</span><span style=3D"color:#000"> func</span><span sty=
le=3D"color:#660">(){</span><span style=3D"color:#000"><br>=C2=A0</span><sp=
an style=3D"color:#800">// ...</span><span style=3D"color:#000"><br></span>=
<span style=3D"color:#660">}</span><span style=3D"color:#000"><br><br></spa=
n><span style=3D"color:#008">int</span><span style=3D"color:#000"> main</sp=
an><span style=3D"color:#660">(){</span><span style=3D"color:#000"><br></sp=
an><span style=3D"color:#800">// Here the concept 'Callable' is use=
d at a non-deduced context (where no deduction happens)</span><span style=
=3D"color:#000"><br></span><span style=3D"color:#800">// Therefore, the Con=
cept will automatically be interpreted as an abstract class to which other =
types can be type erased to.</span><span style=3D"color:#000"><br>std</span=
><span style=3D"color:#660">::</span><span style=3D"color:#000">vector</spa=
n><span style=3D"color:#660"><</span><span style=3D"color:#606">Callable=
</span><span style=3D"color:#660">></span><span style=3D"color:#000"> my=
Vec</span><span style=3D"color:#660">;</span><span style=3D"color:#000"><br=
>myVec</span><span style=3D"color:#660">.</span><span style=3D"color:#000">=
emplace</span><span style=3D"color:#660">(</span><span style=3D"color:#000"=
> </span><span style=3D"color:#660">&</span><span style=3D"color:#000">=
func </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"><b=
r><br></span><span style=3D"color:#008">class</span><span style=3D"color:#0=
00"> </span><span style=3D"color:#606">MyClass</span><span style=3D"color:#=
660">{</span><span style=3D"color:#000"><br>=C2=A0std</span><span style=3D"=
color:#660">::</span><span style=3D"color:#000">vector</span><span style=3D=
"color:#660"><</span><span style=3D"color:#606">Callable</span><span sty=
le=3D"color:#660">></span><span style=3D"color:#000"> myVec</span><span =
style=3D"color:#660">;</span><span style=3D"color:#000"> </span><span style=
=3D"color:#800">// same applies here since we are in an undeduced context</=
span><span style=3D"color:#000"><br><br>=C2=A0</span><span style=3D"color:#=
008">void</span><span style=3D"color:#000"> set_vector</span><span style=3D=
"color:#660">(</span><span style=3D"color:#000"> std</span><span style=3D"c=
olor:#660">::</span><span style=3D"color:#000">vector</span><span style=3D"=
color:#660"><</span><span style=3D"color:#606">Callable</span><span styl=
e=3D"color:#660">></span><span style=3D"color:#000"> newVec </span><span=
style=3D"color:#660">){</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#800">// This is still a function template where Callable might=
be deduced as std::function<void()></span><span style=3D"color:#000"=
><br>=C2=A0 myVec </span><span style=3D"color:#660">=3D</span><span style=
=3D"color:#000"> std</span><span style=3D"color:#660">::</span><span style=
=3D"color:#000">move</span><span style=3D"color:#660">(</span><span style=
=3D"color:#000">newVec</span><span style=3D"color:#660">);</span><span styl=
e=3D"color:#000"> </span><span style=3D"color:#800">// Here an implicit con=
version happens from the potentially specialized vector (e.g. std::vector&l=
t;std::function<<wbr>void()>>) to the vector of type erased Callab=
les</span><span style=3D"color:#000"><br>=C2=A0</span><span style=3D"color:=
#660">}</span><span style=3D"color:#000"><br></span><span style=3D"color:#6=
60">}</span><span style=3D"color:#000"><br></span></div></code></div><div><=
br></div><div>Whenever compile time type deduction <b>can </b>happen, it wi=
ll, <b>analog to contextpr</b>.</div><div>This is both very efficient and i=
ntuitive if you think about it.</div><div>Another example might be helpful:=
</div><div><br></div><div style=3D"background-color:rgb(250,250,250);border=
-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:break=
-word"><code><div><span style=3D"color:#008">void</span><span style=3D"colo=
r:#000"> do_something</span><span style=3D"color:#660">(</span><span style=
=3D"color:#000"> std</span><span style=3D"color:#660">::</span><span style=
=3D"color:#000">vector</span><span style=3D"color:#660"><</span><span st=
yle=3D"color:#606">Callable</span><span style=3D"color:#660">></span><sp=
an style=3D"color:#000"> vec </span><span style=3D"color:#660">){</span><sp=
an style=3D"color:#000"><br></span><span style=3D"color:#800">// ...</span>=
<span style=3D"color:#000"><br></span><span style=3D"color:#660">}</span><s=
pan style=3D"color:#000"><br><br>std</span><span style=3D"color:#660">::</s=
pan><span style=3D"color:#000">vector</span><span style=3D"color:#660"><=
</span><span style=3D"color:#606">Callable</span><span style=3D"color:#660"=
>></span><span style=3D"color:#000"> foo1</span><span style=3D"color:#66=
0">;</span><span style=3D"color:#000"><br>std</span><span style=3D"color:#6=
60">::</span><span style=3D"color:#000">vector</span><span style=3D"color:#=
660"><</span><span style=3D"color:#000">std</span><span style=3D"color:#=
660">::</span><span style=3D"color:#008">function</span><span style=3D"colo=
r:#660"><</span><span style=3D"color:#008">void</span><span style=3D"col=
or:#660"><wbr>()>></span><span style=3D"color:#000"> foo2</span><span=
style=3D"color:#660">;</span><span style=3D"color:#000"><br><br>do_somethi=
ng</span><span style=3D"color:#660">(</span><span style=3D"color:#000"> foo=
1 </span><span style=3D"color:#660">);</span><span style=3D"color:#000"> </=
span><span style=3D"color:#800">// 'vec' will stay a vector of type=
erased Callables</span><span style=3D"color:#000"><br>do_something</span><=
span style=3D"color:#660">(</span><span style=3D"color:#000"> foo2 </span><=
span style=3D"color:#660">);</span><span style=3D"color:#000"> </span><span=
style=3D"color:#800">// 'vec' will be deduced to std::vector<st=
d::function<<wbr>void()>></span><span style=3D"color:#000"><br></s=
pan></div></code></div><div><br></div>Again: Everything that can be deduced=
at compile time will and everything that cannot will be deferred to run ti=
me.<div>Since this interpretation of concepts as implicit base classes only=
happens in undeduced contexts (this is currently not allowed), its not bre=
aking code.</div><div><br></div><div>How 'bout that???</div><div><br></=
div><div>Cheers,</div><div>Jakob</div></div></blockquote></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/d832c461-fa3e-429e-a36b-1d0b11eb634f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d832c461-fa3e-429e-a36b-1d0b11eb634f=
%40isocpp.org</a>.<br />
------=_Part_759_1725561650.1494310215177--
------=_Part_758_274165352.1494310215176--
.
Author: Mingxin Wang <wmx16835vv@163.com>
Date: Mon, 8 May 2017 23:36:20 -0700 (PDT)
Raw View
------=_Part_7056_14373624.1494311780082
Content-Type: multipart/alternative;
boundary="----=_Part_7057_853067923.1494311780082"
------=_Part_7057_853067923.1494311780082
Content-Type: text/plain; charset=UTF-8
Dear Mr. Fromreide,
The "*signatures*" in G++ is a *syntactic sugar* that introduces new rules
for declaring virtual member functions. The "*interfaces*" is not only a
syntactic sugar, but a style of implementation for polymorphism, enabling
types that meet specific requirements implicitly convertible to a same type
at runtime.
In short, we used to write virtual functions (or "signatures") *manually *to
implement polymorphism, but now we can use the "interfaces" to *generate*
efficient implementations for polymorphism based on our requirements.
Thank you!
Mingxin Wang
On Tuesday, May 9, 2017 at 1:01:02 PM UTC+8, Magnus Fromreide wrote:
>
> On Mon, May 08, 2017 at 08:16:23AM -0700, Nicol Bolas wrote:
> > On Monday, May 8, 2017 at 10:54:13 AM UTC-4, Thiago Macieira wrote:
> > >
> > > On Monday, 8 May 2017 00:30:58 PDT Mingxin Wang wrote:
> > > > Unlike the "*Concespts*" that work at compile time, the
> > > > "*Interfaces*" work at runtime mostly. In essence, it is not only
> > > > a syntactic sugar, but a style of implementation for *polymorphism*:
> > > > virtual functions are only generated when required at runtime
> > >
> > > "virtual functions generated at runtime" needs A LOT of explanation.
> > > Please
> > > explain how the compiler would implement such a thing.
> > >
> > > i also recommend finding another name for your feature. "interface" is
> a
> > > widely
> > > known term and means something else: it means a base class with
> virtuals
> > > that
> > > need to be overridden.
> > >
> >
> > I think the idea that he's trying to get across is the following.
> >
> > An `interface` is a class which is implicitly convertible from any type
> > which matches some concept. The implicit conversion effectively works by
> > storing a type-erased pointer/reference to the object it is converted
> from.
> >
> > The concept it matches is defined by the set of member functions in the
> > `interface`. The `interface` class will automatically generate matching
> > member functions which forward calls to the type-erased
> pointer/reference.
> >
> > So it's not a "virtual" call in the language sense; it's a virtual call
> in
> > the polymorphic sense.
>
> So, is this yet another reinvention of the old "signature" extension of
> G++?
>
> https://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC112
>
> /MF
>
--
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/6edad2ff-ea7e-4b26-bf65-0311e63e7633%40isocpp.org.
------=_Part_7057_853067923.1494311780082
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><font face=3D"georgia, serif" size=3D"2">Dear Mr. Fromreid=
e,</font><div><font face=3D"georgia, serif" size=3D"2"><br></font></div><di=
v><font size=3D"2"><font face=3D"georgia, serif">The "<b>signatures</b=
></font><span style=3D"font-family: georgia, serif;">" in G++ is a=C2=
=A0</span><font face=3D"georgia, serif"><b>syntactic sugar</b> that introdu=
ces new rules for declaring virtual member functions. The "<b>interfac=
es</b>"=C2=A0is not only a syntactic sugar, but a style of implementat=
ion for polymorphism, enabling types that meet specific requirements implic=
itly convertible to a same type at runtime.</font></font></div><div><font f=
ace=3D"georgia, serif" size=3D"2"><br></font></div><div><font size=3D"2"><f=
ont face=3D"georgia, serif">In short, we used to write virtual functions (o=
r=C2=A0</font><font face=3D"georgia, serif">"signatures</font><span st=
yle=3D"font-family: georgia, serif;">"</span><font face=3D"georgia, se=
rif">)=C2=A0<b>manually=C2=A0</b>to implement=C2=A0</font><span style=3D"fo=
nt-family: georgia, serif;">polymorphism, but now we can use the "inte=
rfaces" to <b>generate</b>=C2=A0</span></font><font face=3D"georgia, s=
erif" size=3D"2">efficient</font><span style=3D"font-family: georgia, serif=
;">=C2=A0</span><font face=3D"georgia, serif" style=3D"font-size: small;">i=
mplementations for=C2=A0</font><span style=3D"font-size: small; font-family=
: georgia, serif;">polymorphism based on our requirements.</span></div><div=
><div><font face=3D"georgia, serif"><br></font></div><div><font face=3D"geo=
rgia, serif">Thank you!</font></div><div><font face=3D"georgia, serif"><br>=
</font></div><div><font face=3D"georgia, serif">Mingxin Wang</font></div><d=
iv><br>On Tuesday, May 9, 2017 at 1:01:02 PM UTC+8, Magnus Fromreide wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;">On Mon, May 08, 2017 at 08:16:=
23AM -0700, Nicol Bolas wrote:
<br>> On Monday, May 8, 2017 at 10:54:13 AM UTC-4, Thiago Macieira wrote=
:
<br>> >
<br>> > On Monday, 8 May 2017 00:30:58 PDT Mingxin Wang wrote:=20
<br>> > > Unlike the "*Concespts*" that work at compile =
time, the=20
<br>> > > "*Interfaces*" work at runtime mostly. In esse=
nce, it is not only=20
<br>> > > a syntactic sugar, but a style of implementation for *po=
lymorphism*:=20
<br>> > > virtual functions are only generated when required at ru=
ntime=20
<br>> >
<br>> > "virtual functions generated at runtime" needs A LO=
T of explanation.=20
<br>> > Please=20
<br>> > explain how the compiler would implement such a thing.=20
<br>> >
<br>> > i also recommend finding another name for your feature. "=
;interface" is a=20
<br>> > widely=20
<br>> > known term and means something else: it means a base class wi=
th virtuals=20
<br>> > that=20
<br>> > need to be overridden.
<br>> >
<br>>=20
<br>> I think the idea that he's trying to get across is the followi=
ng.
<br>>=20
<br>> An `interface` is a class which is implicitly convertible from any=
type=20
<br>> which matches some concept. The implicit conversion effectively wo=
rks by=20
<br>> storing a type-erased pointer/reference to the object it is conver=
ted from.
<br>>=20
<br>> The concept it matches is defined by the set of member functions i=
n the=20
<br>> `interface`. The `interface` class will automatically generate mat=
ching=20
<br>> member functions which forward calls to the type-erased pointer/re=
ference.
<br>>=20
<br>> So it's not a "virtual" call in the language sense; =
it's a virtual call in=20
<br>> the polymorphic sense.
<br>
<br>So, is this yet another reinvention of the old "signature" ex=
tension of G++?
<br>
<br><a href=3D"https://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC112"=
target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'https:/=
/www.google.com/url?q\x3dhttps%3A%2F%2Fgcc.gnu.org%2Fonlinedocs%2Fgcc-2.95.=
3%2Fgcc_5.html%23SEC112\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEw4-Ehkly2R=
WPS0OVrE2Arh1XgYw';return true;" onclick=3D"this.href=3D'https://ww=
w.google.com/url?q\x3dhttps%3A%2F%2Fgcc.gnu.org%2Fonlinedocs%2Fgcc-2.95.3%2=
Fgcc_5.html%23SEC112\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEw4-Ehkly2RWPS=
0OVrE2Arh1XgYw';return true;">https://gcc.gnu.org/<wbr>onlinedocs/gcc-2=
..95.3/gcc_5.<wbr>html#SEC112</a>
<br>
<br>/MF
<br></blockquote></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/6edad2ff-ea7e-4b26-bf65-0311e63e7633%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6edad2ff-ea7e-4b26-bf65-0311e63e7633=
%40isocpp.org</a>.<br />
------=_Part_7057_853067923.1494311780082--
------=_Part_7056_14373624.1494311780082--
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Tue, 9 May 2017 00:17:59 -0700 (PDT)
Raw View
------=_Part_4462_2115638637.1494314279677
Content-Type: multipart/alternative;
boundary="----=_Part_4463_1417322570.1494314279678"
------=_Part_4463_1417322570.1494314279678
Content-Type: text/plain; charset=UTF-8
* I think you are over-using the word "runtime" here. As I understand it
what's happening is duck-typing: When the compiler sees that a variable of
some type T is used where an interface I is required it checks if the T at
hand contains all the methods specified by I. If so it generates (at
compile time) a virtual function table suitable for I which contains
pointers to the corresponding functions of T. In the case that the
corresponding function is virtual and the variable is a reference it seems
most reasonable to generate a stub function which implements a virtual call
to the T function using the variable value as "this".
* Reusing Concepts as interfaces is a appealing idea but we have already
seen in this thread what a can of worms this opens, unfortunately. If
anyone can disentangle this into a manageable set of rules I would be all
for it, but the problems pointed out, that a concept can contain
requirements for free functions, types etc, and thus the virtual pointer
table is not enough to express the resulting polymorphism.
* Maybe the keyword interface can be introduced as a contextual keyword for
this purpose, as in:
struct MyInterface interface {
// only methods allowed
};
Maybe the methods should have to be declared virtual inside this construct
or maybe they are virtual by default.
* I don't think that the ownership/lifetime issues should be mixed with
this duck-typing feature, instead the signature of the (non-template)
function to be called should express this as in:
void Fun1(MyInterface& p);
void Fun2(std::unique_ptr<MyInterface> p);
Ok, this does not work: while ownership of the p object is established by
the signatures above the ownership of the original object is unclear. And
they can't be the same object as the p object has to consist of the
(generated) virtual function table and the pointer to the original object
(with some unknown ownership). This said, it is too weak of an idea to
automatically infer unique_ptr or shared_ptr as suggested earlier in this
thread. A very common case will be 'no ownership', i.e. a reference to a
stack object or similar, and user defined smart pointer templates. Some
kind of traits class should be able to act as a customization point to
indicate how p relates to the original object.
Den tisdag 9 maj 2017 kl. 08:36:20 UTC+2 skrev Mingxin Wang:
>
> Dear Mr. Fromreide,
>
> The "*signatures*" in G++ is a *syntactic sugar* that introduces new
> rules for declaring virtual member functions. The "*interfaces*" is not
> only a syntactic sugar, but a style of implementation for polymorphism,
> enabling types that meet specific requirements implicitly convertible to a
> same type at runtime.
>
> In short, we used to write virtual functions (or "signatures") *manually *to
> implement polymorphism, but now we can use the "interfaces" to *generate*
> efficient implementations for polymorphism based on our requirements.
>
> Thank you!
>
> Mingxin Wang
>
> On Tuesday, May 9, 2017 at 1:01:02 PM UTC+8, Magnus Fromreide wrote:
>>
>> On Mon, May 08, 2017 at 08:16:23AM -0700, Nicol Bolas wrote:
>> > On Monday, May 8, 2017 at 10:54:13 AM UTC-4, Thiago Macieira wrote:
>> > >
>> > > On Monday, 8 May 2017 00:30:58 PDT Mingxin Wang wrote:
>> > > > Unlike the "*Concespts*" that work at compile time, the
>> > > > "*Interfaces*" work at runtime mostly. In essence, it is not only
>> > > > a syntactic sugar, but a style of implementation for
>> *polymorphism*:
>> > > > virtual functions are only generated when required at runtime
>> > >
>> > > "virtual functions generated at runtime" needs A LOT of explanation.
>> > > Please
>> > > explain how the compiler would implement such a thing.
>> > >
>> > > i also recommend finding another name for your feature. "interface"
>> is a
>> > > widely
>> > > known term and means something else: it means a base class with
>> virtuals
>> > > that
>> > > need to be overridden.
>> > >
>> >
>> > I think the idea that he's trying to get across is the following.
>> >
>> > An `interface` is a class which is implicitly convertible from any type
>> > which matches some concept. The implicit conversion effectively works
>> by
>> > storing a type-erased pointer/reference to the object it is converted
>> from.
>> >
>> > The concept it matches is defined by the set of member functions in the
>> > `interface`. The `interface` class will automatically generate matching
>> > member functions which forward calls to the type-erased
>> pointer/reference.
>> >
>> > So it's not a "virtual" call in the language sense; it's a virtual call
>> in
>> > the polymorphic sense.
>>
>> So, is this yet another reinvention of the old "signature" extension of
>> G++?
>>
>> https://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC112
>>
>> /MF
>>
>
--
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/db7aa7af-ac88-4ba7-a5f7-94aaf9b7ebfd%40isocpp.org.
------=_Part_4463_1417322570.1494314279678
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">* I think you are over-using the word "runtime" =
here. As I understand it what's happening is duck-typing: When the comp=
iler sees that a variable of some type T is used where an interface I is re=
quired it checks if the T at hand contains all the methods specified by I. =
If so it generates (at compile time) a virtual function table suitable for =
I which contains pointers to the corresponding functions of T. In the case =
that the corresponding function is virtual and the variable is a reference =
it seems most reasonable to generate a stub function which implements a vir=
tual call to the T function using the variable value as "this".<d=
iv><br></div><div>* Reusing Concepts as interfaces is a appealing idea but =
we have already seen in this thread what a can of worms this opens, unfortu=
nately. If anyone can disentangle this into a manageable set of rules I wou=
ld be all for it, but the problems pointed out, that a concept can contain =
requirements for free functions, types etc, and thus the virtual pointer ta=
ble is not enough to express the resulting polymorphism.</div><div><br></di=
v><div>* Maybe the keyword interface can be introduced as a contextual keyw=
ord for this purpose, as in:</div><div><br></div><div>=C2=A0 =C2=A0 struct =
MyInterface interface {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // onl=
y methods allowed</div><div>=C2=A0 =C2=A0 };</div><div><br></div><div>Maybe=
the methods should have to be declared virtual inside this construct or ma=
ybe they are virtual by default.</div><div><br></div><div>* I don't thi=
nk that the ownership/lifetime issues should be mixed with this duck-typing=
feature, instead the signature of the (non-template) function to be called=
should express this as in:</div><div><br></div><div>=C2=A0 =C2=A0 void Fun=
1(MyInterface& p);</div><div>=C2=A0 =C2=A0 void Fun2(std::unique_ptr<=
;MyInterface> p);</div><div><br></div><div>Ok, this does not work: while=
ownership of the p object is established by the signatures above the owner=
ship of the original object is unclear. And they can't be the same obje=
ct as the p object has to consist of the (generated) virtual function table=
and the pointer to the original object (with some unknown ownership). This=
said, it is too weak of an idea to automatically infer unique_ptr or share=
d_ptr as suggested earlier in this thread. A very common case will be '=
no ownership', i.e. a reference to a stack object or similar, and user =
defined smart pointer templates. Some kind of traits class should be able t=
o act as a customization point to indicate how p relates to the original ob=
ject.<br><div><br><br>Den tisdag 9 maj 2017 kl. 08:36:20 UTC+2 skrev Mingxi=
n Wang:<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"><font =
face=3D"georgia, serif" size=3D"2">Dear Mr. Fromreide,</font><div><font fac=
e=3D"georgia, serif" size=3D"2"><br></font></div><div><font size=3D"2"><fon=
t face=3D"georgia, serif">The "<b>signatures</b></font><span style=3D"=
font-family:georgia,serif">" in G++ is a=C2=A0</span><font face=3D"geo=
rgia, serif"><b>syntactic sugar</b> that introduces new rules for declaring=
virtual member functions. The "<b>interfaces</b>"=C2=A0is not on=
ly a syntactic sugar, but a style of implementation for polymorphism, enabl=
ing types that meet specific requirements implicitly convertible to a same =
type at runtime.</font></font></div><div><font face=3D"georgia, serif" size=
=3D"2"><br></font></div><div><font size=3D"2"><font face=3D"georgia, serif"=
>In short, we used to write virtual functions (or=C2=A0</font><font face=3D=
"georgia, serif">"signatures</font><span style=3D"font-family:georgia,=
serif">"</span><font face=3D"georgia, serif">)=C2=A0<b>manually=C2=A0<=
/b>to implement=C2=A0</font><span style=3D"font-family:georgia,serif">polym=
orphism, but now we can use the "interfaces" to <b>generate</b>=
=C2=A0</span></font><font face=3D"georgia, serif" size=3D"2">efficient</fon=
t><span style=3D"font-family:georgia,serif">=C2=A0</span><font face=3D"geor=
gia, serif" style=3D"font-size:small">implementat<wbr>ions for=C2=A0</font>=
<span style=3D"font-size:small;font-family:georgia,serif">polymorphism base=
d on our requirements.</span></div><div><div><font face=3D"georgia, serif">=
<br></font></div><div><font face=3D"georgia, serif">Thank you!</font></div>=
<div><font face=3D"georgia, serif"><br></font></div><div><font face=3D"geor=
gia, serif">Mingxin Wang</font></div><div><br>On Tuesday, May 9, 2017 at 1:=
01:02 PM UTC+8, Magnus Fromreide wrote:<blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex">On Mon, May 08, 2017 at 08:16:23AM -0700, Nicol Bolas wrote:
<br>> On Monday, May 8, 2017 at 10:54:13 AM UTC-4, Thiago Macieira wrote=
:
<br>> >
<br>> > On Monday, 8 May 2017 00:30:58 PDT Mingxin Wang wrote:=20
<br>> > > Unlike the "*Concespts*" that work at compile =
time, the=20
<br>> > > "*Interfaces*" work at runtime mostly. In esse=
nce, it is not only=20
<br>> > > a syntactic sugar, but a style of implementation for *po=
lymorphism*:=20
<br>> > > virtual functions are only generated when required at ru=
ntime=20
<br>> >
<br>> > "virtual functions generated at runtime" needs A LO=
T of explanation.=20
<br>> > Please=20
<br>> > explain how the compiler would implement such a thing.=20
<br>> >
<br>> > i also recommend finding another name for your feature. "=
;interface" is a=20
<br>> > widely=20
<br>> > known term and means something else: it means a base class wi=
th virtuals=20
<br>> > that=20
<br>> > need to be overridden.
<br>> >
<br>>=20
<br>> I think the idea that he's trying to get across is the followi=
ng.
<br>>=20
<br>> An `interface` is a class which is implicitly convertible from any=
type=20
<br>> which matches some concept. The implicit conversion effectively wo=
rks by=20
<br>> storing a type-erased pointer/reference to the object it is conver=
ted from.
<br>>=20
<br>> The concept it matches is defined by the set of member functions i=
n the=20
<br>> `interface`. The `interface` class will automatically generate mat=
ching=20
<br>> member functions which forward calls to the type-erased pointer/re=
ference.
<br>>=20
<br>> So it's not a "virtual" call in the language sense; =
it's a virtual call in=20
<br>> the polymorphic sense.
<br>
<br>So, is this yet another reinvention of the old "signature" ex=
tension of G++?
<br>
<br><a href=3D"https://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC112"=
rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D'https:/=
/www.google.com/url?q\x3dhttps%3A%2F%2Fgcc.gnu.org%2Fonlinedocs%2Fgcc-2.95.=
3%2Fgcc_5.html%23SEC112\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEw4-Ehkly2R=
WPS0OVrE2Arh1XgYw';return true;" onclick=3D"this.href=3D'https://ww=
w.google.com/url?q\x3dhttps%3A%2F%2Fgcc.gnu.org%2Fonlinedocs%2Fgcc-2.95.3%2=
Fgcc_5.html%23SEC112\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEw4-Ehkly2RWPS=
0OVrE2Arh1XgYw';return true;">https://gcc.gnu.org/<wbr>onlinedocs/gcc-2=
..95.3/gcc_5.<wbr>html#SEC112</a>
<br>
<br>/MF
<br></blockquote></div></div></div></blockquote></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/db7aa7af-ac88-4ba7-a5f7-94aaf9b7ebfd%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/db7aa7af-ac88-4ba7-a5f7-94aaf9b7ebfd=
%40isocpp.org</a>.<br />
------=_Part_4463_1417322570.1494314279678--
------=_Part_4462_2115638637.1494314279677--
.
Author: Mingxin Wang <wmx16835vv@163.com>
Date: Tue, 9 May 2017 01:01:48 -0700 (PDT)
Raw View
------=_Part_4928_340421383.1494316908861
Content-Type: multipart/alternative;
boundary="----=_Part_4929_1991480419.1494316908861"
------=_Part_4929_1991480419.1494316908861
Content-Type: text/plain; charset=UTF-8
Dear Mr. Barry Revzin,
This feature is possible to be implemented with virtual functions and smart
pointers. The "reflections" usually introduces much runtime overhead than
virtual functions, thus I tend to use the latter.
Specifically, I tend to use the following architecture to implement:
<https://lh3.googleusercontent.com/-qA3Nkvys7YE/WRF2vmJ2v9I/AAAAAAAAADk/ToqJoRWyzGEnUt2CvwOfpA76uy5VelMWwCLcB/s1600/Untitled.png>
For example, for a interface Foo:
interface Foo {
Foo copy();
void operator()();
Foo f();
void g(int);
};
The following code may be generated:
class Foo {
public:
template <class Data>
Foo(Data data) requires
MoveConstructible<Data>() &&
requires(Data data, int arg_0) {
{ data() };
{ data.g(std::move(arg_0)) };
} && (requires(Data data) {
{ data.f() } -> Data;
} || requires(Data data) {
{ data.f() } -> Foo;
}) : data_(new Implementation<Data>(std::move(data))) {}
Foo() = default;
Foo(Foo&&) = default;
Foo(const Foo&) = default;
Foo& operator=(Foo&&) = default;
Foo& operator=(const Foo&) = default;
Foo copy() { return data_->op_0(); }
void operator()() { data_->op_1(); };
Foo f() { return data_->op_2(); }
void g(int arg_0) { data_->op_3(std::move(arg_0)); }
private:
class Abstraction {
public:
virtual Foo op_0() = 0;
virtual void op_1() = 0;
virtual Foo op_2() = 0;
virtual void op_3(int&&) = 0;
virtual ~Abstraction() {}
};
template <class Data>
class Implementation final : public Abstraction {
public:
Implementation(Data&& data) : data_(std::forward<Data>(data)) {}
Foo op_0() override { return Data(data_); }
void op_1() override { data_(); }
Foo op_2() override { return data_.f(); }
void op_3(int&& arg_0) override { data_.g(std::forward<int>(arg_0)); }
private:
Data data_;
};
std::shared_ptr<Abstraction> data_;
};
On Tuesday, May 9, 2017 at 5:27:34 AM UTC+8, Barry Revzin wrote:
>
> Yep, I think we are talking about automatic type-erasure here.
>>>
>>> Sean Parent has done a lot of work with type-erasure and polymorphic
>>> values types based on "concepts" (pre Concepts concepts).
>>>
>>> I wonder if Concepts + reflection might allow someone to write:
>>>
>>> Foo foo; // foo happens to model Concept
>>> std::erased<Concept> efoo = foo;
>>> func(efoo); // Not a templatized function
>>>
>>> Tony
>>>
>>
>> That would require lots of things that don't exist at present:
>>
>> 1: Reflection to be able to introspect concepts, being able to iterate
>> over their constituent expressions.
>>
>> 2: Reflection would need to be able to *generate* code. Otherwise,
>> `std::erased` wouldn't be able to generate non-member functions to handle
>> non-members of the `Concept`.
>>
>> 3: Concepts would have to be able to be passed as template parameters.
>>
>
> Yeah, but I'd argue it's really what you want. Type erasure is extremely
> useful, Concepts already express the desired interface, so it's really
> natural to stick them together. It'd be pretty valuable to either:
>
> (1) be able to write a library that works like erased<Concept> (e.g.
> Rust's Box)
> (2) provide a mechanism in the language to implicitly generate such a
> thing, whether by
> (2a) reappropriating the abbreviated function syntax to do type erasure
> instead, or
> (2b) providing a new syntax like void foo(Concept^ )
>
> Any of those approaches requires a lot of stuff that we don't have today,
> and won't have on day 1 on any of these TSes hitting, but I think are worth
> considering longer term as next steps for cool problems to solve with
> Concepts.
>
--
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/d15cc3d3-b526-499d-9b8b-2d4ecd15aba9%40isocpp.org.
------=_Part_4929_1991480419.1494316908861
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><font face=3D"georgia, serif">Dear Mr. Barry Rev=
zin,</font></div><div><font face=3D"georgia, serif"><br></font></div><div><=
font face=3D"georgia, serif">This feature is possible to be implemented wit=
h virtual functions and smart pointers. The "reflections" usually=
introduces much runtime overhead than virtual functions, thus I tend to us=
e the latter.</font></div><div><font face=3D"georgia, serif"><br></font></d=
iv><div><font face=3D"georgia, serif">Specifically, I tend to use the follo=
wing architecture to implement:</font></div></div><div><br></div><p class=
=3D"separator" style=3D"text-align: center; clear: both;"><a imageanchor=3D=
"1" href=3D"https://lh3.googleusercontent.com/-qA3Nkvys7YE/WRF2vmJ2v9I/AAAA=
AAAAADk/ToqJoRWyzGEnUt2CvwOfpA76uy5VelMWwCLcB/s1600/Untitled.png" style=3D"=
margin-left: 1em; margin-right: 1em;"><img src=3D"https://lh3.googleusercon=
tent.com/-qA3Nkvys7YE/WRF2vmJ2v9I/AAAAAAAAADk/ToqJoRWyzGEnUt2CvwOfpA76uy5Ve=
lMWwCLcB/s400/Untitled.png" border=3D"0" width=3D"400" height=3D"142"></a><=
/p><div><font face=3D"georgia, serif"><br></font></div><div><font face=3D"g=
eorgia, serif">For example, for a interface Foo:</font></div><div><font fac=
e=3D"georgia, serif"><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"><div class=
=3D"subprettyprint">interface Foo {</div><div class=3D"subprettyprint">=C2=
=A0 Foo copy();</div><div class=3D"subprettyprint">=C2=A0 void operator()()=
;</div><div class=3D"subprettyprint">=C2=A0 Foo f();</div><div class=3D"sub=
prettyprint">=C2=A0 void g(int);</div><div class=3D"subprettyprint">};</div=
></div></code></div><br>The following code may be generated:</font></div><d=
iv><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"><font color=3D"#660066"><div=
class=3D"subprettyprint">class Foo {</div><div class=3D"subprettyprint">=
=C2=A0public:</div><div class=3D"subprettyprint">=C2=A0 template <class =
Data></div><div class=3D"subprettyprint">=C2=A0 Foo(Data data) requires<=
/div><div class=3D"subprettyprint">=C2=A0 =C2=A0 =C2=A0 MoveConstructible&l=
t;Data>() &&</div><div class=3D"subprettyprint">=C2=A0 =C2=A0 =
=C2=A0 requires(Data data, int arg_0) {</div><div class=3D"subprettyprint">=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 { data() };</div><div class=3D"subprettyprint">=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 { data.g(std::move(arg_0)) };</div><div class=
=3D"subprettyprint">=C2=A0 =C2=A0 =C2=A0 } && (requires(Data data) =
{</div><div class=3D"subprettyprint">=C2=A0 =C2=A0 =C2=A0 =C2=A0 { data.f()=
} -> Data;</div><div class=3D"subprettyprint">=C2=A0 =C2=A0 =C2=A0 } ||=
requires(Data data) {</div><div class=3D"subprettyprint">=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 { data.f() } -> Foo;</div><div class=3D"subprettyprint">=C2=
=A0 =C2=A0 =C2=A0 }) : data_(new Implementation<Data>(std::move(data)=
)) {}</div><div class=3D"subprettyprint">=C2=A0 Foo() =3D default;</div><di=
v class=3D"subprettyprint">=C2=A0 Foo(Foo&&) =3D default;</div><div=
class=3D"subprettyprint">=C2=A0 Foo(const Foo&) =3D default;</div><div=
class=3D"subprettyprint">=C2=A0 Foo& operator=3D(Foo&&) =3D de=
fault;</div><div class=3D"subprettyprint">=C2=A0 Foo& operator=3D(const=
Foo&) =3D default;</div><div class=3D"subprettyprint"><br></div><div c=
lass=3D"subprettyprint">=C2=A0 Foo copy() { return data_->op_0(); }</div=
><div class=3D"subprettyprint">=C2=A0 void operator()() { data_->op_1();=
};</div><div class=3D"subprettyprint">=C2=A0 Foo f() { return data_->op=
_2(); }</div><div class=3D"subprettyprint">=C2=A0 void g(int arg_0) { data_=
->op_3(std::move(arg_0)); }</div><div class=3D"subprettyprint"><br></div=
><div class=3D"subprettyprint">=C2=A0private:</div><div class=3D"subprettyp=
rint">=C2=A0 class Abstraction {</div><div class=3D"subprettyprint">=C2=A0 =
=C2=A0public:</div><div class=3D"subprettyprint">=C2=A0 =C2=A0 virtual Foo =
op_0() =3D 0;</div><div class=3D"subprettyprint">=C2=A0 =C2=A0 virtual void=
op_1() =3D 0;</div><div class=3D"subprettyprint">=C2=A0 =C2=A0 virtual Foo=
op_2() =3D 0;</div><div class=3D"subprettyprint">=C2=A0 =C2=A0 virtual voi=
d op_3(int&&) =3D 0;</div><div class=3D"subprettyprint">=C2=A0 =C2=
=A0 virtual ~Abstraction() {}</div><div class=3D"subprettyprint">=C2=A0 };<=
/div><div class=3D"subprettyprint"><br></div><div class=3D"subprettyprint">=
=C2=A0 template <class Data></div><div class=3D"subprettyprint">=C2=
=A0 class Implementation final : public Abstraction {</div><div class=3D"su=
bprettyprint">=C2=A0 =C2=A0public:</div><div class=3D"subprettyprint">=C2=
=A0 =C2=A0 Implementation(Data&& data) : data_(std::forward<Data=
>(data)) {}</div><div class=3D"subprettyprint">=C2=A0 =C2=A0 Foo op_0() =
override { return Data(data_); }</div><div class=3D"subprettyprint">=C2=A0 =
=C2=A0 void op_1() override { data_(); }</div><div class=3D"subprettyprint"=
>=C2=A0 =C2=A0 Foo op_2() override { return data_.f(); }</div><div class=3D=
"subprettyprint">=C2=A0 =C2=A0 void op_3(int&& arg_0) override { da=
ta_.g(std::forward<int>(arg_0)); }</div><div class=3D"subprettyprint"=
><br></div><div class=3D"subprettyprint">=C2=A0 =C2=A0private:</div><div cl=
ass=3D"subprettyprint">=C2=A0 =C2=A0 Data data_;</div><div class=3D"subpret=
typrint">=C2=A0 };</div><div class=3D"subprettyprint"><br></div><div class=
=3D"subprettyprint">=C2=A0 std::shared_ptr<Abstraction> data_;</div><=
div class=3D"subprettyprint">};</div></font></div></code></div><br><br></di=
v><div><br></div><div><br></div>On Tuesday, May 9, 2017 at 5:27:34 AM UTC+8=
, Barry Revzin wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><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"><blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>Yep, I t=
hink we are talking about automatic type-erasure here.<br></div><div><br></=
div><div>Sean Parent has done a lot of work with type-erasure and polymorph=
ic values types based on "concepts" (pre Concepts concepts).<br><=
br></div><div>I wonder if Concepts + reflection might allow someone to writ=
e:<br><br></div><div>Foo foo; // foo happens to model Concept<br></div><div=
>std::erased<Concept> efoo =3D foo;<br></div><div>func(efoo);=C2=A0 /=
/ Not a templatized function<br></div><div><br></div><div>Tony<br></div></d=
iv></div></div></blockquote><div><br>That would require lots of things that=
don't exist at present:<br><br>1: Reflection to be able to introspect =
concepts, being able to iterate over their constituent expressions.<br><br>=
2: Reflection would need to be able to <i>generate</i> code. Otherwise, `st=
d::erased` wouldn't be able to generate non-member functions to handle =
non-members of the `Concept`.<br><br>3: Concepts would have to be able to b=
e passed as template parameters.<br></div></div></blockquote><div><br></div=
><div>Yeah, but I'd argue it's really what you want. Type erasure i=
s extremely useful, Concepts already express the desired interface, so it&#=
39;s really natural to stick them together. It'd be pretty valuable to =
either:</div><div><br></div><div>(1) be able to write a library that works =
like erased<Concept> (e.g. Rust's Box)</div><div>(2) provide a me=
chanism in the language to implicitly generate such a thing, whether by</di=
v><div>(2a) reappropriating the abbreviated function syntax to do type eras=
ure instead, or=C2=A0</div><div>(2b) providing a new syntax like void foo(C=
oncept^ )=C2=A0</div><div><br></div><div>Any of those approaches requires a=
lot of stuff that we don't have today, and won't have on day 1 on =
any of these TSes hitting, but I think are worth considering longer term as=
next steps for cool problems to solve with Concepts.</div></blockquote></d=
iv>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/d15cc3d3-b526-499d-9b8b-2d4ecd15aba9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d15cc3d3-b526-499d-9b8b-2d4ecd15aba9=
%40isocpp.org</a>.<br />
------=_Part_4929_1991480419.1494316908861--
------=_Part_4928_340421383.1494316908861--
.
Author: Jakob Riedle <jakob.riedle@gmail.com>
Date: Tue, 9 May 2017 01:34:19 -0700 (PDT)
Raw View
------=_Part_2834_558741609.1494318859133
Content-Type: multipart/alternative;
boundary="----=_Part_2835_568080330.1494318859135"
------=_Part_2835_568080330.1494318859135
Content-Type: text/plain; charset=UTF-8
Am Dienstag, 9. Mai 2017 08:10:15 UTC+2 schrieb Mingxin Wang:
>
> Dear Mr. Riedle,
>
> Thank you for your recognition!
>
> I have thought about the idea you posted about possible compile-time
> deduction, and I found it is *positive *for compiler optimization, but it
> shall not be abused. For example:
>
> Callable<void()> a([] { puts("Lambda"); });
> a();
>
> is OK to be compiled (after compiler optimization) as
>
> puts("Lambda");
>
Sure, this is easy optimization. Still, the compiler is not forced to
optimize this, right?
> But
>
> std::vector<function<void()>> a;
> std::vector<Callable<void()>> b(a);
>
> is ill-formed.
>
That's true, I thought std::vector was constructible from a different
vector of castable type, but its not.
How about
std::vector<function<void()>> a;
std::vector<Callable<void()>> b(a.begin(), a.end());
This should work!
An interface is a type, like integral types, classes, lambda expressions,
> etc. The reason why the code above is ill-formed is similar with the code
> below (also ill-formed):
>
> std::vector<int> a;
> std::vector<double> b(a);
>
Gotcha!
*Concerning the Answer by Bengt Gustafsson:*
If anyone can disentangle this into a manageable set of rules I would be
> all for it, but the problems pointed out, that a concept can contain
> requirements for free functions, types etc, and thus the virtual pointer
> table is not enough to express the resulting polymorphism.
I think you missed the example implementation by Mingxing Wang!
template <class R, class... Args>
class Callable {
public:
template <class Data>
Callable(Data data) requires
requires(Data data, Args... args) { { data(std::move(args)...) } -> R;
}
: data_(new Implementation<Data>(std::move(data))) {}
Callable() = default;
Callable(Callable&&) = default;
Callable(const Callable&) = default;
Callable& operator=(Callable&&) = default;
Callable& operator=(const Callable&) = default;
R operator()(Args... args) { return data_->op_0(std::move(args)...); }
private:
class Abstraction {
public:
virtual R op_0(Args&&...) = 0;
virtual ~Abstraction() {}
};
template <class Data>
class Implementation final : public Abstraction {
public:
Implementation(Data&& data) : data_(std::forward<Data>(data)) {}
R op_0(Args&&... args) override { return data_(std::forward<Args>(args
)...); }
private:
Data data_;
};
std::shared_ptr<Abstraction> data_;
};
This Implementation does not just "grab" some functions of the contained
type fulfilling "Callable".
Note, that
*R operator()(Args... args) { return data_->op_0(std::move(args)...); }*
can be written for any function, be it member function or freestanding.
*Literally the Only exception*: Constructors. Virtual function calls for
constructors are not valid right now.
My vision is that the runtime version of Callable<...> resembles 100% of
the concrete type that was stored in it, even copying, moving and swapping.
It might be, that some Compiler magic needs to be done to allow
constructors, but hey, the approach is working!
My argument is, that instead of implementing *Concept Polymorphism *(That's
what I'll call it for now) as library feature (which involves super
expensive and complex reflections),
I'd implement it as language feature.
*Concerning the Answer by Nicol Bolas*
`vector<Callable<void()>>::value_type` needs to be a specific type (one
> that is the same in all translation units),
and it's probably best that this type have a well-defined name. And that
> name can't be `Callable<void()>`.
Yes it can, let me show you why:
Imagine a pure abstract base class BaseClass and a derived class
*DerivedClass*:
class BaseClass{
public:
virtual void operator()() = 0;
};
class DerivedClass : public BaseClass{
public:
void operator()() override {/*Whatever*/}
};
Now imagine a vector of *BaseClass *objects in which e.g. *DerivedClass *objects
can be inserted.
Your argument would be, that std::vector<BaseClass>::value_type needs to be
a concrete type, *which it is, its BaseClass.*
Still that doesn't mean, It will actually be DerivedClass in all
translation units, but thats how this mechanism is supposed to work.
For *Dynamic Concepts, *this is the way, Mingxing Wang proposed it: as pure
virtual base class.
Now one argument would be, *what if algorithms want to make objects of this
Dynamic Concept Type??*
This translates to: What if algorithms want to make objects of Type
BaseClass??
[I hope it's starting to become clear now...]
Unlike DerivedClass objects, type erased to BaseClass: If a Concept
reuqires a type to be e.g. copyable and movable,
I'd overload operator move and copy within a hypothetic implementation
*Callable*(as above) to support that.
*In order for the Concept to behave 100% like the concrete Type that's
stored in it.*
Note: I would therefore vote for std::unique_ptr instead of std::shared_ptr
as internal helper type.
*This way,*
*void f( Callable<void()> v )*
*{*
* Callable<void()>& v1 = v; // Reference copy*
* Callable<void()> v2 = v; // Actual copy of the concrete object*
*}*
*works as expected.*
Even though we don't have many of the groundwork that's needed for Dynamic
Concepts,
I think this feature is quite self contained and is proposable in a
straightforward way.
Cheers,
Jakob
--
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/da34864f-4752-4969-bac5-96c6ce133bd1%40isocpp.org.
------=_Part_2835_568080330.1494318859135
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Am Dienstag, 9. Mai 2017 08:10:15 UTC+2 schrieb Mingxin Wa=
ng:<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><font=
face=3D"georgia, serif">Dear Mr.=C2=A0Riedle,</font></div><div><font face=
=3D"georgia, serif"><br></font></div><div><font face=3D"georgia, serif">Tha=
nk you for your recognition!</font><br></div><div><font face=3D"georgia, se=
rif"><br></font></div><div><font face=3D"georgia, serif">I have thought abo=
ut the idea</font><span style=3D"font-family:georgia,serif">=C2=A0you poste=
d</span><span style=3D"font-family:georgia,serif">=C2=A0</span><span style=
=3D"font-family:georgia,serif">about=C2=A0possible compile-time deduction</=
span><span style=3D"font-family:georgia,serif">, and I found it is=C2=A0</s=
pan><span style=3D"font-family:georgia,serif;line-height:17px"><b>positive =
</b>for=C2=A0compiler optimization, but it shall not be abused. For example=
:</span></div><div><span style=3D"font-family:georgia,serif;line-height:17p=
x"><br></span></div><div><span style=3D"font-family:georgia,serif;line-heig=
ht:17px"><div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-wo=
rd;background-color:rgb(250,250,250)"><code><div><div>Callable<void()>=
; a([] { puts("Lambda"); });</div><div>a();</div></div></code></d=
iv><br>is OK to be compiled</span><span style=3D"font-family:georgia,serif;=
line-height:17px">=C2=A0(after=C2=A0</span><span style=3D"font-family:georg=
ia,serif;line-height:17px">compiler optimization</span><span style=3D"font-=
family:georgia,serif;line-height:17px">)</span><span style=3D"font-family:g=
eorgia,serif;line-height:17px">=C2=A0as</span></div><div><span style=3D"fon=
t-family:georgia,serif;line-height:17px"><br></span></div><div><div style=
=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;background-color=
:rgb(250,250,250)"><code><div><font color=3D"#660066"><span style=3D"line-h=
eight:17px">puts("Lambda");</span></font></div></code></div></div=
></div></blockquote><div>Sure, this is easy optimization. Still, the compil=
er is not forced to optimize this, right?</div><div><br></div><div>=C2=A0</=
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><spa=
n style=3D"font-family: georgia, serif;">But</span>=C2=A0</div></div></bloc=
kquote><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><=
font face=3D"georgia, serif"><br></font></div><div><font face=3D"georgia, s=
erif"><div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;=
background-color:rgb(250,250,250)"><code><div><div>std::vector<function&=
lt;void()>> a;</div><div>std::vector<Callable<void()>> b(=
a);</div></div></code></div><br>is=C2=A0ill-formed.</font></div></div></blo=
ckquote><div>That's true, I thought std::vector was constructible from =
a different vector of castable type, but its not.</div><div><br></div><div>=
How about</div><div class=3D"prettyprint" style=3D"background-color: rgb(25=
0, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; border=
-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">vector</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span=
style=3D"color: #008;" class=3D"styled-by-prettify">function</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">void</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">()>></span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> a</span><span style=3D"color: #66=
0;" 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><span style=3D"color: #000;" class=3D"styled-=
by-prettify">vector</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify"><</span><span style=3D"color: #606;" class=3D"styled-by-prettif=
y">Callable</span><span style=3D"color: #660;" 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"> b</span><s=
pan 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: #008;" =
class=3D"styled-by-prettify">begin</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(),</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> a</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">.</span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
end</span><span style=3D"color: #660;" class=3D"styled-by-prettify">());</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></=
div></code></div><div style=3D"background-color: rgb(250, 250, 250);"><font=
face=3D"arial, sans-serif">This should work!</font></div><div style=3D"bac=
kground-color: rgb(250, 250, 250);"><font face=3D"arial, sans-serif"><br></=
font></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"><d=
iv><font face=3D"georgia, serif">An interface is a type, like=C2=A0integral=
types,=C2=A0classes, lambda expressions, etc. The reason why the code abov=
e is=C2=A0</font><span style=3D"font-family: georgia, serif;">ill-formed</s=
pan><font face=3D"georgia, serif">=C2=A0is similar with the code below (als=
o ill-formed):</font><br></div><div><font face=3D"georgia, serif"><br></fon=
t></div><div><font face=3D"georgia, serif"><div style=3D"border:1px solid r=
gb(187,187,187);word-wrap:break-word;background-color:rgb(250,250,250)"><co=
de><div><div>std::vector<int> a;</div><div>std::vector<double> =
b(a);</div></div></code></div></font></div></div></blockquote><div>Gotcha!<=
br></div><div><br></div><div><br></div><div><br></div><div><b>Concerning th=
e Answer by Bengt Gustafsson:</b></div><div><b><br></b></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px so=
lid rgb(204, 204, 204); padding-left: 1ex;">If anyone can disentangle this =
into a manageable set of rules I would be all for it, but the problems poin=
ted out, that a concept can contain requirements for free functions, types =
etc, and thus the virtual pointer table is not enough to express the result=
ing polymorphism.</blockquote><div><br></div><div>I think you missed the ex=
ample implementation by Mingxing Wang!</div><div><br></div><div><div class=
=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-colo=
r: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: b=
reak-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span=
style=3D"color: #008;" class=3D"styled-by-prettify">template</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify"><</span><span style=3D"color: =
#008;" class=3D"styled-by-prettify">class</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"style=
d-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">class</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>...</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #606;" class=3D"styled-by-prettify">Args</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">></span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">class</span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" c=
lass=3D"styled-by-prettify">Callable</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </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>=C2=A0</span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">public</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">tem=
plate</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">class</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #606;" class=3D"styled-by-prettify">Data</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 </span><span style=3D"color: #606;"=
class=3D"styled-by-prettify">Callable</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">(</span><span style=3D"color: #606;" class=3D"s=
tyled-by-prettify">Data</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> data</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
requires<br>=C2=A0 =C2=A0 =C2=A0 requires</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">(</span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">Data</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> data</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Args<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">...</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> args</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: #6=
60;" 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"> data</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">std</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify">move</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">args</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: #660;" class=3D"st=
yled-by-prettify">}</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"> R</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"><br>=C2=A0 =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"> data_</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">new</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-b=
y-prettify">Implementation</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify"><</span><span style=3D"color: #606;" class=3D"styled-by-=
prettify">Data</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">>(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">s=
td</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">move</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">data</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">{}</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br>=C2=A0 </span><span style=3D"color: #606;" class=3D"sty=
led-by-prettify">Callable</span><span style=3D"color: #660;" class=3D"style=
d-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">=
=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><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span styl=
e=3D"color: #606;" class=3D"styled-by-prettify">Callable</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #606;" class=3D"styled-by-prettify">Callable</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;" c=
lass=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-b=
y-prettify">default</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br>=C2=A0 </span><span style=3D"color: #606;" class=3D"styled-by-prettify"=
>Callable</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(=
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">const</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #606;" class=3D"styled-by-prettify">Callable</span><span sty=
le=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;" 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-b=
y-prettify"><br>=C2=A0 </span><span style=3D"color: #606;" class=3D"styled-=
by-prettify">Callable</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">&</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">ope=
rator</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D(<=
/span><span style=3D"color: #606;" class=3D"styled-by-prettify">Callable</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">&&)</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n 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>=C2=A0 </span><span style=3D"color: #606;" cl=
ass=3D"styled-by-prettify">Callable</span><span style=3D"color: #660;" clas=
s=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">operator</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">=3D(</span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">const</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #606;" class=3D"styled-by-prettify">Callable</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 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>=C2=A0 R </span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">operator</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">()(</span><span style=3D"color: #606;" class=3D"s=
tyled-by-prettify">Args</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">...</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> args</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">{</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">return</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> data_</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">-></span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">op_0</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">std</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">mov=
e</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify">args</span><span s=
tyle=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"><br><br>=C2=A0</span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">private</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 </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">class</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-=
prettify">Abstraction</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>=C2=
=A0 =C2=A0</span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
public</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: #008;" class=3D"styled-by-prettify">vir=
tual</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> R op_=
0</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><=
span style=3D"color: #606;" class=3D"styled-by-prettify">Args</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">&&...)</span><sp=
an 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"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;=
" class=3D"styled-by-prettify">0</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>=C2=A0 =C2=A0 </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: #660;" class=3D"styled-b=
y-prettify">~</span><span style=3D"color: #606;" class=3D"styled-by-prettif=
y">Abstraction</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </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>=C2=A0 </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">};</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br><br>=C2=A0 </span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">template</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify"><</span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">class</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D=
"styled-by-prettify">Data</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">></span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">class</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Impl=
ementation</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">final</sp=
an><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: #0=
08;" class=3D"styled-by-prettify">public</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D=
"styled-by-prettify">Abstraction</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"><br>=C2=A0 =C2=A0</span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">public</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br>=C2=A0 =C2=A0 </span><span style=3D"color: #606;" class=3D"styled-by-pr=
ettify">Implementation</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">(</span><span style=3D"color: #606;" class=3D"styled-by-prettif=
y">Data</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&am=
p;&</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> da=
ta</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"> data_</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">std</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">forward</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify"><</span><span style=3D"color: #606;" class=3D"styled-by-prettif=
y">Data</span><span style=3D"color: #660;" class=3D"styled-by-prettify">>=
;(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">data</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: #660;" class=3D"styled-by-prettify">{}</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 R op_0</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"co=
lor: #606;" class=3D"styled-by-prettify">Args</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">&&...</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> args</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">override</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">return</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> data_</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">std</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">forward</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify"><</span><span style=3D"color: #606;" class=3D"=
styled-by-prettify">Args</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">>(</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">args</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">)...);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>=C2=A0 =C2=
=A0</span><span style=3D"color: #008;" class=3D"styled-by-prettify">private=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 <=
/span><span style=3D"color: #606;" class=3D"styled-by-prettify">Data</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> data_</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">};</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br><br>=C2=A0 std</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">shared_ptr</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify"><</span><span style=3D"color: #6=
06;" class=3D"styled-by-prettify">Abstraction</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">></span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> data_</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><span style=3D"color: #660;" class=3D"styled-by-=
prettify">};</span></div></code></div><div class=3D"IVILX2C-Db-b" style=3D"=
font-family: monospace; background-color: rgb(250, 250, 250);"><div><br></d=
iv></div></div><div>This Implementation does not just "grab" some=
functions of the contained type fulfilling "Callable".</div><div=
>Note, that</div><div><br></div><div><b><span class=3D"styled-by-prettify" =
style=3D"font-family: monospace; background-color: rgb(250, 250, 250); colo=
r: rgb(0, 0, 0);">R=C2=A0</span><span class=3D"styled-by-prettify" style=3D=
"font-family: monospace; background-color: rgb(250, 250, 250); color: rgb(0=
, 0, 136);">operator</span><span class=3D"styled-by-prettify" style=3D"font=
-family: monospace; background-color: rgb(250, 250, 250); color: rgb(102, 1=
02, 0);">()(</span><span class=3D"styled-by-prettify" style=3D"font-family:=
monospace; background-color: rgb(250, 250, 250); color: rgb(102, 0, 102);"=
>Args</span><span class=3D"styled-by-prettify" style=3D"font-family: monosp=
ace; background-color: rgb(250, 250, 250); color: rgb(102, 102, 0);">...</s=
pan><span class=3D"styled-by-prettify" style=3D"font-family: monospace; bac=
kground-color: rgb(250, 250, 250); color: rgb(0, 0, 0);">=C2=A0args</span><=
span class=3D"styled-by-prettify" style=3D"font-family: monospace; backgrou=
nd-color: rgb(250, 250, 250); color: rgb(102, 102, 0);">)</span><span class=
=3D"styled-by-prettify" style=3D"font-family: monospace; background-color: =
rgb(250, 250, 250); color: rgb(0, 0, 0);">=C2=A0</span><span class=3D"style=
d-by-prettify" style=3D"font-family: monospace; background-color: rgb(250, =
250, 250); color: rgb(102, 102, 0);">{</span><span class=3D"styled-by-prett=
ify" style=3D"font-family: monospace; background-color: rgb(250, 250, 250);=
color: rgb(0, 0, 0);">=C2=A0</span><span class=3D"styled-by-prettify" styl=
e=3D"font-family: monospace; background-color: rgb(250, 250, 250); color: r=
gb(0, 0, 136);">return</span><span class=3D"styled-by-prettify" style=3D"fo=
nt-family: monospace; background-color: rgb(250, 250, 250); color: rgb(0, 0=
, 0);">=C2=A0data_</span><span class=3D"styled-by-prettify" style=3D"font-f=
amily: monospace; background-color: rgb(250, 250, 250); color: rgb(102, 102=
, 0);">-></span><span class=3D"styled-by-prettify" style=3D"font-family:=
monospace; background-color: rgb(250, 250, 250); color: rgb(0, 0, 0);">op_=
0</span><span class=3D"styled-by-prettify" style=3D"font-family: monospace;=
background-color: rgb(250, 250, 250); color: rgb(102, 102, 0);">(</span><s=
pan class=3D"styled-by-prettify" style=3D"font-family: monospace; backgroun=
d-color: rgb(250, 250, 250); color: rgb(0, 0, 0);">std</span><span class=3D=
"styled-by-prettify" style=3D"font-family: monospace; background-color: rgb=
(250, 250, 250); color: rgb(102, 102, 0);">::</span><span class=3D"styled-b=
y-prettify" style=3D"font-family: monospace; background-color: rgb(250, 250=
, 250); color: rgb(0, 0, 0);">move</span><span class=3D"styled-by-prettify"=
style=3D"font-family: monospace; background-color: rgb(250, 250, 250); col=
or: rgb(102, 102, 0);">(</span><span class=3D"styled-by-prettify" style=3D"=
font-family: monospace; background-color: rgb(250, 250, 250); color: rgb(0,=
0, 0);">args</span><span class=3D"styled-by-prettify" style=3D"font-family=
: monospace; background-color: rgb(250, 250, 250); color: rgb(102, 102, 0);=
">)...);</span><span class=3D"styled-by-prettify" style=3D"font-family: mon=
ospace; background-color: rgb(250, 250, 250); color: rgb(0, 0, 0);">=C2=A0<=
/span><span class=3D"styled-by-prettify" style=3D"font-family: monospace; b=
ackground-color: rgb(250, 250, 250); color: rgb(102, 102, 0);">}</span></b>=
</div><div><span class=3D"styled-by-prettify" style=3D"background-color: rg=
b(250, 250, 250);"><font face=3D"arial, sans-serif" color=3D"#000000"><br><=
/font></span></div><div><span class=3D"styled-by-prettify" style=3D"backgro=
und-color: rgb(250, 250, 250);"><font face=3D"arial, sans-serif" color=3D"#=
000000">can be written for any function, be it member function or freestand=
ing.</font></span></div><div><span class=3D"styled-by-prettify" style=3D"ba=
ckground-color: rgb(250, 250, 250);"><font face=3D"arial, sans-serif" color=
=3D"#000000"><b>Literally the Only exception</b>: Constructors. Virtual fun=
ction calls for constructors are not valid right now.</font></span></div><d=
iv><span class=3D"styled-by-prettify" style=3D"background-color: rgb(250, 2=
50, 250);"><font face=3D"arial, sans-serif" color=3D"#000000"><br></font></=
span></div><div><span class=3D"styled-by-prettify" style=3D"background-colo=
r: rgb(250, 250, 250);"><font face=3D"arial, sans-serif" color=3D"#000000">=
My vision is that the runtime version of Callable<...> resembles 100%=
of the concrete type that was stored in it, even copying, moving and swapp=
ing.</font></span></div><div><span class=3D"styled-by-prettify" style=3D"ba=
ckground-color: rgb(250, 250, 250);"><font face=3D"arial, sans-serif" color=
=3D"#000000">It might be, that some Compiler magic needs to be done to allo=
w constructors, but hey, the approach is working!</font></span></div><div><=
span class=3D"styled-by-prettify" style=3D"background-color: rgb(250, 250, =
250);"><font face=3D"arial, sans-serif" color=3D"#000000"><br></font></span=
></div><div><span class=3D"styled-by-prettify" style=3D"background-color: r=
gb(250, 250, 250);"><font face=3D"arial, sans-serif" color=3D"#000000">My a=
rgument is, that instead of implementing <b>Concept Polymorphism </b>(That&=
#39;s what I'll call it for now) as library feature (which involves sup=
er expensive and complex reflections),</font></span></div><div><span class=
=3D"styled-by-prettify" style=3D"background-color: rgb(250, 250, 250);"><fo=
nt face=3D"arial, sans-serif" color=3D"#000000">I'd implement it as lan=
guage feature.</font></span></div><div><b><span class=3D"styled-by-prettify=
" style=3D"font-family: monospace; background-color: rgb(250, 250, 250); co=
lor: rgb(102, 102, 0);"><br></span></b></div><div><b><span class=3D"styled-=
by-prettify" style=3D"font-family: monospace; background-color: rgb(250, 25=
0, 250); color: rgb(102, 102, 0);"><br></span></b></div><div><b><span class=
=3D"styled-by-prettify" style=3D"font-family: monospace; background-color: =
rgb(250, 250, 250); color: rgb(102, 102, 0);"><br></span></b></div><div><sp=
an class=3D"styled-by-prettify" style=3D"background-color: rgb(250, 250, 25=
0);"><font face=3D"arial, sans-serif" color=3D"#000000"><b>Concerning the A=
nswer by Nicol Bolas</b></font></span></div><div><span class=3D"styled-by-p=
rettify" style=3D"background-color: rgb(250, 250, 250);"><font face=3D"aria=
l, sans-serif" color=3D"#000000"><b><br></b></font></span></div><blockquote=
class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px=
solid rgb(204, 204, 204); padding-left: 1ex;"><span class=3D"styled-by-pre=
ttify" style=3D"background-color: rgb(250, 250, 250);"><span style=3D"backg=
round-color: rgb(255, 255, 255);">`vector<Callable<void()>>::</=
span><wbr style=3D"background-color: rgb(255, 255, 255);"><span style=3D"ba=
ckground-color: rgb(255, 255, 255);">value_type` needs to be a specific typ=
e (one that is the same in all translation units),</span></span>=C2=A0</blo=
ckquote><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8e=
x; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><span cla=
ss=3D"styled-by-prettify" style=3D"background-color: rgb(250, 250, 250);"><=
span style=3D"background-color: rgb(255, 255, 255);">and it's probably =
best that this type have a well-defined name. And that name can't be `C=
allable<void()>`.</span></span></blockquote><div><br></div><div>Yes i=
t can, let me show you why:</div><div><br></div><div>Imagine a pure abstrac=
t base class <font face=3D"courier new, monospace" style=3D"font-weight: bo=
ld;">BaseClass </font><font face=3D"arial, sans-serif">and a derived class =
</font><font face=3D"courier new, monospace"><b>DerivedClass</b></font><fon=
t face=3D"courier new, monospace" style=3D"font-weight: bold;">:</font></di=
v><div><div class=3D"prettyprint" style=3D"font-family: "courier new&q=
uot;, monospace; font-weight: bold; background-color: rgb(250, 250, 250); b=
order-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; wo=
rd-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettypr=
int"><font color=3D"#660066"><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">class</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Ba=
seClass</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</=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">public</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">virtual</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">void</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">operator</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">()()</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">0</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><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color:=
#008;" class=3D"styled-by-prettify">class</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">DerivedClass</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">p=
ublic</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #606;" class=3D"styled-by-prettify">BaseClass</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</span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">public</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 </span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">void</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">operator</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">()()</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">override</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: #800;" class=3D"styled-by-prettify">/*Whatever*=
/</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 s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">};</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br></span></font></div></code><=
/div><font face=3D"arial, sans-serif">Now imagine a vector of </font><font =
face=3D"courier new, monospace"><b>BaseClass </b></font><font face=3D"arial=
, sans-serif">objects in which e.g. </font><font face=3D"courier new, monos=
pace"><b>DerivedClass </b></font><font face=3D"arial, sans-serif">objects c=
an be inserted.</font></div><div><font face=3D"arial, sans-serif"><br></fon=
t></div><div><font face=3D"arial, sans-serif">Your argument would be, that =
std::vector<BaseClass>::value_type needs to be a concrete type, </fon=
t><b><font face=3D"arial, sans-serif">which it is, its=C2=A0</font><font fa=
ce=3D"courier new, monospace">BaseClass</font><font face=3D"arial, sans-ser=
if">.</font></b></div><div><font face=3D"arial, sans-serif">Still that does=
n't mean, It will actually be DerivedClass in all translation units, bu=
t thats how this mechanism is supposed to work.</font></div><div><font face=
=3D"arial, sans-serif">For <i>Dynamic Concepts, </i>this is the way, Mingxi=
ng Wang proposed it: as pure virtual base class.</font></div><div><font fac=
e=3D"arial, sans-serif"><br></font></div><div><font face=3D"arial, sans-ser=
if">Now one argument would be, <i>what if algorithms want to make objects o=
f this Dynamic Concept Type??</i></font></div><div><font face=3D"arial, san=
s-serif">This translates to: What if algorithms want to make objects of Typ=
e </font><font face=3D"courier new, monospace">BaseClass</font><font face=
=3D"arial, sans-serif">??</font></div><div><font face=3D"arial, sans-serif"=
><br></font></div><div><font face=3D"arial, sans-serif">[I hope it's st=
arting to become clear now...]</font></div><div><font face=3D"arial, sans-s=
erif"><br></font></div><div><font face=3D"arial, sans-serif">Unlike Derived=
Class objects,=C2=A0</font><span style=3D"font-family: arial, sans-serif;">=
type erased</span><span style=3D"font-family: arial, sans-serif;">=C2=A0to<=
/span><span style=3D"font-family: arial, sans-serif;">=C2=A0</span><font fa=
ce=3D"courier new, monospace">BaseClass</font><font face=3D"arial, sans-ser=
if">: If a Concept reuqires a type to be e.g. copyable and movable,</font><=
/div><div><font face=3D"arial, sans-serif">I'd overload operator move a=
nd copy within a hypothetic implementation=C2=A0</font><font face=3D"courie=
r new, monospace"><b>Callable</b></font><font face=3D"arial, sans-serif">(a=
s above) to support that.</font></div><div><font face=3D"arial, sans-serif"=
><b>In order for the Concept to behave 100% like the concrete Type that'=
;s stored in it.</b></font></div><div><font face=3D"arial, sans-serif"><b><=
br></b></font></div><div><span style=3D"font-family: arial, sans-serif;">No=
te: I would therefore vote for std::unique_ptr instead of std::shared_ptr a=
s internal helper type.</span><font face=3D"arial, sans-serif"><b><br></b><=
/font></div><div><font face=3D"arial, sans-serif"><b><br></b></font></div><=
div><font face=3D"arial, sans-serif"><b>This way,</b></font></div><div><fon=
t face=3D"arial, sans-serif"><b>void f( Callable<void()> v )</b></fon=
t></div><div><font face=3D"arial, sans-serif"><b>{</b></font></div><div><fo=
nt face=3D"arial, sans-serif"><b>=C2=A0 =C2=A0Callable<void()>& v=
1 =3D v; // Reference copy</b></font></div><div><font face=3D"arial, sans-s=
erif"><b>=C2=A0 =C2=A0Callable<void()> v2 =3D v; // Actual copy of th=
e concrete object</b></font></div><div><font face=3D"arial, sans-serif"><b>=
}</b></font></div><div><font face=3D"arial, sans-serif"><b>works as expecte=
d.</b></font></div><div><font face=3D"arial, sans-serif"><b><br></b></font>=
</div><div><font face=3D"arial, sans-serif">Even though we don't have m=
any of the groundwork that's needed for Dynamic Concepts,</font></div><=
div><font face=3D"arial, sans-serif">I think this feature is quite self con=
tained and is proposable in a straightforward way.</font></div><div><font f=
ace=3D"arial, sans-serif"><br></font></div><div><font face=3D"arial, sans-s=
erif">Cheers,</font></div><div><font face=3D"arial, sans-serif">Jakob</font=
></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/da34864f-4752-4969-bac5-96c6ce133bd1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/da34864f-4752-4969-bac5-96c6ce133bd1=
%40isocpp.org</a>.<br />
------=_Part_2835_568080330.1494318859135--
------=_Part_2834_558741609.1494318859133--
.
Author: Jakob Riedle <jakob.riedle@gmail.com>
Date: Tue, 9 May 2017 07:31:51 -0700 (PDT)
Raw View
------=_Part_2894_2048022581.1494340311920
Content-Type: multipart/alternative;
boundary="----=_Part_2895_940101487.1494340311920"
------=_Part_2895_940101487.1494340311920
Content-Type: text/plain; charset="UTF-8"
Am Dienstag, 9. Mai 2017 10:34:19 UTC+2 schrieb Jakob Riedle:
>
> My argument is, that instead of implementing *Concept Polymorphism *(That's
> what I'll call it for now) as library feature (which involves super
> expensive and complex reflections),
> I'd implement it as language feature.
>
Sorry, I first decided to refer to the proposed concept as "Concept
Polymorphism".
Later decided to change this term to *Dynamic Concepts*, which I like more.
Not, that I'd suggest this name for a potential proposal but just for *clarifying
this term w.r.t. my previous answer*.
Jakob
--
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/81c87217-1730-4f4d-b563-d255a86ed591%40isocpp.org.
------=_Part_2895_940101487.1494340311920
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Am Dienstag, 9. Mai 2017 10:34:19 UTC+2 schrieb Jakob Ried=
le:<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><span=
style=3D"color: rgb(0, 0, 0); font-family: arial, sans-serif; background-c=
olor: rgb(250, 250, 250);">My argument is, that instead of implementing </s=
pan><b style=3D"color: rgb(0, 0, 0); font-family: arial, sans-serif; backgr=
ound-color: rgb(250, 250, 250);">Concept Polymorphism </b><span style=3D"co=
lor: rgb(0, 0, 0); font-family: arial, sans-serif; background-color: rgb(25=
0, 250, 250);">(That's what I'll call it for now) as library featur=
e (which involves super expensive and complex reflections),</span><br></div=
><div><span style=3D"background-color:rgb(250,250,250)"><font face=3D"arial=
, sans-serif" color=3D"#000000">I'd implement it as language feature.</=
font></span></div></div></blockquote><div><br></div><div>Sorry, I first dec=
ided to refer to the proposed concept as "Concept Polymorphism".<=
/div><div>Later decided to change this term to <b>Dynamic Concepts</b>, whi=
ch I like more.</div><div>Not, that I'd suggest this name for a potenti=
al proposal but just for <i>clarifying this term w.r.t. my previous answer<=
/i>.</div><div><br></div><div>Jakob</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/81c87217-1730-4f4d-b563-d255a86ed591%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/81c87217-1730-4f4d-b563-d255a86ed591=
%40isocpp.org</a>.<br />
------=_Part_2895_940101487.1494340311920--
------=_Part_2894_2048022581.1494340311920--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 9 May 2017 07:39:08 -0700 (PDT)
Raw View
------=_Part_3151_357011682.1494340748237
Content-Type: multipart/alternative;
boundary="----=_Part_3152_1491932021.1494340748237"
------=_Part_3152_1491932021.1494340748237
Content-Type: text/plain; charset="UTF-8"
On Tuesday, May 9, 2017 at 4:34:19 AM UTC-4, Jakob Riedle wrote:
>
> *Concerning the Answer by Nicol Bolas*
>
>> `vector<Callable<void()>>::value_type` needs to be a specific type (one
>> that is the same in all translation units),
>
> and it's probably best that this type have a well-defined name. And that
>> name can't be `Callable<void()>`.
>
>
> Yes it can, let me show you why:
>
> Imagine a pure abstract base class BaseClass and a derived class
> *DerivedClass*:
> class BaseClass{
> public:
> virtual void operator()() = 0;
> };
>
> class DerivedClass : public BaseClass{
> public:
> void operator()() override {/*Whatever*/}
> };
> Now imagine a vector of *BaseClass *objects in which e.g. *DerivedClass *objects
> can be inserted.
>
That would have to be a `vector<BaseClass*>`. Which would be different from
`vector<BaseClass>`.
> Your argument would be, that std::vector<BaseClass>::value_type needs to
> be a concrete type, *which it is, its BaseClass.*
>
No, my argument is that `Callable<void()>` is a *concept*. Concepts *are
not types*; in the current TS, they are either functions or variables,
neither of which is a *type*.
Therefore, `vector<Callable<void()>>::value_type` *cannot be*
`Callable<void()>`.
Still that doesn't mean, It will actually be DerivedClass in all
> translation units, but thats how this mechanism is supposed to work.
> For *Dynamic Concepts, *this is the way, Mingxing Wang proposed it: as
> pure virtual base class.
>
In order to have "dynamic concepts", you need some construct to refer to
such a thing, which must by necessity be *different* from how you refer to
*static* concepts. `Callable<>` is a static concept, so if you want to make
a dynamic concept based on it, you must use some other syntax besides
`Callable<>`.
That's my point. You can't have `Callable<>` be both a static and dynamic
concept. That's why its best to make "dynamic concepts" specifically be
types.
--
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/09ec869a-2c1d-4fe8-8295-253e5001edd4%40isocpp.org.
------=_Part_3152_1491932021.1494340748237
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, May 9, 2017 at 4:34:19 AM UTC-4, Jakob Riedle =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><s=
pan style=3D"background-color:rgb(250,250,250)"><font color=3D"#000000" fac=
e=3D"arial, sans-serif"><b>Concerning the Answer by Nicol Bolas</b></font><=
/span></div><div><span style=3D"background-color:rgb(250,250,250)"><font co=
lor=3D"#000000" face=3D"arial, sans-serif"><b></b></font></span></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex"><span style=3D"background-colo=
r:rgb(250,250,250)"><span style=3D"background-color:rgb(255,255,255)">`vect=
or<Callable<void()>>::</span><span style=3D"background-color:rg=
b(255,255,255)">val<wbr>ue_type` needs to be a specific type (one that is t=
he same in all translation units),</span></span>=C2=A0</blockquote><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
solid rgb(204,204,204);padding-left:1ex"><span style=3D"background-color:r=
gb(250,250,250)"><span style=3D"background-color:rgb(255,255,255)">and it&#=
39;s probably best that this type have a well-defined name. And that name c=
an't be `Callable<void()>`.</span></span></blockquote><div><br></=
div><div>Yes it can, let me show you why:</div></div></blockquote><div></di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br></=
div><div>Imagine a pure abstract base class <font style=3D"font-weight:bold=
" face=3D"courier new, monospace">BaseClass </font><font face=3D"arial, san=
s-serif">and a derived class </font><font face=3D"courier new, monospace"><=
b>DerivedClass</b></font><font style=3D"font-weight:bold" face=3D"courier n=
ew, monospace">:</font></div><div><div style=3D"font-family:"courier n=
ew",monospace;font-weight:bold;background-color:rgb(250,250,250);borde=
r-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:brea=
k-word"><code><div><font color=3D"#660066"><span style=3D"color:#008">class=
</span><span style=3D"color:#000"> </span><span style=3D"color:#606">BaseCl=
ass</span><span style=3D"color:#660">{</span><span style=3D"color:#000"><br=
>=C2=A0</span><span style=3D"color:#008">public</span><span style=3D"color:=
#660">:</span><span style=3D"color:#000"><br>=C2=A0 </span><span style=3D"c=
olor:#008">virtual</span><span style=3D"color:#000"> </span><span style=3D"=
color:#008">void</span><span style=3D"color:#000"> </span><span style=3D"co=
lor:#008">operator</span><span style=3D"color:#660">()()</span><span style=
=3D"color:#000"> </span><span style=3D"color:#660">=3D</span><span style=3D=
"color:#000"> </span><span style=3D"color:#066">0</span><span style=3D"colo=
r:#660">;</span><span style=3D"color:#000"> <br></span><span style=3D"color=
:#660">};</span><span style=3D"color:#000"><br><br></span><span style=3D"co=
lor:#008">class</span><span style=3D"color:#000"> </span><span style=3D"col=
or:#606">DerivedClass</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">:</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#008">public</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#606">BaseClass</span><span style=3D"color:#660">{</span><span style=
=3D"color:#000"><br>=C2=A0</span><span style=3D"color:#008">public</span><s=
pan style=3D"color:#660">:</span><span style=3D"color:#000"><br>=C2=A0 </sp=
an><span style=3D"color:#008">void</span><span style=3D"color:#000"> </span=
><span style=3D"color:#008">operator</span><span style=3D"color:#660">()()<=
/span><span style=3D"color:#000"> </span><span style=3D"color:#008">overrid=
e</span><span style=3D"color:#000"> </span><span style=3D"color:#660">{</sp=
an><span style=3D"color:#800">/*Whatever*/</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></span></font></div></code></div><fo=
nt face=3D"arial, sans-serif">Now imagine a vector of </font><font face=3D"=
courier new, monospace"><b>BaseClass </b></font><font face=3D"arial, sans-s=
erif">objects in which e.g. </font><font face=3D"courier new, monospace"><b=
>DerivedClass </b></font><font face=3D"arial, sans-serif">objects can be in=
serted.</font></div></div></blockquote><div><br>That would have to be a `ve=
ctor<BaseClass*>`. Which would be different from `vector<BaseClass=
>`.<br>=C2=A0</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><font face=3D"arial, sans-serif"></font></div><div><font face=
=3D"arial, sans-serif">Your argument would be, that std::vector<BaseClas=
s>::value_<wbr>type needs to be a concrete type, </font><b><font face=3D=
"arial, sans-serif">which it is, its=C2=A0</font><font face=3D"courier new,=
monospace">BaseClass</font><font face=3D"arial, sans-serif">.</font></b></=
div></div></blockquote><div><br>No, my argument is that `Callable<void()=
>` is a <i>concept</i>. Concepts <i>are not types</i>; in the current TS=
, they are either functions or variables, neither of which is a <i>type</i>=
..<br><br>Therefore, `vector<Callable<void()>>::value_type` <i>c=
annot be</i> `Callable<void()>`.<br><br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;"><div dir=3D"ltr"><div><font face=3D"arial, sans-serif=
">Still that doesn't mean, It will actually be DerivedClass in all tran=
slation units, but thats how this mechanism is supposed to work.</font></di=
v><div><font face=3D"arial, sans-serif">For <i>Dynamic Concepts, </i>this i=
s the way, Mingxing Wang proposed it: as pure virtual base class.</font></d=
iv></div></blockquote><div><br>In order to have "dynamic concepts"=
;, you need some construct to refer to such a thing, which must by necessit=
y be <i>different</i> from how you refer to <i>static</i> concepts. `Callab=
le<>` is a static concept, so if you want to make a dynamic concept b=
ased on it, you must use some other syntax besides `Callable<>`.<br><=
br>That's my point. You can't have `Callable<>` be both a sta=
tic and dynamic concept. That's why its best to make "dynamic conc=
epts" specifically be types.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/09ec869a-2c1d-4fe8-8295-253e5001edd4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/09ec869a-2c1d-4fe8-8295-253e5001edd4=
%40isocpp.org</a>.<br />
------=_Part_3152_1491932021.1494340748237--
------=_Part_3151_357011682.1494340748237--
.
Author: Mingxin Wang <wmx16835vv@163.com>
Date: Tue, 9 May 2017 08:34:30 -0700 (PDT)
Raw View
------=_Part_4455_51006967.1494344070453
Content-Type: multipart/alternative;
boundary="----=_Part_4456_1364826697.1494344070453"
------=_Part_4456_1364826697.1494344070453
Content-Type: text/plain; charset="UTF-8"
From my point of view, we can have both
template <class F, class... Args>
concept bool Callable() {...}
and
template <class F, class... Args>
interface Callable {...}
The "*concepts*" ensures the types to be *well-formed* at compile-time, and
the "*interfaces*" (I am still trying to find a more appropriate name)
performs *type deduction* at runtime.
Informally, the "*interfaces*" is a typical user to "*concepts*".
Thank you!
Mingxin Wang
On Tuesday, May 9, 2017 at 10:39:08 PM UTC+8, Nicol Bolas wrote:
>
> On Tuesday, May 9, 2017 at 4:34:19 AM UTC-4, Jakob Riedle wrote:
>>
>> *Concerning the Answer by Nicol Bolas*
>>
>>> `vector<Callable<void()>>::value_type` needs to be a specific type (one
>>> that is the same in all translation units),
>>
>> and it's probably best that this type have a well-defined name. And that
>>> name can't be `Callable<void()>`.
>>
>>
>> Yes it can, let me show you why:
>>
>
>> Imagine a pure abstract base class BaseClass and a derived class
>> *DerivedClass*:
>> class BaseClass{
>> public:
>> virtual void operator()() = 0;
>> };
>>
>> class DerivedClass : public BaseClass{
>> public:
>> void operator()() override {/*Whatever*/}
>> };
>> Now imagine a vector of *BaseClass *objects in which e.g. *DerivedClass *objects
>> can be inserted.
>>
>
> That would have to be a `vector<BaseClass*>`. Which would be different
> from `vector<BaseClass>`.
>
>
>> Your argument would be, that std::vector<BaseClass>::value_type needs to
>> be a concrete type, *which it is, its BaseClass.*
>>
>
> No, my argument is that `Callable<void()>` is a *concept*. Concepts *are
> not types*; in the current TS, they are either functions or variables,
> neither of which is a *type*.
>
> Therefore, `vector<Callable<void()>>::value_type` *cannot be*
> `Callable<void()>`.
>
> Still that doesn't mean, It will actually be DerivedClass in all
>> translation units, but thats how this mechanism is supposed to work.
>> For *Dynamic Concepts, *this is the way, Mingxing Wang proposed it: as
>> pure virtual base class.
>>
>
> In order to have "dynamic concepts", you need some construct to refer to
> such a thing, which must by necessity be *different* from how you refer
> to *static* concepts. `Callable<>` is a static concept, so if you want to
> make a dynamic concept based on it, you must use some other syntax besides
> `Callable<>`.
>
> That's my point. You can't have `Callable<>` be both a static and dynamic
> concept. That's why its best to make "dynamic concepts" specifically be
> types.
>
--
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/0a9d820d-7fb3-4adf-86a3-e55b05396d72%40isocpp.org.
------=_Part_4456_1364826697.1494344070453
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><font face=3D"georgia, serif">From my point of view, =
we can have both</font></div><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"><div class=3D"subprettyprint">template <class F, class... Args></d=
iv><div class=3D"subprettyprint">concept bool Callable() {...}</div></div><=
/code></div><font face=3D"georgia, serif">and</font></div><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"><div class=3D"subprettyprint">template &l=
t;class F, class... Args></div><div class=3D"subprettyprint">interface C=
allable {...}</div></div></code></div><font face=3D"georgia, serif"><br>The=
"<b>concepts</b>" ensures the types to be <b>well-formed</b> at =
compile-time, and the "<b>interfaces</b>" (I am still trying to f=
ind a more appropriate name) performs <b>type=C2=A0deduction</b> at runtime=
..</font></div><div><font face=3D"georgia, serif"><br></font></div><div><fon=
t face=3D"georgia, serif">Informally, the "<b>interfaces</b>" is =
a typical user to "<b>concepts</b>".</font></div><div><font face=
=3D"georgia, serif"><br></font></div><div><font face=3D"georgia, serif">Tha=
nk you!</font></div><div><font face=3D"georgia, serif"><br></font></div><di=
v><font face=3D"georgia, serif">Mingxin Wang<br></font></div><br>On Tuesday=
, May 9, 2017 at 10:39:08 PM UTC+8, Nicol Bolas wrote:<blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div dir=3D"ltr">On Tuesday, May 9, 2017 at 4:34:19=
AM UTC-4, Jakob Riedle wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr"><div><span style=3D"background-color:rgb(250,250,250)"><font co=
lor=3D"#000000" face=3D"arial, sans-serif"><b>Concerning the Answer by Nico=
l Bolas</b></font></span></div><div><span style=3D"background-color:rgb(250=
,250,250)"><font color=3D"#000000" face=3D"arial, sans-serif"><b></b></font=
></span></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style=
=3D"background-color:rgb(250,250,250)"><span style=3D"background-color:rgb(=
255,255,255)">`vector<Callable<void()>>::</span><span style=3D"=
background-color:rgb(255,255,255)">val<wbr>ue_type` needs to be a specific =
type (one that is the same in all translation units),</span></span>=C2=A0</=
blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style=3D=
"background-color:rgb(250,250,250)"><span style=3D"background-color:rgb(255=
,255,255)">and it's probably best that this type have a well-defined na=
me. And that name can't be `Callable<void()>`.</span></span></blo=
ckquote><div><br></div><div>Yes it can, let me show you why:</div></div></b=
lockquote><div></div><blockquote class=3D"gmail_quote" style=3D"margin:0;ma=
rgin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r"><div><br></div><div>Imagine a pure abstract base class <font style=3D"fo=
nt-weight:bold" face=3D"courier new, monospace">BaseClass </font><font face=
=3D"arial, sans-serif">and a derived class </font><font face=3D"courier new=
, monospace"><b>DerivedClass</b></font><font style=3D"font-weight:bold" fac=
e=3D"courier new, monospace">:</font></div><div><div style=3D"font-family:&=
quot;courier new",monospace;font-weight:bold;background-color:rgb(250,=
250,250);border-color:rgb(187,187,187);border-style:solid;border-width:1px;=
word-wrap:break-word"><code><div><font color=3D"#660066"><span style=3D"col=
or:#008">class</span><span style=3D"color:#000"> </span><span style=3D"colo=
r:#606">BaseClass</span><span style=3D"color:#660">{</span><span style=3D"c=
olor:#000"><br>=C2=A0</span><span style=3D"color:#008">public</span><span s=
tyle=3D"color:#660">:</span><span style=3D"color:#000"><br>=C2=A0 </span><s=
pan style=3D"color:#008">virtual</span><span style=3D"color:#000"> </span><=
span style=3D"color:#008">void</span><span style=3D"color:#000"> </span><sp=
an style=3D"color:#008">operator</span><span style=3D"color:#660">()()</spa=
n><span style=3D"color:#000"> </span><span style=3D"color:#660">=3D</span><=
span style=3D"color:#000"> </span><span style=3D"color:#066">0</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><spa=
n style=3D"color:#008">class</span><span style=3D"color:#000"> </span><span=
style=3D"color:#606">DerivedClass</span><span style=3D"color:#000"> </span=
><span style=3D"color:#660">:</span><span style=3D"color:#000"> </span><spa=
n style=3D"color:#008">public</span><span style=3D"color:#000"> </span><spa=
n style=3D"color:#606">BaseClass</span><span style=3D"color:#660">{</span><=
span style=3D"color:#000"><br>=C2=A0</span><span style=3D"color:#008">publi=
c</span><span style=3D"color:#660">:</span><span style=3D"color:#000"><br>=
=C2=A0 </span><span style=3D"color:#008">void</span><span style=3D"color:#0=
00"> </span><span style=3D"color:#008">operator</span><span style=3D"color:=
#660">()()</span><span style=3D"color:#000"> </span><span style=3D"color:#0=
08">override</span><span style=3D"color:#000"> </span><span style=3D"color:=
#660">{</span><span style=3D"color:#800">/*Whatever*/</span><span style=3D"=
color:#660">}</span><span style=3D"color:#000"><br></span><span style=3D"co=
lor:#660">};</span><span style=3D"color:#000"><br></span></font></div></cod=
e></div><font face=3D"arial, sans-serif">Now imagine a vector of </font><fo=
nt face=3D"courier new, monospace"><b>BaseClass </b></font><font face=3D"ar=
ial, sans-serif">objects in which e.g. </font><font face=3D"courier new, mo=
nospace"><b>DerivedClass </b></font><font face=3D"arial, sans-serif">object=
s can be inserted.</font></div></div></blockquote><div><br>That would have =
to be a `vector<BaseClass*>`. Which would be different from `vector&l=
t;BaseClass>`.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D=
"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><div><font face=3D"arial, sans-serif"></font></div><div><fon=
t face=3D"arial, sans-serif">Your argument would be, that std::vector<Ba=
seClass>::value_<wbr>type needs to be a concrete type, </font><b><font f=
ace=3D"arial, sans-serif">which it is, its=C2=A0</font><font face=3D"courie=
r new, monospace">BaseClass</font><font face=3D"arial, sans-serif">.</font>=
</b></div></div></blockquote><div><br>No, my argument is that `Callable<=
void()>` is a <i>concept</i>. Concepts <i>are not types</i>; in the curr=
ent TS, they are either functions or variables, neither of which is a <i>ty=
pe</i>.<br><br>Therefore, `vector<Callable<void()>>::<wbr>value=
_type` <i>cannot be</i> `Callable<void()>`.<br><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"><div><font face=3D"arial, sans=
-serif">Still that doesn't mean, It will actually be DerivedClass in al=
l translation units, but thats how this mechanism is supposed to work.</fon=
t></div><div><font face=3D"arial, sans-serif">For <i>Dynamic Concepts, </i>=
this is the way, Mingxing Wang proposed it: as pure virtual base class.</fo=
nt></div></div></blockquote><div><br>In order to have "dynamic concept=
s", you need some construct to refer to such a thing, which must by ne=
cessity be <i>different</i> from how you refer to <i>static</i> concepts. `=
Callable<>` is a static concept, so if you want to make a dynamic con=
cept based on it, you must use some other syntax besides `Callable<>`=
..<br><br>That's my point. You can't have `Callable<>` be both=
a static and dynamic concept. That's why its best to make "dynami=
c concepts" specifically be types.</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" 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/0a9d820d-7fb3-4adf-86a3-e55b05396d72%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0a9d820d-7fb3-4adf-86a3-e55b05396d72=
%40isocpp.org</a>.<br />
------=_Part_4456_1364826697.1494344070453--
------=_Part_4455_51006967.1494344070453--
.
Author: Barry Revzin <barry.revzin@gmail.com>
Date: Tue, 9 May 2017 09:00:18 -0700 (PDT)
Raw View
------=_Part_2005_1479491446.1494345618842
Content-Type: multipart/alternative;
boundary="----=_Part_2006_96908170.1494345618842"
------=_Part_2006_96908170.1494345618842
Content-Type: text/plain; charset="UTF-8"
On Tuesday, May 9, 2017 at 10:34:30 AM UTC-5, Mingxin Wang wrote:
>
> From my point of view, we can have both
> template <class F, class... Args>
> concept bool Callable() {...}
> and
> template <class F, class... Args>
> interface Callable {...}
>
> The "*concepts*" ensures the types to be *well-formed* at compile-time,
> and the "*interfaces*" (I am still trying to find a more appropriate
> name) performs *type deduction* at runtime.
>
> Informally, the "*interfaces*" is a typical user to "*concepts*".
>
There's no reason to have both. They are the same thing. With Concepts TS,
it's just a constraint placed on types for function templates and class
templates. What we're talking about here is more runtime polymorphism - but
the interface we're defining is exactly the same thing. We don't need two
keywords with two sets of rules.
Also, could you please stop excessively formatting all your posts? When
every 5th word is bold, it makes it harder to read.
That's my point. You can't have `Callable<>` be both a static and dynamic
> concept. That's why its best to make "dynamic concepts" specifically be
> types.
Yeah, maybe you need some kind of annotation on the type. It could be
"virtual Callable<>" (from Andy Prowl's opus), it could be
"erased<Callable<>>" (where erased is either a library that is
implementable with reflection or some compiler intrinsic that is not
implementable in C++), it could be "Callable<>@" (where @ is a placeholder
for some arbitrary annotation to differentiate this type-erased form). I
don't want to get too bikeshed-y on what the annotation looks like, but I
think the main point is simply to have an easy way to map from Concept to
polymorphic type.
* Reusing Concepts as interfaces is a appealing idea but we have already
> seen in this thread what a can of worms this opens, unfortunately. If
> anyone can disentangle this into a manageable set of rules I would be all
> for it, but the problems pointed out, that a concept can contain
> requirements for free functions, types etc, and thus the virtual pointer
> table is not enough to express the resulting polymorphism.
I do not think it is a good solution to introduce a new kind of Concept
(Concepts Lite Lite?) just to address this problem. Sure, Concepts that
require a typename can't be immediately translated - but that's an easy and
obvious rule to remember. Free functions vs member functions isn't really a
problem. Besides, if you add interfaces as a special thing, the immediate
followup question is "why do I need to incur runtime overhead for using
this when I don't have to?" And if you allow interfaces to behave like
concepts in terms of constraining function templates... well, then, aren't
they just concepts anyway?
--
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/1a6874ec-ecbd-483a-82e6-3084a7d982dc%40isocpp.org.
------=_Part_2006_96908170.1494345618842
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, May 9, 2017 at 10:34:30 AM UTC-5, Ming=
xin Wang 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=
"><div><font face=3D"georgia, serif">From my point of view, we can have bot=
h</font></div><div><div style=3D"border:1px solid rgb(187,187,187);word-wra=
p:break-word;background-color:rgb(250,250,250)"><code><div><div>template &l=
t;class F, class... Args></div><div>concept bool Callable() {...}</div><=
/div></code></div><font face=3D"georgia, serif">and</font></div><div><div s=
tyle=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;background-c=
olor:rgb(250,250,250)"><code><div><div>template <class F, class... Args&=
gt;</div><div>interface Callable {...}</div></div></code></div><font face=
=3D"georgia, serif"><br>The "<b>concepts</b>" ensures the types t=
o be <b>well-formed</b> at compile-time, and the "<b>interfaces</b>&qu=
ot; (I am still trying to find a more appropriate name) performs <b>type=C2=
=A0deduction</b> at runtime.</font></div><div><font face=3D"georgia, serif"=
><br></font></div><div><font face=3D"georgia, serif">Informally, the "=
<b>interfaces</b>" is a typical user to "<b>concepts</b>".</=
font></div></div></blockquote><div><br></div><div>There's no reason to =
have both. They are the same thing. With Concepts TS, it's just a const=
raint placed on types for function templates and class templates. What we&#=
39;re talking about here is more runtime polymorphism - but the interface w=
e're defining is exactly the same thing. We don't need two keywords=
with two sets of rules.=C2=A0</div><div><br></div><div>Also, could you ple=
ase stop excessively formatting all your posts? When every 5th word is bold=
, it makes it harder to read.=C2=A0</div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid=
rgb(204, 204, 204); padding-left: 1ex;">That's my point. You can't=
have `Callable<>` be both a static and dynamic concept. That's w=
hy its best to make "dynamic concepts" specifically be types.</bl=
ockquote><div><br></div><div>Yeah, maybe you need some kind of annotation o=
n the type. It could be "virtual Callable<>" (from Andy Pro=
wl's opus), it could be "erased<Callable<>>" (whe=
re erased is either a library that is implementable with reflection or some=
compiler intrinsic that is not implementable in C++), it could be "Ca=
llable<>@" (where @ is a placeholder for some arbitrary annotati=
on to differentiate this type-erased form). I don't want to get too bik=
eshed-y on what the annotation looks like, but I think the main point is si=
mply to have an easy way to map from Concept to polymorphic type.=C2=A0</di=
v><div><br></div><div><blockquote class=3D"gmail_quote" style=3D"margin: 0p=
x 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1=
ex;">* Reusing Concepts as interfaces is a appealing idea but we have alrea=
dy seen in this thread what a can of worms this opens, unfortunately. If an=
yone can disentangle this into a manageable set of rules I would be all for=
it, but the problems pointed out, that a concept can contain requirements =
for free functions, types etc, and thus the virtual pointer table is not en=
ough to express the resulting polymorphism.</blockquote></div><div><br></di=
v><div>I do not think it is a good solution to introduce a new kind of Conc=
ept (Concepts Lite Lite?) just to address this problem. Sure, Concepts that=
require a typename can't be immediately translated - but that's an=
easy and obvious rule to remember. Free functions vs member functions isn&=
#39;t really a problem. Besides, if you add interfaces as a special thing, =
the immediate followup question is "why do I need to incur runtime ove=
rhead for using this when I don't have to?" And if you allow inter=
faces to behave like concepts in terms of constraining function templates..=
.. well, then, aren't they just concepts anyway?</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/1a6874ec-ecbd-483a-82e6-3084a7d982dc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1a6874ec-ecbd-483a-82e6-3084a7d982dc=
%40isocpp.org</a>.<br />
------=_Part_2006_96908170.1494345618842--
------=_Part_2005_1479491446.1494345618842--
.
Author: Jakob Riedle <jakob.riedle@gmail.com>
Date: Tue, 9 May 2017 09:19:48 -0700 (PDT)
Raw View
------=_Part_1274_354219459.1494346788659
Content-Type: multipart/alternative;
boundary="----=_Part_1275_311731125.1494346788659"
------=_Part_1275_311731125.1494346788659
Content-Type: text/plain; charset="UTF-8"
Am Dienstag, 9. Mai 2017 16:39:08 UTC+2 schrieb Nicol Bolas:
>
> That would have to be a `vector<BaseClass*>`. Which would be different
> from `vector<BaseClass>`.
>
Yeah, I was aiming for std::vector<BaseClass&>, sorry for the ambiguity.
*[Note: Having a reference here introduces some new difficulties with
lifetime,*
*but I think my point is independent of that: Generic Functions/*
*Translation Units are usually independent of the concrete Type]*
> No, my argument is that `Callable<void()>` is a *concept*. Concepts *are
> not types*; in the current TS, they are either functions or variables,
> neither of which is a *type*.
> [...]
> That's my point. You can't have `Callable<>` be both a static and dynamic
> concept. That's why its best to make "dynamic concepts" specifically be
> types.
>
You are right on that. However, I defined the use of Callable<> in
different contexts quite clearly (did I not?):
void func(){
> // ...
> }
> int main(){
> // Here the concept 'Callable<>' is used at a non-deduced context (where
> no deduction happens)
> // Therefore, the Callable<> will automatically be interpreted as an *abstract
> class* (Dynamic Concept) to which other types can be type erased to.
> std::vector<Callable> myVec;
> myVec.emplace( &func );
> }
> class MyClass{
> std::vector<Callable> myVec; // same applies here since we are in an
> undeduced context
> void set_vector( std::vector<Callable> newVec ){ // This is still a
> function template where Callable might be deduced as std::function<void()>
> std::move(newVec.begin(),newVec.end(),std::back_inserter(myVec)); //
> Here an implicit conversion happens from the potentially specialized
> std::function<void()> to type erased Callables
}
> }
[...]
`Callable<>` is a static concept, so if you want to make a dynamic concept
> based on it, you must use some other syntax besides `Callable<>`.
>
Is this question now solved?
I should explicate here, that I personally strive for exactly this
ambiguity to allow going hand in hand with "normal" concepts.
Actually, I see your point of ambiguity very clearly.
But maybe you have this perspective, because the different applications of
a concepts name are not going hand in hand (yet). Is that true?
In the following I will argue, why we should strive to reconcile Dynamic
and "Static" Concepts to go hand in hand with each other,
much like compile time and runtime constexpr function execution does.
*Plea to complete the symmetry to constexpr functions:*
Constexpr functions operate on Values. Values have to have a data type,
that means in an abstract way,
*data types are concepts (subsets of) the infinite set of potential values*.
Concepts (from Concepts Lite) also represent subsets, but not upon values
but upon the infinite set of potential types.
*Trying to interwine both principles:*
- If you pass constant (known at compilation) values into a constexpr
function, you immediately can work with it and determine everything you
want at compile time.
- If you pass constant (known at compilation) types into a templated
function/class, you immediately can work with it and determine everything
you want at compile time.
- If you pass a dynamic (only known at runtime) values into a constexpr
function, you need to defer all work to the run time.
- If you pass a dynamic (only known at compilation due to polymorphism)
types into a templated function/class, you need to defer all work to
runtime.
Data types (as mentioned above), guarantee certain subset of possible
values a variable of that type can have.
Concepts guaratee a certain subsets of types.
In order to be able to defer an operations on concrete types (restricted by
a concept) to run time,
dynamic concepts have to make the symmetry complete.
Yours cincerely,
Jakob
--
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/9a9e46d5-ed24-40d8-8451-8b32ec0146d5%40isocpp.org.
------=_Part_1275_311731125.1494346788659
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Am Dienstag, 9. Mai 2017 16:39:08 UTC+2 schrieb Nicol Bola=
s:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>That w=
ould have to be a `vector<BaseClass*>`. Which would be different from=
`vector<BaseClass>`.<br></div></div></blockquote><div><br></div><div=
>Yeah, I was aiming for std::vector<BaseClass&>, sorry for the am=
biguity.</div><div><br></div><div><i>[Note: Having a reference here introdu=
ces some new difficulties with lifetime,</i></div><div><i>but I think my po=
int is independent of that: Generic Functions/</i></div><div><i>Translation=
Units are usually independent of the concrete Type]</i></div><div>=C2=A0</=
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 dir=
=3D"ltr"><div>No, my argument is that `Callable<void()>` is a <i>conc=
ept</i>. Concepts <i>are not types</i>; in the current TS, they are either =
functions or variables, neither of which is a <i>type</i>.<br></div></div><=
div>[...]</div><div>That's my point. You can't have `Callable<&g=
t;` be both a static and dynamic concept. That's why its best to make &=
quot;dynamic concepts" specifically be types.</div></div></blockquote>=
<div><br></div><div>You are right on that. However, I defined the use of Ca=
llable<> in different contexts quite clearly (did I not?):</div><div>=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.=
8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><span s=
tyle=3D"font-family: monospace; background-color: rgb(250, 250, 250); color=
: rgb(0, 0, 136);">void</span><span style=3D"font-family: monospace; backgr=
ound-color: rgb(250, 250, 250); color: rgb(0, 0, 0);">=C2=A0func</span><spa=
n style=3D"font-family: monospace; background-color: rgb(250, 250, 250); co=
lor: rgb(102, 102, 0);">(){<br></span><span style=3D"font-family: monospace=
; background-color: rgb(250, 250, 250); color: rgb(0, 0, 0);">=C2=A0</span>=
<span style=3D"font-family: monospace; background-color: rgb(250, 250, 250)=
; color: rgb(136, 0, 0);">// ...<br></span><span style=3D"font-family: mono=
space; background-color: rgb(250, 250, 250); color: rgb(102, 102, 0);">}</s=
pan><span style=3D"font-family: monospace; background-color: rgb(250, 250, =
250); color: rgb(0, 0, 0);"><br></span><span style=3D"font-family: monospac=
e; background-color: rgb(250, 250, 250); color: rgb(0, 0, 136);">int</span>=
<span style=3D"font-family: monospace; background-color: rgb(250, 250, 250)=
; color: rgb(0, 0, 0);">=C2=A0main</span><span style=3D"font-family: monosp=
ace; background-color: rgb(250, 250, 250); color: rgb(102, 102, 0);">(){<br=
></span><span style=3D"font-family: monospace; background-color: rgb(250, 2=
50, 250); color: rgb(136, 0, 0);">// Here the concept 'Callable<>=
' is used at a non-deduced context (where no deduction happens)<br></sp=
an><span style=3D"font-family: monospace; background-color: rgb(250, 250, 2=
50); color: rgb(136, 0, 0);">// Therefore, the Callable<> will automa=
tically be interpreted as an <b>abstract class</b>=C2=A0(Dynamic Concept) t=
o which other types can be type erased to.<br></span><span style=3D"font-fa=
mily: monospace; background-color: rgb(250, 250, 250); color: rgb(0, 0, 0);=
">std</span><span style=3D"font-family: monospace; background-color: rgb(25=
0, 250, 250); color: rgb(102, 102, 0);">::</span><span style=3D"font-family=
: monospace; background-color: rgb(250, 250, 250); color: rgb(0, 0, 0);">ve=
ctor</span><span style=3D"font-family: monospace; background-color: rgb(250=
, 250, 250); color: rgb(102, 102, 0);"><</span><span style=3D"font-famil=
y: monospace; background-color: rgb(250, 250, 250); color: rgb(102, 0, 102)=
;">Callable</span><span style=3D"font-family: monospace; background-color: =
rgb(250, 250, 250); color: rgb(102, 102, 0);">></span><span style=3D"fon=
t-family: monospace; background-color: rgb(250, 250, 250); color: rgb(0, 0,=
0);">=C2=A0myVec</span><span style=3D"font-family: monospace; background-c=
olor: rgb(250, 250, 250); color: rgb(102, 102, 0);">;<br></span><span style=
=3D"font-family: monospace; background-color: rgb(250, 250, 250); color: rg=
b(0, 0, 0);">myVec</span><span style=3D"font-family: monospace; background-=
color: rgb(250, 250, 250); color: rgb(102, 102, 0);">.</span><span style=3D=
"font-family: monospace; background-color: rgb(250, 250, 250); color: rgb(0=
, 0, 0);">emplace</span><span style=3D"font-family: monospace; background-c=
olor: rgb(250, 250, 250); color: rgb(102, 102, 0);">(</span><span style=3D"=
font-family: monospace; background-color: rgb(250, 250, 250); color: rgb(0,=
0, 0);">=C2=A0</span><span style=3D"font-family: monospace; background-col=
or: rgb(250, 250, 250); color: rgb(102, 102, 0);">&</span><span style=
=3D"font-family: monospace; background-color: rgb(250, 250, 250); color: rg=
b(0, 0, 0);">func=C2=A0</span><span style=3D"font-family: monospace; backgr=
ound-color: rgb(250, 250, 250); color: rgb(102, 102, 0);">);<br></span><spa=
n style=3D"font-family: monospace; background-color: rgb(250, 250, 250); co=
lor: rgb(102, 102, 0);">}</span><span style=3D"font-family: monospace; back=
ground-color: rgb(250, 250, 250); color: rgb(0, 0, 0);"><br></span><span st=
yle=3D"font-family: monospace; background-color: rgb(250, 250, 250); color:=
rgb(0, 0, 136);">class</span><span style=3D"font-family: monospace; backgr=
ound-color: rgb(250, 250, 250); color: rgb(0, 0, 0);">=C2=A0</span><span st=
yle=3D"font-family: monospace; background-color: rgb(250, 250, 250); color:=
rgb(102, 0, 102);">MyClass</span><span style=3D"font-family: monospace; ba=
ckground-color: rgb(250, 250, 250); color: rgb(102, 102, 0);">{<br></span><=
span style=3D"font-family: monospace; background-color: rgb(250, 250, 250);=
color: rgb(0, 0, 0);">=C2=A0std</span><span style=3D"font-family: monospac=
e; background-color: rgb(250, 250, 250); color: rgb(102, 102, 0);">::</span=
><span style=3D"font-family: monospace; background-color: rgb(250, 250, 250=
); color: rgb(0, 0, 0);">vector</span><span style=3D"font-family: monospace=
; background-color: rgb(250, 250, 250); color: rgb(102, 102, 0);"><</spa=
n><span style=3D"font-family: monospace; background-color: rgb(250, 250, 25=
0); color: rgb(102, 0, 102);">Callable</span><span style=3D"font-family: mo=
nospace; background-color: rgb(250, 250, 250); color: rgb(102, 102, 0);">&g=
t;</span><span style=3D"font-family: monospace; background-color: rgb(250, =
250, 250); color: rgb(0, 0, 0);">=C2=A0myVec</span><span style=3D"font-fami=
ly: monospace; background-color: rgb(250, 250, 250); color: rgb(102, 102, 0=
);">;</span><span style=3D"font-family: monospace; background-color: rgb(25=
0, 250, 250); color: rgb(0, 0, 0);">=C2=A0</span><span style=3D"font-family=
: monospace; background-color: rgb(250, 250, 250); color: rgb(136, 0, 0);">=
// same applies here since we are in an undeduced context</span><span style=
=3D"font-family: monospace; background-color: rgb(250, 250, 250); color: rg=
b(0, 0, 0);"><br></span><span style=3D"font-family: monospace; background-c=
olor: rgb(250, 250, 250); color: rgb(0, 0, 0);">=C2=A0</span><span style=3D=
"font-family: monospace; background-color: rgb(250, 250, 250); color: rgb(0=
, 0, 136);">void</span><span style=3D"font-family: monospace; background-co=
lor: rgb(250, 250, 250); color: rgb(0, 0, 0);">=C2=A0set_vector</span><span=
style=3D"font-family: monospace; background-color: rgb(250, 250, 250); col=
or: rgb(102, 102, 0);">(</span><span style=3D"font-family: monospace; backg=
round-color: rgb(250, 250, 250); color: rgb(0, 0, 0);">=C2=A0std</span><spa=
n style=3D"font-family: monospace; background-color: rgb(250, 250, 250); co=
lor: rgb(102, 102, 0);">::</span><span style=3D"font-family: monospace; bac=
kground-color: rgb(250, 250, 250); color: rgb(0, 0, 0);">vector</span><span=
style=3D"font-family: monospace; background-color: rgb(250, 250, 250); col=
or: rgb(102, 102, 0);"><</span><span style=3D"font-family: monospace; ba=
ckground-color: rgb(250, 250, 250); color: rgb(102, 0, 102);">Callable</spa=
n><span style=3D"font-family: monospace; background-color: rgb(250, 250, 25=
0); color: rgb(102, 102, 0);">></span><span style=3D"font-family: monosp=
ace; background-color: rgb(250, 250, 250); color: rgb(0, 0, 0);">=C2=A0newV=
ec=C2=A0</span><span style=3D"font-family: monospace; background-color: rgb=
(250, 250, 250); color: rgb(102, 102, 0);">){</span><span style=3D"font-fam=
ily: monospace; background-color: rgb(250, 250, 250); color: rgb(0, 0, 0);"=
>=C2=A0</span><span style=3D"font-family: monospace; background-color: rgb(=
250, 250, 250); color: rgb(136, 0, 0);">// This is still a function templat=
e where Callable might be deduced as std::function<void()><br></span>=
<span style=3D"font-family: monospace; background-color: rgb(250, 250, 250)=
; color: rgb(0, 0, 0);">=C2=A0 </span><span style=3D"font-family: monospace=
; background-color: rgb(250, 250, 250); color: rgb(0, 0, 0);">std</span><sp=
an style=3D"font-family: monospace; background-color: rgb(250, 250, 250); c=
olor: rgb(102, 102, 0);">::</span><span style=3D"font-family: monospace; ba=
ckground-color: rgb(250, 250, 250); color: rgb(0, 0, 0);">move</span><span =
style=3D"font-family: monospace; background-color: rgb(250, 250, 250); colo=
r: rgb(102, 102, 0);">(</span><span style=3D"font-family: monospace; backgr=
ound-color: rgb(250, 250, 250); color: rgb(0, 0, 0);">newVec.begin(),newVec=
..end(),std::back_inserter(myVec)</span><span style=3D"font-family: monospac=
e; background-color: rgb(250, 250, 250); color: rgb(102, 102, 0);">);</span=
><span style=3D"font-family: monospace; background-color: rgb(250, 250, 250=
); color: rgb(0, 0, 0);">=C2=A0</span><span style=3D"font-family: monospace=
; background-color: rgb(250, 250, 250); color: rgb(136, 0, 0);">// Here an =
implicit conversion happens from the potentially specialized std::function&=
lt;<wbr>void()> to type erased Callables</span></blockquote><blockquote =
class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px =
solid rgb(204, 204, 204); padding-left: 1ex;"><span style=3D"font-family: m=
onospace; background-color: rgb(250, 250, 250); color: rgb(0, 0, 0);">=C2=
=A0</span><span style=3D"font-family: monospace; background-color: rgb(250,=
250, 250); color: rgb(102, 102, 0);">}<br></span><span style=3D"font-famil=
y: monospace; background-color: rgb(250, 250, 250); color: rgb(102, 102, 0)=
;">}</span></blockquote><div><br></div><div>[...]</div><div><br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-lef=
t: 1px solid rgb(204, 204, 204); padding-left: 1ex;">`Callable<>` is =
a static concept, so if you want to make a dynamic concept based on it, you=
must use some other syntax besides `Callable<>`.<br></blockquote><di=
v><br></div><div>Is this question now solved?</div><div>I should explicate =
here, that I personally strive for exactly this ambiguity to allow going ha=
nd in hand with "normal" concepts.<br></div><div>Actually, I see =
your point of ambiguity very clearly.</div><div>But maybe you have this per=
spective, because the different applications of a concepts name are not goi=
ng hand in hand (yet). Is that true?</div><div><br></div><div>In the follow=
ing I will argue, why we should strive to reconcile Dynamic and "Stati=
c" Concepts to go hand in hand with each other,</div><div>much like co=
mpile time and runtime constexpr function execution does.</div><div><br></d=
iv><div><br></div><div><font size=3D"4"><u>Plea to complete the symmetry to=
constexpr functions:</u></font></div><div><font size=3D"4"><br></font></di=
v><div>Constexpr functions operate on Values. Values have to have a data ty=
pe, that means in an abstract way,</div><div><b>data types are concepts (su=
bsets of) the infinite set of potential values</b>.</div><div><br></div><di=
v>Concepts (from Concepts Lite) also represent subsets, but not upon values=
but upon the infinite set of potential types.</div><div><br></div><div><i>=
Trying to interwine both principles:</i></div><div><ul><li>If you pass cons=
tant (known at compilation) values into a constexpr function, you immediate=
ly can work with it and determine everything you want at compile time.<br><=
/li><li>If you pass constant=C2=A0(known at compilation) types into a templ=
ated function/class, you immediately can work with it and determine everyth=
ing you want at compile time.<br></li><li>If you pass a dynamic (only known=
at runtime) values into a constexpr function, you need to defer all work t=
o the run time.<br></li><li>If you pass a dynamic (only known at compilatio=
n due to polymorphism) types into a templated function/class, you need to d=
efer all work to runtime.</li></ul></div><div>Data types (as mentioned abov=
e), guarantee certain subset of possible values a variable of that type can=
have.</div><div>Concepts guaratee a certain subsets of types.</div><div>In=
order to be able to defer an operations on concrete types (restricted by a=
concept) to run time,=C2=A0</div><div>dynamic concepts have to make the sy=
mmetry complete.</div><div><br></div><div><br></div><div>Yours cincerely,</=
div><div>Jakob</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/9a9e46d5-ed24-40d8-8451-8b32ec0146d5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9a9e46d5-ed24-40d8-8451-8b32ec0146d5=
%40isocpp.org</a>.<br />
------=_Part_1275_311731125.1494346788659--
------=_Part_1274_354219459.1494346788659--
.
Author: =?UTF-8?Q?Aar=C3=B3n_Bueno_Villares?= <abv150ci@gmail.com>
Date: Tue, 9 May 2017 18:20:45 +0200
Raw View
--001a113dd32256e0ff054f19bf20
Content-Type: text/plain; charset="UTF-8"
The adventages of an interface, I think, is that if you don't implement
some of the features of an interface, the compiler can issue you a compiler
error. So, if you "extends" or "inherit" from an interface, you constraint
yourself to implement everything, as a way to ensure you don't miss
something important. But you are not mandate to extends an interface to
match a concept restriction, but if you has extended an interface, then the
concept checker has its work done. If the received template parameter
didn't extend from the corresponding interface, then the concept checker
must behave in the usual way, checking the type members.
Another adventage of interfaces is that they are self-documented. An
interface like that says what are the required restrictions of a concept,
but don't add any runtime overhead because they can be seen as just
"concept API schemas" or something like that. And I think interfaces like
that are better for newcommers. I think it's easier to "just extend", than
read the concept restrictions.
On 9 May 2017 at 18:00, Barry Revzin <barry.revzin@gmail.com> wrote:
>
>
> On Tuesday, May 9, 2017 at 10:34:30 AM UTC-5, Mingxin Wang wrote:
>>
>> From my point of view, we can have both
>> template <class F, class... Args>
>> concept bool Callable() {...}
>> and
>> template <class F, class... Args>
>> interface Callable {...}
>>
>> The "*concepts*" ensures the types to be *well-formed* at compile-time,
>> and the "*interfaces*" (I am still trying to find a more appropriate
>> name) performs *type deduction* at runtime.
>>
>> Informally, the "*interfaces*" is a typical user to "*concepts*".
>>
>
> There's no reason to have both. They are the same thing. With Concepts TS,
> it's just a constraint placed on types for function templates and class
> templates. What we're talking about here is more runtime polymorphism - but
> the interface we're defining is exactly the same thing. We don't need two
> keywords with two sets of rules.
>
> Also, could you please stop excessively formatting all your posts? When
> every 5th word is bold, it makes it harder to read.
>
> That's my point. You can't have `Callable<>` be both a static and dynamic
>> concept. That's why its best to make "dynamic concepts" specifically be
>> types.
>
>
> Yeah, maybe you need some kind of annotation on the type. It could be
> "virtual Callable<>" (from Andy Prowl's opus), it could be
> "erased<Callable<>>" (where erased is either a library that is
> implementable with reflection or some compiler intrinsic that is not
> implementable in C++), it could be "Callable<>@" (where @ is a placeholder
> for some arbitrary annotation to differentiate this type-erased form). I
> don't want to get too bikeshed-y on what the annotation looks like, but I
> think the main point is simply to have an easy way to map from Concept to
> polymorphic type.
>
> * Reusing Concepts as interfaces is a appealing idea but we have already
>> seen in this thread what a can of worms this opens, unfortunately. If
>> anyone can disentangle this into a manageable set of rules I would be all
>> for it, but the problems pointed out, that a concept can contain
>> requirements for free functions, types etc, and thus the virtual pointer
>> table is not enough to express the resulting polymorphism.
>
>
> I do not think it is a good solution to introduce a new kind of Concept
> (Concepts Lite Lite?) just to address this problem. Sure, Concepts that
> require a typename can't be immediately translated - but that's an easy and
> obvious rule to remember. Free functions vs member functions isn't really a
> problem. Besides, if you add interfaces as a special thing, the immediate
> followup question is "why do I need to incur runtime overhead for using
> this when I don't have to?" And if you allow interfaces to behave like
> concepts in terms of constraining function templates... well, then, aren't
> they just concepts anyway?
>
> --
> 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/1a6874ec-ecbd-483a-
> 82e6-3084a7d982dc%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1a6874ec-ecbd-483a-82e6-3084a7d982dc%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
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/CAMbYJhZjV-A%3DFsbfg8S6Sx5Qp79vJ6unQgDDLLvYqWv9phHrdA%40mail.gmail.com.
--001a113dd32256e0ff054f19bf20
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The adventages of an interface, I think, is that if you do=
n't implement some of the features of an interface, the compiler can is=
sue you a compiler error. So, if you "extends" or "inherit&q=
uot; from an interface, you constraint yourself to implement everything, as=
a way to ensure you don't miss something important. But you are not ma=
ndate to extends an interface to match a concept restriction, but if you ha=
s extended an interface, then the concept checker has its work done. If the=
received template parameter didn't extend from the corresponding inter=
face, then the concept checker must behave in the usual way, checking the t=
ype members.<div><br></div><div>Another adventage of interfaces is that the=
y are self-documented. An interface like that says what are the required re=
strictions of a concept, but don't add any runtime overhead because the=
y can be seen as just "concept API schemas" or something like tha=
t. And I think interfaces like that are better for newcommers. I think it&#=
39;s easier to "just extend", than read the concept restrictions.=
=C2=A0</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"=
>On 9 May 2017 at 18:00, Barry Revzin <span dir=3D"ltr"><<a href=3D"mail=
to:barry.revzin@gmail.com" target=3D"_blank">barry.revzin@gmail.com</a>>=
</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"><br><br>O=
n Tuesday, May 9, 2017 at 10:34:30 AM UTC-5, Mingxin Wang 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"><div><font face=3D"georgia, s=
erif">From my point of view, we can have both</font></div><div><div style=
=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;background-color=
:rgb(250,250,250)"><code><div><div>template <class F, class... Args><=
/div><div>concept bool Callable() {...}</div></div></code></div><font face=
=3D"georgia, serif">and</font></div><div><div style=3D"border:1px solid rgb=
(187,187,187);word-wrap:break-word;background-color:rgb(250,250,250)"><code=
><div><div>template <class F, class... Args></div><div>interface Call=
able {...}</div></div></code></div><font face=3D"georgia, serif"><br>The &q=
uot;<b>concepts</b>" ensures the types to be <b>well-formed</b> at com=
pile-time, and the "<b>interfaces</b>" (I am still trying to find=
a more appropriate name) performs <b>type=C2=A0deduction</b> at runtime.</=
font></div><div><font face=3D"georgia, serif"><br></font></div><div><font f=
ace=3D"georgia, serif">Informally, the "<b>interfaces</b>" is a t=
ypical user to "<b>concepts</b>".</font></div></div></blockquote>=
<div><br></div><div>There's no reason to have both. They are the same t=
hing. With Concepts TS, it's just a constraint placed on types for func=
tion templates and class templates. What we're talking about here is mo=
re runtime polymorphism - but the interface we're defining is exactly t=
he same thing. We don't need two keywords with two sets of rules.=C2=A0=
</div><div><br></div><div>Also, could you please stop excessively formattin=
g all your posts? When every 5th word is bold, it makes it harder to read.=
=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
">That's my point. You can't have `Callable<>` be both a stat=
ic and dynamic concept. That's why its best to make "dynamic conce=
pts" specifically be types.</blockquote><div><br></div><div>Yeah, mayb=
e you need some kind of annotation on the type. It could be "virtual C=
allable<>" (from Andy Prowl's opus), it could be "erase=
d<Callable<>>" (where erased is either a library that is i=
mplementable with reflection or some compiler intrinsic that is not impleme=
ntable in C++), it could be "Callable<>@" (where @ is a pla=
ceholder for some arbitrary annotation to differentiate this type-erased fo=
rm). I don't want to get too bikeshed-y on what the annotation looks li=
ke, but I think the main point is simply to have an easy way to map from Co=
ncept to polymorphic type.=C2=A0</div><div><br></div><div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">* Reusing Concepts as interfaces is a appe=
aling idea but we have already seen in this thread what a can of worms this=
opens, unfortunately. If anyone can disentangle this into a manageable set=
of rules I would be all for it, but the problems pointed out, that a conce=
pt can contain requirements for free functions, types etc, and thus the vir=
tual pointer table is not enough to express the resulting polymorphism.</bl=
ockquote></div><div><br></div><div>I do not think it is a good solution to =
introduce a new kind of Concept (Concepts Lite Lite?) just to address this =
problem. Sure, Concepts that require a typename can't be immediately tr=
anslated - but that's an easy and obvious rule to remember. Free functi=
ons vs member functions isn't really a problem. Besides, if you add int=
erfaces as a special thing, the immediate followup question is "why do=
I need to incur runtime overhead for using this when I don't have to?&=
quot; And if you allow interfaces to behave like concepts in terms of const=
raining function templates... well, then, aren't they just concepts any=
way?</div></div><span class=3D"HOEnZb"><font color=3D"#888888">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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@<wbr>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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1a6874ec-ecbd-483a-82e6-3084a7d982dc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/1a68=
74ec-ecbd-483a-<wbr>82e6-3084a7d982dc%40isocpp.org</a><wbr>.<br>
</font></span></blockquote></div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CAMbYJhZjV-A%3DFsbfg8S6Sx5Qp79vJ6unQg=
DDLLvYqWv9phHrdA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMbYJhZjV-A%3D=
Fsbfg8S6Sx5Qp79vJ6unQgDDLLvYqWv9phHrdA%40mail.gmail.com</a>.<br />
--001a113dd32256e0ff054f19bf20--
.
Author: Jakob Riedle <jakob.riedle@gmail.com>
Date: Tue, 9 May 2017 09:33:10 -0700 (PDT)
Raw View
------=_Part_3310_1063086778.1494347590160
Content-Type: multipart/alternative;
boundary="----=_Part_3311_2029574582.1494347590160"
------=_Part_3311_2029574582.1494347590160
Content-Type: text/plain; charset="UTF-8"
> Another adventage of interfaces is that they are self-documented. An
> interface like that says what are the required restrictions of a concept,
> but don't add any runtime overhead because they can be seen as just
> "concept API schemas" or something like that. And I think interfaces like
> that are better for newcommers. I think it's easier to "just extend", than
> read the concept restrictions.
>
This is a good point, however it can easily be fixed if allowing something
like
class myClass implements Callable<void()>{
//...
};
or
Callable<void()> class MyClass{
//...
};
There is no need for another data structure besides concepts...
But: This is a really good point and IMO really useful!
Cheers,
Jakob
--
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/88cd4578-0b30-45d6-8205-87a969383a69%40isocpp.org.
------=_Part_3311_2029574582.1494347590160
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">Another adventage of interfaces is that they are self-documented. =
An interface like that says what are the required restrictions of a concept=
, but don't add any runtime overhead because they can be seen as just &=
quot;concept API schemas" or something like that. And I think interfac=
es like that are better for newcommers. I think it's easier to "ju=
st extend", than read the concept restrictions.=C2=A0<br></div></block=
quote><div><br></div><div>This is a good point, however it can easily be fi=
xed if allowing something like</div><div class=3D"prettyprint" style=3D"bac=
kground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border=
-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pr=
ettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=
=3D"styled-by-prettify">class</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> myClass </span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">implements</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-p=
rettify">Callable</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify"><</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>=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></span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">};</span></div></c=
ode></div><div></div><div>or</div><div><div class=3D"prettyprint" style=3D"=
background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bor=
der-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D=
"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #606;" cl=
ass=3D"styled-by-prettify">Callable</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify"><</span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">void</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">()></span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
class</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #606;" class=3D"styled-by-prettify">MyClass</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0</span><span sty=
le=3D"color: #800;" 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>Ther=
e is no need for another data structure besides concepts...<br></div></div>=
<div><br></div><div>But: This is a really good point and IMO really useful!=
</div><div><br></div><div>Cheers,</div><div>Jakob</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/88cd4578-0b30-45d6-8205-87a969383a69%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/88cd4578-0b30-45d6-8205-87a969383a69=
%40isocpp.org</a>.<br />
------=_Part_3311_2029574582.1494347590160--
------=_Part_3310_1063086778.1494347590160--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 9 May 2017 11:41:37 -0700 (PDT)
Raw View
------=_Part_1065_418035795.1494355298081
Content-Type: multipart/alternative;
boundary="----=_Part_1066_842818205.1494355298081"
------=_Part_1066_842818205.1494355298081
Content-Type: text/plain; charset="UTF-8"
On Tuesday, May 9, 2017 at 12:19:48 PM UTC-4, Jakob Riedle wrote:
>
> Am Dienstag, 9. Mai 2017 16:39:08 UTC+2 schrieb Nicol Bolas:
>>
>> That would have to be a `vector<BaseClass*>`. Which would be different
>> from `vector<BaseClass>`.
>>
>
> Yeah, I was aiming for std::vector<BaseClass&>, sorry for the ambiguity.
>
> *[Note: Having a reference here introduces some new difficulties with
> lifetime,*
> *but I think my point is independent of that: Generic Functions/*
> *Translation Units are usually independent of the concrete Type]*
>
>
>> No, my argument is that `Callable<void()>` is a *concept*. Concepts *are
>> not types*; in the current TS, they are either functions or variables,
>> neither of which is a *type*.
>> [...]
>> That's my point. You can't have `Callable<>` be both a static and dynamic
>> concept. That's why its best to make "dynamic concepts" specifically be
>> types.
>>
>
> You are right on that. However, I defined the use of Callable<> in
> different contexts quite clearly (did I not?):
>
> void func(){
>> // ...
>> }
>> int main(){
>> // Here the concept 'Callable<>' is used at a non-deduced context (where
>> no deduction happens)
>> // Therefore, the Callable<> will automatically be interpreted as an *abstract
>> class* (Dynamic Concept) to which other types can be type erased to.
>> std::vector<Callable> myVec;
>> myVec.emplace( &func );
>> }
>> class MyClass{
>> std::vector<Callable> myVec; // same applies here since we are in an
>> undeduced context
>> void set_vector( std::vector<Callable> newVec ){ // This is still a
>> function template where Callable might be deduced as std::function<void()>
>> std::move(newVec.begin(),newVec.end(),std::back_inserter(myVec)); //
>> Here an implicit conversion happens from the potentially specialized
>> std::function<void()> to type erased Callables
>
> }
>> }
>
>
> [...]
>
> `Callable<>` is a static concept, so if you want to make a dynamic concept
>> based on it, you must use some other syntax besides `Callable<>`.
>>
>
> Is this question now solved?
> I should explicate here, that I personally strive for exactly this
> ambiguity to allow going hand in hand with "normal" concepts.
> Actually, I see your point of ambiguity very clearly.
> But maybe you have this perspective, because the different applications of
> a concepts name are not going hand in hand (yet). Is that true?
>
> In the following I will argue, why we should strive to reconcile Dynamic
> and "Static" Concepts to go hand in hand with each other, much like compile
> time and runtime constexpr function execution does.
>
The argument is essentially irrelevant because of the vast difference in
the *implementation* of these constructs.
Static concepts are to some degree syntactic sugar. They can provide
overloading on an interface and error messages if you don't implement the
proper interface. But once the proper overload has been found, the compiler
uses the same template substitution and instantiation rules as it always
has. Static concepts are something that the real work of instantiation and
compilation doesn't care about; they never appear in the compiled code.
Dynamic concepts are a completely different thing. Their usage requires the
generation of C++ code: a type which has type-erasure behavior as well as
functions (both member and otherwise) for this new type that forward their
behavior. These are not phantasmal compiler constructs that never appear in
compiled code; they are real things that have real effects on the
executable.
A dynamic concept is, at its core, an *object*; it's part of the compiled
output of a C++ program. Dynamic concepts can be constructed; they can be
members of objects. They are real types that have real objects. They are
not phantasmal compiler constructs; they're living, breathing types with
typenames and everything.
Now, dynamic concepts can be defined *in terms of* static ones. But syntax
which represents a static concept should not be re-used to also represent a
dynamic one. When looking at a piece of code, you should be able to know
when its using a static concept and when it's using a dynamic one.
After all:
void foo(Callable<void()> t);
That should be a template function that takes types fitting the given
concept.
void foo(DynamicCallable<void()> t);
That should be a non-template function that takes a concrete type defined
by the static concept. I'm not very concerned about the syntax that invokes
the latter; what matters is that there is a clear syntactic difference
between the two.
The implementation distinction between these two functions (not to mention
the fact that in the latter case, you can define the function in a
different translation unit) is non-trivial and cannot be ignored.
Therefore, a static concept cannot implicitly be a dynamic concept and
vice-versa.
--
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/eb118137-dc70-45a5-b0cb-f100eefc0bd1%40isocpp.org.
------=_Part_1066_842818205.1494355298081
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, May 9, 2017 at 12:19:48 PM UTC-4, Jakob Riedle=
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">Am Die=
nstag, 9. Mai 2017 16:39:08 UTC+2 schrieb Nicol Bolas:<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>That would have to be a `vector<=
;BaseClass*>`. Which would be different from `vector<BaseClass>`.<=
br></div></div></blockquote><div><br></div><div>Yeah, I was aiming for std:=
:vector<BaseClass&>, sorry for the ambiguity.</div><div><br></div=
><div><i>[Note: Having a reference here introduces some new difficulties wi=
th lifetime,</i></div><div><i>but I think my point is independent of that: =
Generic Functions/</i></div><div><i>Translation Units are usually independe=
nt of the concrete Type]</i></div><div>=C2=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><div>No, my argument is t=
hat `Callable<void()>` is a <i>concept</i>. Concepts <i>are not types=
</i>; in the current TS, they are either functions or variables, neither of=
which is a <i>type</i>.<br></div></div><div>[...]</div><div>That's my =
point. You can't have `Callable<>` be both a static and dynamic c=
oncept. That's why its best to make "dynamic concepts" specif=
ically be types.</div></div></blockquote><div><br></div><div>You are right =
on that. However, I defined the use of Callable<> in different contex=
ts quite clearly (did I not?):</div><div><br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex"><span style=3D"font-family:monospace;background-c=
olor:rgb(250,250,250);color:rgb(0,0,136)">void</span><span style=3D"font-fa=
mily:monospace;background-color:rgb(250,250,250);color:rgb(0,0,0)">=C2=A0fu=
nc</span><span style=3D"font-family:monospace;background-color:rgb(250,250,=
250);color:rgb(102,102,0)">(){<br></span><span style=3D"font-family:monospa=
ce;background-color:rgb(250,250,250);color:rgb(0,0,0)">=C2=A0</span><span s=
tyle=3D"font-family:monospace;background-color:rgb(250,250,250);color:rgb(1=
36,0,0)">// ...<br></span><span style=3D"font-family:monospace;background-c=
olor:rgb(250,250,250);color:rgb(102,102,0)">}</span><span style=3D"font-fam=
ily:monospace;background-color:rgb(250,250,250);color:rgb(0,0,0)"><br></spa=
n><span style=3D"font-family:monospace;background-color:rgb(250,250,250);co=
lor:rgb(0,0,136)">int</span><span style=3D"font-family:monospace;background=
-color:rgb(250,250,250);color:rgb(0,0,0)">=C2=A0main</span><span style=3D"f=
ont-family:monospace;background-color:rgb(250,250,250);color:rgb(102,102,0)=
">(){<br></span><span style=3D"font-family:monospace;background-color:rgb(2=
50,250,250);color:rgb(136,0,0)">// Here the concept 'Callable<>&#=
39; is used at a non-deduced context (where no deduction happens)<br></span=
><span style=3D"font-family:monospace;background-color:rgb(250,250,250);col=
or:rgb(136,0,0)">// Therefore, the Callable<> will automatically be i=
nterpreted as an <b>abstract class</b>=C2=A0(Dynamic Concept) to which othe=
r types can be type erased to.<br></span><span style=3D"font-family:monospa=
ce;background-color:rgb(250,250,250);color:rgb(0,0,0)">std</span><span styl=
e=3D"font-family:monospace;background-color:rgb(250,250,250);color:rgb(102,=
102,0)">::</span><span style=3D"font-family:monospace;background-color:rgb(=
250,250,250);color:rgb(0,0,0)">vector</span><span style=3D"font-family:mono=
space;background-color:rgb(250,250,250);color:rgb(102,102,0)"><</span><s=
pan style=3D"font-family:monospace;background-color:rgb(250,250,250);color:=
rgb(102,0,102)">Callable</span><span style=3D"font-family:monospace;backgro=
und-color:rgb(250,250,250);color:rgb(102,102,0)">></span><span style=3D"=
font-family:monospace;background-color:rgb(250,250,250);color:rgb(0,0,0)">=
=C2=A0myVec</span><span style=3D"font-family:monospace;background-color:rgb=
(250,250,250);color:rgb(102,102,0)">;<br></span><span style=3D"font-family:=
monospace;background-color:rgb(250,250,250);color:rgb(0,0,0)">myVec</span><=
span style=3D"font-family:monospace;background-color:rgb(250,250,250);color=
:rgb(102,102,0)">.</span><span style=3D"font-family:monospace;background-co=
lor:rgb(250,250,250);color:rgb(0,0,0)">emplace</span><span style=3D"font-fa=
mily:monospace;background-color:rgb(250,250,250);color:rgb(102,102,0)">(</s=
pan><span style=3D"font-family:monospace;background-color:rgb(250,250,250);=
color:rgb(0,0,0)">=C2=A0</span><span style=3D"font-family:monospace;backgro=
und-color:rgb(250,250,250);color:rgb(102,102,0)">&</span><span style=3D=
"font-family:monospace;background-color:rgb(250,250,250);color:rgb(0,0,0)">=
func=C2=A0</span><span style=3D"font-family:monospace;background-color:rgb(=
250,250,250);color:rgb(102,102,0)">);<br></span><span style=3D"font-family:=
monospace;background-color:rgb(250,250,250);color:rgb(102,102,0)">}</span><=
span style=3D"font-family:monospace;background-color:rgb(250,250,250);color=
:rgb(0,0,0)"><br></span><span style=3D"font-family:monospace;background-col=
or:rgb(250,250,250);color:rgb(0,0,136)">class</span><span style=3D"font-fam=
ily:monospace;background-color:rgb(250,250,250);color:rgb(0,0,0)">=C2=A0</s=
pan><span style=3D"font-family:monospace;background-color:rgb(250,250,250);=
color:rgb(102,0,102)">MyClass</span><span style=3D"font-family:monospace;ba=
ckground-color:rgb(250,250,250);color:rgb(102,102,0)">{<br></span><span sty=
le=3D"font-family:monospace;background-color:rgb(250,250,250);color:rgb(0,0=
,0)">=C2=A0std</span><span style=3D"font-family:monospace;background-color:=
rgb(250,250,250);color:rgb(102,102,0)">::</span><span style=3D"font-family:=
monospace;background-color:rgb(250,250,250);color:rgb(0,0,0)">vector</span>=
<span style=3D"font-family:monospace;background-color:rgb(250,250,250);colo=
r:rgb(102,102,0)"><</span><span style=3D"font-family:monospace;backgroun=
d-color:rgb(250,250,250);color:rgb(102,0,102)">Callable</span><span style=
=3D"font-family:monospace;background-color:rgb(250,250,250);color:rgb(102,1=
02,0)">></span><span style=3D"font-family:monospace;background-color:rgb=
(250,250,250);color:rgb(0,0,0)">=C2=A0myVec</span><span style=3D"font-famil=
y:monospace;background-color:rgb(250,250,250);color:rgb(102,102,0)">;</span=
><span style=3D"font-family:monospace;background-color:rgb(250,250,250);col=
or:rgb(0,0,0)">=C2=A0</span><span style=3D"font-family:monospace;background=
-color:rgb(250,250,250);color:rgb(136,0,0)"><wbr>// same applies here since=
we are in an undeduced context</span><span style=3D"font-family:monospace;=
background-color:rgb(250,250,250);color:rgb(0,0,0)"><br></span><span style=
=3D"font-family:monospace;background-color:rgb(250,250,250);color:rgb(0,0,0=
)">=C2=A0</span><span style=3D"font-family:monospace;background-color:rgb(2=
50,250,250);color:rgb(0,0,136)">void</span><span style=3D"font-family:monos=
pace;background-color:rgb(250,250,250);color:rgb(0,0,0)">=C2=A0set_vector</=
span><span style=3D"font-family:monospace;background-color:rgb(250,250,250)=
;color:rgb(102,102,0)">(</span><span style=3D"font-family:monospace;backgro=
und-color:rgb(250,250,250);color:rgb(0,0,0)">=C2=A0std</span><span style=3D=
"font-family:monospace;background-color:rgb(250,250,250);color:rgb(102,102,=
0)">::</span><span style=3D"font-family:monospace;background-color:rgb(250,=
250,250);color:rgb(0,0,0)">vector</span><span style=3D"font-family:monospac=
e;background-color:rgb(250,250,250);color:rgb(102,102,0)"><</span><span =
style=3D"font-family:monospace;background-color:rgb(250,250,250);color:rgb(=
102,0,102)"><wbr>Callable</span><span style=3D"font-family:monospace;backgr=
ound-color:rgb(250,250,250);color:rgb(102,102,0)">></span><span style=3D=
"font-family:monospace;background-color:rgb(250,250,250);color:rgb(0,0,0)">=
=C2=A0newVec=C2=A0</span><span style=3D"font-family:monospace;background-co=
lor:rgb(250,250,250);color:rgb(102,102,0)">){</span><span style=3D"font-fam=
ily:monospace;background-color:rgb(250,250,250);color:rgb(0,0,0)">=C2=A0</s=
pan><span style=3D"font-family:monospace;background-color:rgb(250,250,250);=
color:rgb(136,0,0)">// This is still a function template where Callable mig=
ht be deduced as std::function<void()><br></span><span style=3D"font-=
family:monospace;background-color:rgb(250,250,250);color:rgb(0,0,0)">=C2=A0=
</span><span style=3D"font-family:monospace;background-color:rgb(250,250,2=
50);color:rgb(0,0,0)">std</span><span style=3D"font-family:monospace;backgr=
ound-color:rgb(250,250,250);color:rgb(102,102,0)">::</span><span style=3D"f=
ont-family:monospace;background-color:rgb(250,250,250);color:rgb(0,0,0)">mo=
ve</span><span style=3D"font-family:monospace;background-color:rgb(250,250,=
250);color:rgb(102,102,0)">(</span><span style=3D"font-family:monospace;bac=
kground-color:rgb(250,250,250);color:rgb(0,0,0)">newVec.begin(),<wbr>newVec=
..end(),std::back_<wbr>inserter(myVec)</span><span style=3D"font-family:mono=
space;background-color:rgb(250,250,250);color:rgb(102,102,0)">);</span><spa=
n style=3D"font-family:monospace;background-color:rgb(250,250,250);color:rg=
b(0,0,0)">=C2=A0</span><span style=3D"font-family:monospace;background-colo=
r:rgb(250,250,250);color:rgb(136,0,0)">// Here an implicit conversion happe=
ns from the potentially specialized std::function<void()> to type era=
sed Callables</span></blockquote><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex"><span style=3D"font-family:monospace;background-color:rgb(250,250,2=
50);color:rgb(0,0,0)">=C2=A0</span><span style=3D"font-family:monospace;bac=
kground-color:rgb(250,250,250);color:rgb(102,102,0)">}<br></span><span styl=
e=3D"font-family:monospace;background-color:rgb(250,250,250);color:rgb(102,=
102,0)">}</span></blockquote><div><br></div><div>[...]</div><div><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">`Callable<>` is a s=
tatic concept, so if you want to make a dynamic concept based on it, you mu=
st use some other syntax besides `Callable<>`.<br></blockquote><div><=
br></div><div>Is this question now solved?</div><div>I should explicate her=
e, that I personally strive for exactly this ambiguity to allow going hand =
in hand with "normal" concepts.<br></div><div>Actually, I see you=
r point of ambiguity very clearly.</div><div>But maybe you have this perspe=
ctive, because the different applications of a concepts name are not going =
hand in hand (yet). Is that true?</div><div><br></div><div>In the following=
I will argue, why we should strive to reconcile Dynamic and "Static&q=
uot; Concepts to go hand in hand with each other, much like compile time an=
d runtime constexpr function execution does.</div></div></blockquote><div><=
br>The argument is essentially irrelevant because of the vast difference in=
the <i>implementation</i> of these constructs.<br><br>Static concepts are =
to some degree syntactic sugar. They can provide overloading on an interfac=
e and error messages if you don't implement the proper interface. But o=
nce the proper overload has been found, the compiler uses the same template=
substitution and instantiation rules as it always has. Static concepts are=
something that the real work of instantiation and compilation doesn't =
care about; they never appear in the compiled code.<br><br>Dynamic concepts=
are a completely different thing. Their usage requires the generation of C=
++ code: a type which has type-erasure behavior as well as functions (both =
member and otherwise) for this new type that forward their behavior. These =
are not phantasmal compiler constructs that never appear in compiled code; =
they are real things that have real effects on the executable.<br><br>A dyn=
amic concept is, at its core, an <i>object</i>; it's part of the compil=
ed output of a C++ program. Dynamic concepts can be constructed; they can b=
e members of objects. They are real types that have real objects. They are =
not phantasmal compiler constructs; they're living, breathing types wit=
h typenames and everything.<br><br>Now, dynamic concepts can be defined <i>=
in terms of</i> static ones. But syntax which represents a static concept s=
hould not be re-used to also represent a dynamic one. When looking at a pie=
ce of code, you should be able to know when its using a static concept and =
when it's using a dynamic one.<br><br>After all:<br><br><div style=3D"b=
ackground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bord=
er-style: solid; border-width: 1px; overflow-wrap: break-word;" class=3D"pr=
ettyprint"><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"> foo</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #606=
;" class=3D"styled-by-prettify">Callable</span><span style=3D"color: #660;"=
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"st=
yled-by-prettify">()></span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> t</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">);</span></div></code></div><br>That should be a template function th=
at takes types fitting the given concept.<br><br><div style=3D"background-c=
olor: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: s=
olid; border-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint">=
<code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">void</span><span style=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">DynamicCallable</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify"><</span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">void</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">()></span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> t</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></div></code></div><br>That should be a non-template function that take=
s a concrete type defined by the static concept. I'm not very concerned=
about the syntax that invokes the latter; what matters is that there is a =
clear syntactic difference between the two. <br><br>The implementation dist=
inction between these two functions (not to mention the fact that in the la=
tter case, you can define the function in a different translation unit) is =
non-trivial and cannot be ignored. Therefore, a static concept cannot impli=
citly be a dynamic concept and vice-versa.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/eb118137-dc70-45a5-b0cb-f100eefc0bd1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/eb118137-dc70-45a5-b0cb-f100eefc0bd1=
%40isocpp.org</a>.<br />
------=_Part_1066_842818205.1494355298081--
------=_Part_1065_418035795.1494355298081--
.
Author: Mingxin Wang <wmx16835vv@163.com>
Date: Tue, 9 May 2017 20:05:27 -0700 (PDT)
Raw View
------=_Part_698_1686516468.1494385527495
Content-Type: multipart/alternative;
boundary="----=_Part_699_1711729776.1494385527496"
------=_Part_699_1711729776.1494385527496
Content-Type: text/plain; charset="UTF-8"
Dear Mr. Bengt Gustafsson,
Thank you for your comments!
On Tuesday, May 9, 2017 at 3:17:59 PM UTC+8, Bengt Gustafsson wrote:
>
> * I think you are over-using the word "runtime" here. As I understand it
> what's happening is duck-typing: When the compiler sees that a variable of
> some type T is used where an interface I is required it checks if the T at
> hand contains all the methods specified by I. If so it generates (at
> compile time) a virtual function table suitable for I which contains
> pointers to the corresponding functions of T. In the case that the
> corresponding function is virtual and the variable is a reference it seems
> most reasonable to generate a stub function which implements a virtual call
> to the T function using the variable value as "this".
>
I used the word "runtime" NOT to focus on concrete implementations (with
virtual function, smart pointers, etc.), but on the requirements (what we
need is runtime polymorphism).
>
>
* Reusing Concepts as interfaces is a appealing idea but we have already
> seen in this thread what a can of worms this opens, unfortunately. If
> anyone can disentangle this into a manageable set of rules I would be all
> for it, but the problems pointed out, that a concept can contain
> requirements for free functions, types etc, and thus the virtual pointer
> table is not enough to express the resulting polymorphism.
>
The "Concepts" is used for compile-time type safety only. This solution is
not a substitute for the "Concepts", not only because they work on
different stages, but also, as you mentioned, they are at different levels
of support for expressions so far. In other words, this solution is a use
case for the "Concepts".
> * Maybe the keyword interface can be introduced as a contextual keyword
> for this purpose, as in:
>
> struct MyInterface interface {
> // only methods allowed
> };
>
> Maybe the methods should have to be declared virtual inside this construct
> or maybe they are virtual by default.
>
The idea is similar to the "signature" extension of G++ (as Magnus
Fromreide mentioned). This solution does not require implementations to
"know" the interface (thus won't break the code we already have). Once a
type is suitable for a interface, it is convertible to the interface. For
example, suppose we want to store some iterators (may have different types)
in a container and perform some operations with them (only "operator*",
"operator++" and "operator==" are used), we may write the following code
with "interfaces":
template <class T>
interface It {
T operator*();
void operator++(); // The returned value is not required
bool operator==(const It&);
};
std::vector<It<int>> vec;
for (It<int> it : vec) { ... }
> * I don't think that the ownership/lifetime issues should be mixed with
> this duck-typing feature, instead the signature of the (non-template)
> function to be called should express this as in:
>
> void Fun1(MyInterface& p);
> void Fun2(std::unique_ptr<MyInterface> p);
>
> Ok, this does not work: while ownership of the p object is established by
> the signatures above the ownership of the original object is unclear. And
> they can't be the same object as the p object has to consist of the
> (generated) virtual function table and the pointer to the original object
> (with some unknown ownership). This said, it is too weak of an idea to
> automatically infer unique_ptr or shared_ptr as suggested earlier in this
> thread. A very common case will be 'no ownership', i.e. a reference to a
> stack object or similar, and user defined smart pointer templates. Some
> kind of traits class should be able to act as a customization point to
> indicate how p relates to the original object.
>
I was thinking about the same issue before posting this solution, because
the "interfaces" seems to have violated the "single responsibility
principle". Thus, the conversion is only allowed when the concrete
implementations are passed "by value" (as a copy), whose ownership/lifetime
shall be managed within the "interface" system.
Thank you!
Mingxin Wang
>
> Den tisdag 9 maj 2017 kl. 08:36:20 UTC+2 skrev Mingxin Wang:
>>
>> Dear Mr. Fromreide,
>>
>> The "*signatures*" in G++ is a *syntactic sugar* that introduces new
>> rules for declaring virtual member functions. The "*interfaces*" is not
>> only a syntactic sugar, but a style of implementation for polymorphism,
>> enabling types that meet specific requirements implicitly convertible to a
>> same type at runtime.
>>
>> In short, we used to write virtual functions (or "signatures")
>> *manually *to implement polymorphism, but now we can use the
>> "interfaces" to *generate* efficient implementations for polymorphism
>> based on our requirements.
>>
>> Thank you!
>>
>> Mingxin Wang
>>
>> On Tuesday, May 9, 2017 at 1:01:02 PM UTC+8, Magnus Fromreide wrote:
>>>
>>> On Mon, May 08, 2017 at 08:16:23AM -0700, Nicol Bolas wrote:
>>> > On Monday, May 8, 2017 at 10:54:13 AM UTC-4, Thiago Macieira wrote:
>>> > >
>>> > > On Monday, 8 May 2017 00:30:58 PDT Mingxin Wang wrote:
>>> > > > Unlike the "*Concespts*" that work at compile time, the
>>> > > > "*Interfaces*" work at runtime mostly. In essence, it is not only
>>> > > > a syntactic sugar, but a style of implementation for
>>> *polymorphism*:
>>> > > > virtual functions are only generated when required at runtime
>>> > >
>>> > > "virtual functions generated at runtime" needs A LOT of explanation.
>>> > > Please
>>> > > explain how the compiler would implement such a thing.
>>> > >
>>> > > i also recommend finding another name for your feature. "interface"
>>> is a
>>> > > widely
>>> > > known term and means something else: it means a base class with
>>> virtuals
>>> > > that
>>> > > need to be overridden.
>>> > >
>>> >
>>> > I think the idea that he's trying to get across is the following.
>>> >
>>> > An `interface` is a class which is implicitly convertible from any
>>> type
>>> > which matches some concept. The implicit conversion effectively works
>>> by
>>> > storing a type-erased pointer/reference to the object it is converted
>>> from.
>>> >
>>> > The concept it matches is defined by the set of member functions in
>>> the
>>> > `interface`. The `interface` class will automatically generate
>>> matching
>>> > member functions which forward calls to the type-erased
>>> pointer/reference.
>>> >
>>> > So it's not a "virtual" call in the language sense; it's a virtual
>>> call in
>>> > the polymorphic sense.
>>>
>>> So, is this yet another reinvention of the old "signature" extension of
>>> G++?
>>>
>>> https://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC112
>>>
>>> /MF
>>>
>>
--
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/31ce0dab-a80e-4356-a63c-a51ffb56b168%40isocpp.org.
------=_Part_699_1711729776.1494385527496
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><font face=3D"georgia, serif">Dear Mr.=C2=A0Bengt Gus=
tafsson,</font></div><div><font face=3D"georgia, serif"><br></font></div><d=
iv><font face=3D"georgia, serif">Thank you for your comments!</font></div><=
div><br></div>On Tuesday, May 9, 2017 at 3:17:59 PM UTC+8, Bengt Gustafsson=
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 th=
ink you are over-using the word "runtime" here. As I understand i=
t what's happening is duck-typing: When the compiler sees that a variab=
le of some type T is used where an interface I is required it checks if the=
T at hand contains all the methods specified by I. If so it generates (at =
compile time) a virtual function table suitable for I which contains pointe=
rs to the corresponding functions of T. In the case that the corresponding =
function is virtual and the variable is a reference it seems most reasonabl=
e to generate a stub function which implements a virtual call to the T func=
tion using the variable value as "this".</div></blockquote><div><=
br></div><div><font face=3D"georgia, serif">I used the word "runtime&q=
uot; NOT to focus on concrete implementations (with virtual function, smart=
pointers, etc.), but on the requirements (what we need is runtime polymorp=
hism).</font></div><div>=C2=A0<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"><div>=C2=A0<br></div></div></blockquote><blockqu=
ote 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><div>* Reu=
sing Concepts as interfaces is a appealing idea but we have already seen in=
this thread what a can of worms this opens, unfortunately. If anyone can d=
isentangle this into a manageable set of rules I would be all for it, but t=
he problems pointed out, that a concept can contain requirements for free f=
unctions, types etc, and thus the virtual pointer table is not enough to ex=
press the resulting polymorphism.</div></div></blockquote><div><br></div><d=
iv><font face=3D"georgia, serif">The "Concepts" is used for compi=
le-time type safety only. This solution is not a=C2=A0substitute for the &q=
uot;Concepts", not only because they work on different stages, but als=
o, as you mentioned, they are at different levels of support for expression=
s so far. In other words, this solution is a=C2=A0use case for the "Co=
ncepts".</font></div><div><br></div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div dir=3D"ltr"><div><br></div><div>* Maybe the keyword interfa=
ce can be introduced as a contextual keyword for this purpose, as in:</div>=
<div><br></div><div>=C2=A0 =C2=A0 struct MyInterface interface {</div><div>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // only methods allowed</div><div>=C2=A0=
=C2=A0 };</div><div><br></div><div>Maybe the methods should have to be dec=
lared virtual inside this construct or maybe they are virtual by default.</=
div></div></blockquote><div><br></div><div><font face=3D"georgia, serif">Th=
e idea is similar to the "signature" extension of G++ (as Magnus =
Fromreide mentioned). This solution does not require implementations to &qu=
ot;know" the interface (thus won't break the code we already have)=
.. Once a type is suitable for a interface, it is convertible to the interfa=
ce. For example, suppose we want to store some iterators (may have differen=
t types) in a container and perform some operations with them (only "o=
perator*", "operator++" and "operator=3D=3D" are u=
sed), we may write the following code with "interfaces":</font></=
div><div><br></div><div><div class=3D"prettyprint" style=3D"border: 1px sol=
id rgb(187, 187, 187); word-wrap: break-word; background-color: rgb(250, 25=
0, 250);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><font c=
olor=3D"#660066"><div class=3D"subprettyprint">template <class T></di=
v><div class=3D"subprettyprint">interface It {</div><div class=3D"subpretty=
print">=C2=A0 T operator*();</div><div class=3D"subprettyprint">=C2=A0 void=
operator++(); // The returned value is not required</div><div class=3D"sub=
prettyprint">=C2=A0 bool operator=3D=3D(const It&);</div><div class=3D"=
subprettyprint">};</div><div class=3D"subprettyprint"><br></div><div class=
=3D"subprettyprint">std::vector<It<int>> vec;</div><div class=
=3D"subprettyprint"><br></div><div class=3D"subprettyprint">for (It<int&=
gt; it : vec) { ... }</div></font></div></code></div><br></div><blockquote =
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"><div><br></div><div>* I d=
on't think that the ownership/lifetime issues should be mixed with this=
duck-typing feature, instead the signature of the (non-template) function =
to be called should express this as in:</div><div><br></div><div>=C2=A0 =C2=
=A0 void Fun1(MyInterface& p);</div><div>=C2=A0 =C2=A0 void Fun2(std::u=
nique_ptr<<wbr>MyInterface> p);</div><div><br></div><div>Ok, this doe=
s not work: while ownership of the p object is established by the signature=
s above the ownership of the original object is unclear. And they can't=
be the same object as the p object has to consist of the (generated) virtu=
al function table and the pointer to the original object (with some unknown=
ownership). This said, it is too weak of an idea to automatically infer un=
ique_ptr or shared_ptr as suggested earlier in this thread. A very common c=
ase will be 'no ownership', i.e. a reference to a stack object or s=
imilar, and user defined smart pointer templates. Some kind of traits class=
should be able to act as a customization point to indicate how p relates t=
o the original object.<br></div></div></blockquote><div><br></div><div><fon=
t face=3D"georgia, serif">I was thinking about the same issue before postin=
g this solution, because the "interfaces" seems to have violated =
the "single responsibility principle". Thus, the conversion is on=
ly allowed when the concrete implementations are passed "by value"=
; (as a copy), whose ownership/lifetime shall be managed within the "i=
nterface" system.</font></div><div><font face=3D"georgia, serif"><br><=
/font></div><div><font face=3D"georgia, serif">Thank you!</font></div><div>=
<font face=3D"georgia, serif"><br></font></div><div><font face=3D"georgia, =
serif">Mingxin Wang</font></div><div><br></div><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"><div><div><br><br>Den tisdag 9 maj 2017 k=
l. 08:36:20 UTC+2 skrev Mingxin Wang:<blockquote class=3D"gmail_quote" styl=
e=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr"><font face=3D"georgia, serif" size=3D"2">Dear Mr. Fromre=
ide,</font><div><font face=3D"georgia, serif" size=3D"2"><br></font></div><=
div><font size=3D"2"><font face=3D"georgia, serif">The "<b>signatures<=
/b></font><span style=3D"font-family:georgia,serif">" in G++ is a=C2=
=A0</span><font face=3D"georgia, serif"><b>syntactic sugar</b> that introdu=
ces new rules for declaring virtual member functions. The "<b>interfac=
es</b>"=C2=A0is not only a syntactic sugar, but a style of implementat=
ion for polymorphism, enabling types that meet specific requirements implic=
itly convertible to a same type at runtime.</font></font></div><div><font f=
ace=3D"georgia, serif" size=3D"2"><br></font></div><div><font size=3D"2"><f=
ont face=3D"georgia, serif">In short, we used to write virtual functions (o=
r=C2=A0</font><font face=3D"georgia, serif">"signatures</font><span st=
yle=3D"font-family:georgia,serif">"</span><font face=3D"georgia, serif=
">)=C2=A0<b>manually=C2=A0</b>to implement=C2=A0</font><span style=3D"font-=
family:georgia,serif">polymorphism, but now we can use the "interfaces=
" to <b>generate</b>=C2=A0</span></font><font face=3D"georgia, serif" =
size=3D"2">efficient</font><span style=3D"font-family:georgia,serif">=C2=A0=
</span><font face=3D"georgia, serif" style=3D"font-size:small">implementat<=
wbr>ions for=C2=A0</font><span style=3D"font-size:small;font-family:georgia=
,serif">polymorphism based on our requirements.</span></div><div><div><font=
face=3D"georgia, serif"><br></font></div><div><font face=3D"georgia, serif=
">Thank you!</font></div><div><font face=3D"georgia, serif"><br></font></di=
v><div><font face=3D"georgia, serif">Mingxin Wang</font></div><div><br>On T=
uesday, May 9, 2017 at 1:01:02 PM UTC+8, Magnus Fromreide wrote:<blockquote=
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px =
#ccc solid;padding-left:1ex">On Mon, May 08, 2017 at 08:16:23AM -0700, Nico=
l Bolas wrote:
<br>> On Monday, May 8, 2017 at 10:54:13 AM UTC-4, Thiago Macieira wrote=
:
<br>> >
<br>> > On Monday, 8 May 2017 00:30:58 PDT Mingxin Wang wrote:=20
<br>> > > Unlike the "*Concespts*" that work at compile =
time, the=20
<br>> > > "*Interfaces*" work at runtime mostly. In esse=
nce, it is not only=20
<br>> > > a syntactic sugar, but a style of implementation for *po=
lymorphism*:=20
<br>> > > virtual functions are only generated when required at ru=
ntime=20
<br>> >
<br>> > "virtual functions generated at runtime" needs A LO=
T of explanation.=20
<br>> > Please=20
<br>> > explain how the compiler would implement such a thing.=20
<br>> >
<br>> > i also recommend finding another name for your feature. "=
;interface" is a=20
<br>> > widely=20
<br>> > known term and means something else: it means a base class wi=
th virtuals=20
<br>> > that=20
<br>> > need to be overridden.
<br>> >
<br>>=20
<br>> I think the idea that he's trying to get across is the followi=
ng.
<br>>=20
<br>> An `interface` is a class which is implicitly convertible from any=
type=20
<br>> which matches some concept. The implicit conversion effectively wo=
rks by=20
<br>> storing a type-erased pointer/reference to the object it is conver=
ted from.
<br>>=20
<br>> The concept it matches is defined by the set of member functions i=
n the=20
<br>> `interface`. The `interface` class will automatically generate mat=
ching=20
<br>> member functions which forward calls to the type-erased pointer/re=
ference.
<br>>=20
<br>> So it's not a "virtual" call in the language sense; =
it's a virtual call in=20
<br>> the polymorphic sense.
<br>
<br>So, is this yet another reinvention of the old "signature" ex=
tension of G++?
<br>
<br><a href=3D"https://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC112"=
rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D'https:/=
/www.google.com/url?q\x3dhttps%3A%2F%2Fgcc.gnu.org%2Fonlinedocs%2Fgcc-2.95.=
3%2Fgcc_5.html%23SEC112\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEw4-Ehkly2R=
WPS0OVrE2Arh1XgYw';return true;" onclick=3D"this.href=3D'https://ww=
w.google.com/url?q\x3dhttps%3A%2F%2Fgcc.gnu.org%2Fonlinedocs%2Fgcc-2.95.3%2=
Fgcc_5.html%23SEC112\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEw4-Ehkly2RWPS=
0OVrE2Arh1XgYw';return true;">https://gcc.gnu.org/<wbr>onlinedocs/gcc-2=
..95.3/gcc_5.<wbr>html#SEC112</a>
<br>
<br>/MF
<br></blockquote></div></div></div></blockquote></div></div></div></blockqu=
ote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/31ce0dab-a80e-4356-a63c-a51ffb56b168%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/31ce0dab-a80e-4356-a63c-a51ffb56b168=
%40isocpp.org</a>.<br />
------=_Part_699_1711729776.1494385527496--
------=_Part_698_1686516468.1494385527495--
.
Author: Mingxin Wang <wmx16835vv@163.com>
Date: Tue, 9 May 2017 22:00:00 -0700 (PDT)
Raw View
------=_Part_5231_555693314.1494392400677
Content-Type: multipart/alternative;
boundary="----=_Part_5232_1288459797.1494392400677"
------=_Part_5232_1288459797.1494392400677
Content-Type: text/plain; charset="UTF-8"
Meanwhile, I do think your last idea is extremely valuable and instructive.
I am trying to update the solution through decoupling polymorphism
and lifetime management.
Thank you again!
Mingxin Wang
On Tuesday, May 9, 2017 at 3:17:59 PM UTC+8, Bengt Gustafsson wrote:
>
> * I think you are over-using the word "runtime" here. As I understand it
> what's happening is duck-typing: When the compiler sees that a variable of
> some type T is used where an interface I is required it checks if the T at
> hand contains all the methods specified by I. If so it generates (at
> compile time) a virtual function table suitable for I which contains
> pointers to the corresponding functions of T. In the case that the
> corresponding function is virtual and the variable is a reference it seems
> most reasonable to generate a stub function which implements a virtual call
> to the T function using the variable value as "this".
>
> * Reusing Concepts as interfaces is a appealing idea but we have already
> seen in this thread what a can of worms this opens, unfortunately. If
> anyone can disentangle this into a manageable set of rules I would be all
> for it, but the problems pointed out, that a concept can contain
> requirements for free functions, types etc, and thus the virtual pointer
> table is not enough to express the resulting polymorphism.
>
> * Maybe the keyword interface can be introduced as a contextual keyword
> for this purpose, as in:
>
> struct MyInterface interface {
> // only methods allowed
> };
>
> Maybe the methods should have to be declared virtual inside this construct
> or maybe they are virtual by default.
>
> * I don't think that the ownership/lifetime issues should be mixed with
> this duck-typing feature, instead the signature of the (non-template)
> function to be called should express this as in:
>
> void Fun1(MyInterface& p);
> void Fun2(std::unique_ptr<MyInterface> p);
>
> Ok, this does not work: while ownership of the p object is established by
> the signatures above the ownership of the original object is unclear. And
> they can't be the same object as the p object has to consist of the
> (generated) virtual function table and the pointer to the original object
> (with some unknown ownership). This said, it is too weak of an idea to
> automatically infer unique_ptr or shared_ptr as suggested earlier in this
> thread. A very common case will be 'no ownership', i.e. a reference to a
> stack object or similar, and user defined smart pointer templates. Some
> kind of traits class should be able to act as a customization point to
> indicate how p relates to the original object.
>
>
> Den tisdag 9 maj 2017 kl. 08:36:20 UTC+2 skrev Mingxin Wang:
>>
>> Dear Mr. Fromreide,
>>
>> The "*signatures*" in G++ is a *syntactic sugar* that introduces new
>> rules for declaring virtual member functions. The "*interfaces*" is not
>> only a syntactic sugar, but a style of implementation for polymorphism,
>> enabling types that meet specific requirements implicitly convertible to a
>> same type at runtime.
>>
>> In short, we used to write virtual functions (or "signatures")
>> *manually *to implement polymorphism, but now we can use the
>> "interfaces" to *generate* efficient implementations for polymorphism
>> based on our requirements.
>>
>> Thank you!
>>
>> Mingxin Wang
>>
>> On Tuesday, May 9, 2017 at 1:01:02 PM UTC+8, Magnus Fromreide wrote:
>>>
>>> On Mon, May 08, 2017 at 08:16:23AM -0700, Nicol Bolas wrote:
>>> > On Monday, May 8, 2017 at 10:54:13 AM UTC-4, Thiago Macieira wrote:
>>> > >
>>> > > On Monday, 8 May 2017 00:30:58 PDT Mingxin Wang wrote:
>>> > > > Unlike the "*Concespts*" that work at compile time, the
>>> > > > "*Interfaces*" work at runtime mostly. In essence, it is not only
>>> > > > a syntactic sugar, but a style of implementation for
>>> *polymorphism*:
>>> > > > virtual functions are only generated when required at runtime
>>> > >
>>> > > "virtual functions generated at runtime" needs A LOT of explanation.
>>> > > Please
>>> > > explain how the compiler would implement such a thing.
>>> > >
>>> > > i also recommend finding another name for your feature. "interface"
>>> is a
>>> > > widely
>>> > > known term and means something else: it means a base class with
>>> virtuals
>>> > > that
>>> > > need to be overridden.
>>> > >
>>> >
>>> > I think the idea that he's trying to get across is the following.
>>> >
>>> > An `interface` is a class which is implicitly convertible from any
>>> type
>>> > which matches some concept. The implicit conversion effectively works
>>> by
>>> > storing a type-erased pointer/reference to the object it is converted
>>> from.
>>> >
>>> > The concept it matches is defined by the set of member functions in
>>> the
>>> > `interface`. The `interface` class will automatically generate
>>> matching
>>> > member functions which forward calls to the type-erased
>>> pointer/reference.
>>> >
>>> > So it's not a "virtual" call in the language sense; it's a virtual
>>> call in
>>> > the polymorphic sense.
>>>
>>> So, is this yet another reinvention of the old "signature" extension of
>>> G++?
>>>
>>> https://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC112
>>>
>>> /MF
>>>
>>
--
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/638143af-5a25-41a8-88bd-5d10ff2c25b4%40isocpp.org.
------=_Part_5232_1288459797.1494392400677
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><font face=3D"georgia, serif">Meanwhile, I do think y=
our last idea is extremely valuable and instructive. I am trying to update =
the solution through decoupling=C2=A0polymorphism and=C2=A0lifetime managem=
ent.<br></font></div><div><font face=3D"georgia, serif"><br></font></div><d=
iv><font face=3D"georgia, serif">Thank you again!</font></div><div><font fa=
ce=3D"georgia, serif"><br></font></div><div><font face=3D"georgia, serif">M=
ingxin Wang</font><br><br>On Tuesday, May 9, 2017 at 3:17:59 PM UTC+8, Beng=
t Gustafsson wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr">* I think you are over-using the word "runtime" here. As I =
understand it what's happening is duck-typing: When the compiler sees t=
hat a variable of some type T is used where an interface I is required it c=
hecks if the T at hand contains all the methods specified by I. If so it ge=
nerates (at compile time) a virtual function table suitable for I which con=
tains pointers to the corresponding functions of T. In the case that the co=
rresponding function is virtual and the variable is a reference it seems mo=
st reasonable to generate a stub function which implements a virtual call t=
o the T function using the variable value as "this".<div><br></di=
v><div>* Reusing Concepts as interfaces is a appealing idea but we have alr=
eady seen in this thread what a can of worms this opens, unfortunately. If =
anyone can disentangle this into a manageable set of rules I would be all f=
or it, but the problems pointed out, that a concept can contain requirement=
s for free functions, types etc, and thus the virtual pointer table is not =
enough to express the resulting polymorphism.</div><div><br></div><div>* Ma=
ybe the keyword interface can be introduced as a contextual keyword for thi=
s purpose, as in:</div><div><br></div><div>=C2=A0 =C2=A0 struct MyInterface=
interface {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // only methods a=
llowed</div><div>=C2=A0 =C2=A0 };</div><div><br></div><div>Maybe the method=
s should have to be declared virtual inside this construct or maybe they ar=
e virtual by default.</div><div><br></div><div>* I don't think that the=
ownership/lifetime issues should be mixed with this duck-typing feature, i=
nstead the signature of the (non-template) function to be called should exp=
ress this as in:</div><div><br></div><div>=C2=A0 =C2=A0 void Fun1(MyInterfa=
ce& p);</div><div>=C2=A0 =C2=A0 void Fun2(std::unique_ptr<<wbr>MyInt=
erface> p);</div><div><br></div><div>Ok, this does not work: while owner=
ship of the p object is established by the signatures above the ownership o=
f the original object is unclear. And they can't be the same object as =
the p object has to consist of the (generated) virtual function table and t=
he pointer to the original object (with some unknown ownership). This said,=
it is too weak of an idea to automatically infer unique_ptr or shared_ptr =
as suggested earlier in this thread. A very common case will be 'no own=
ership', i.e. a reference to a stack object or similar, and user define=
d smart pointer templates. Some kind of traits class should be able to act =
as a customization point to indicate how p relates to the original object.<=
br><div><br><br>Den tisdag 9 maj 2017 kl. 08:36:20 UTC+2 skrev Mingxin Wang=
:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><font face=3D"geo=
rgia, serif" size=3D"2">Dear Mr. Fromreide,</font><div><font face=3D"georgi=
a, serif" size=3D"2"><br></font></div><div><font size=3D"2"><font face=3D"g=
eorgia, serif">The "<b>signatures</b></font><span style=3D"font-family=
:georgia,serif">" in G++ is a=C2=A0</span><font face=3D"georgia, serif=
"><b>syntactic sugar</b> that introduces new rules for declaring virtual me=
mber functions. The "<b>interfaces</b>"=C2=A0is not only a syntac=
tic sugar, but a style of implementation for polymorphism, enabling types t=
hat meet specific requirements implicitly convertible to a same type at run=
time.</font></font></div><div><font face=3D"georgia, serif" size=3D"2"><br>=
</font></div><div><font size=3D"2"><font face=3D"georgia, serif">In short, =
we used to write virtual functions (or=C2=A0</font><font face=3D"georgia, s=
erif">"signatures</font><span style=3D"font-family:georgia,serif">&quo=
t;</span><font face=3D"georgia, serif">)=C2=A0<b>manually=C2=A0</b>to imple=
ment=C2=A0</font><span style=3D"font-family:georgia,serif">polymorphism, bu=
t now we can use the "interfaces" to <b>generate</b>=C2=A0</span>=
</font><font face=3D"georgia, serif" size=3D"2">efficient</font><span style=
=3D"font-family:georgia,serif">=C2=A0</span><font face=3D"georgia, serif" s=
tyle=3D"font-size:small">implementat<wbr>ions for=C2=A0</font><span style=
=3D"font-size:small;font-family:georgia,serif">polymorphism based on our re=
quirements.</span></div><div><div><font face=3D"georgia, serif"><br></font>=
</div><div><font face=3D"georgia, serif">Thank you!</font></div><div><font =
face=3D"georgia, serif"><br></font></div><div><font face=3D"georgia, serif"=
>Mingxin Wang</font></div><div><br>On Tuesday, May 9, 2017 at 1:01:02 PM UT=
C+8, Magnus Fromreide wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon,=
May 08, 2017 at 08:16:23AM -0700, Nicol Bolas wrote:
<br>> On Monday, May 8, 2017 at 10:54:13 AM UTC-4, Thiago Macieira wrote=
:
<br>> >
<br>> > On Monday, 8 May 2017 00:30:58 PDT Mingxin Wang wrote:=20
<br>> > > Unlike the "*Concespts*" that work at compile =
time, the=20
<br>> > > "*Interfaces*" work at runtime mostly. In esse=
nce, it is not only=20
<br>> > > a syntactic sugar, but a style of implementation for *po=
lymorphism*:=20
<br>> > > virtual functions are only generated when required at ru=
ntime=20
<br>> >
<br>> > "virtual functions generated at runtime" needs A LO=
T of explanation.=20
<br>> > Please=20
<br>> > explain how the compiler would implement such a thing.=20
<br>> >
<br>> > i also recommend finding another name for your feature. "=
;interface" is a=20
<br>> > widely=20
<br>> > known term and means something else: it means a base class wi=
th virtuals=20
<br>> > that=20
<br>> > need to be overridden.
<br>> >
<br>>=20
<br>> I think the idea that he's trying to get across is the followi=
ng.
<br>>=20
<br>> An `interface` is a class which is implicitly convertible from any=
type=20
<br>> which matches some concept. The implicit conversion effectively wo=
rks by=20
<br>> storing a type-erased pointer/reference to the object it is conver=
ted from.
<br>>=20
<br>> The concept it matches is defined by the set of member functions i=
n the=20
<br>> `interface`. The `interface` class will automatically generate mat=
ching=20
<br>> member functions which forward calls to the type-erased pointer/re=
ference.
<br>>=20
<br>> So it's not a "virtual" call in the language sense; =
it's a virtual call in=20
<br>> the polymorphic sense.
<br>
<br>So, is this yet another reinvention of the old "signature" ex=
tension of G++?
<br>
<br><a href=3D"https://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC112"=
rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D'https:/=
/www.google.com/url?q\x3dhttps%3A%2F%2Fgcc.gnu.org%2Fonlinedocs%2Fgcc-2.95.=
3%2Fgcc_5.html%23SEC112\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEw4-Ehkly2R=
WPS0OVrE2Arh1XgYw';return true;" onclick=3D"this.href=3D'https://ww=
w.google.com/url?q\x3dhttps%3A%2F%2Fgcc.gnu.org%2Fonlinedocs%2Fgcc-2.95.3%2=
Fgcc_5.html%23SEC112\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEw4-Ehkly2RWPS=
0OVrE2Arh1XgYw';return true;">https://gcc.gnu.org/<wbr>onlinedocs/gcc-2=
..95.3/gcc_5.<wbr>html#SEC112</a>
<br>
<br>/MF
<br></blockquote></div></div></div></blockquote></div></div></div></blockqu=
ote></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/638143af-5a25-41a8-88bd-5d10ff2c25b4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/638143af-5a25-41a8-88bd-5d10ff2c25b4=
%40isocpp.org</a>.<br />
------=_Part_5232_1288459797.1494392400677--
------=_Part_5231_555693314.1494392400677--
.
Author: Jakob Riedle <jakob.riedle@gmail.com>
Date: Wed, 10 May 2017 00:25:57 -0700 (PDT)
Raw View
------=_Part_4694_615182131.1494401157979
Content-Type: multipart/alternative;
boundary="----=_Part_4695_1471380589.1494401157980"
------=_Part_4695_1471380589.1494401157980
Content-Type: text/plain; charset="UTF-8"
>
> I was thinking about the same issue before posting this solution, because
> the "interfaces" seems to have violated the "single responsibility
> principle". Thus, the conversion is only allowed when the concrete
> implementations are passed "by value" (as a copy), whose ownership/lifetime
> shall be managed within the "interface" system.
> Thank you!
Oh, that is so true, I didn't realize that before!
So what be basically want is this?
std::function<void()> f1 = /**/;
std::function<void()> f2();
const volatile std::function<void()> f3 = /**/;
Callable<void()> c1 = f1; // This copies f. Internally, an std::unique_ptr
as handle is needed.
Callable<void()>& c2 = f1; // This references f. internally, the abstract
class generatedfor Callable needs a '&' handle.
Callable<void()>&& c3 = f2(); // Internally uses '&&' as handle.
const volatile Callable<void()>& c4 = f3; //Internally 'const &' as handle.
// and so on...
At least now, Dynamic Concepts need to be a language feature, since the
reference/const/volatile specification needs to be internalized into the
implicit abstract class generation.
Cheers,
Jakob
@Minxing Wang: Could you please not cite whole posts in your answers, this
elongates the thread immensely :)
--
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/5f24e72e-6f21-4b99-84d7-053c940e66a1%40isocpp.org.
------=_Part_4695_1471380589.1494401157980
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">=
<font face=3D"georgia, serif">I was thinking about the same issue before po=
sting this solution, because the "interfaces" seems to have viola=
ted the "single responsibility principle". Thus, the conversion i=
s only allowed when the concrete implementations are passed "by value&=
quot; (as a copy), whose ownership/lifetime shall be managed within the &qu=
ot;interface" system.</font><font face=3D"georgia, serif"><br></font><=
font face=3D"georgia, serif">Thank you!</font></blockquote><div><br></div><=
div>Oh, that is so true, I didn't realize that before!</div><div><br></=
div><div>So what be basically want is this?</div><div><div class=3D"prettyp=
rint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187,=
187, 187); border-style: solid; border-width: 1px; word-wrap: break-word;"=
><code class=3D"prettyprint"><div class=3D"prettyprint" style=3D"background=
-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style:=
solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettypri=
nt"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">std</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">::</span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">function</span><span style=3D"color: #660;" 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"> f1 </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=
: #800;" 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>std</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">::</span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">function</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify"><</span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">void</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(=
)></span><span style=3D"color: #000;" class=3D"styled-by-prettify"> f2</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">();</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">const</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">volatile</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">::</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">function</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify"><</span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">void</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">()></span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> f3 </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #800;" class=3D"styled-by-prettify">/**/</span><sp=
an 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: #606;" class=3D"styled-by-prettify">Callable</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=3D"co=
lor: #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"> c1 </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> f1</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">// This=
copies f. Internally, an std::unique_ptr as handle is needed.</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Callable</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=3D"co=
lor: #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"> c2 </span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> f1</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">/=
/ This references f. internally, the abstract class generatedfor Callable n=
eeds a '&' handle.</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br></span><span style=3D"color: #606;" class=3D"styled=
-by-prettify">Callable</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify"><</span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">void</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
()>&&</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> c3 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> f2</sp=
an><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: #800;" class=3D"styled-by-prettify">// Internally uses '&=
;&' as handle.</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">const</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">volatile=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #606;" class=3D"styled-by-prettify">Callable</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">void</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">()>&</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> c4 </span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> f3</span><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: #800;" class=3D"styled-by-pret=
tify">//Internally 'const &' as handle.</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #=
800;" class=3D"styled-by-prettify">// and so on...</span></div></code></div=
></code></div><div><br></div>At least now, Dynamic Concepts need to be a la=
nguage feature, since the reference/const/volatile specification needs to b=
e internalized into the implicit abstract class generation.</div><div>=C2=
=A0</div><div>Cheers,</div><div>Jakob</div><div><br></div><div>@Minxing Wan=
g: Could you please not cite whole posts in your answers, this elongates th=
e thread immensely :)</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/5f24e72e-6f21-4b99-84d7-053c940e66a1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5f24e72e-6f21-4b99-84d7-053c940e66a1=
%40isocpp.org</a>.<br />
------=_Part_4695_1471380589.1494401157980--
------=_Part_4694_615182131.1494401157979--
.