Topic: Factory functions as deducing constructors? (N4471)
Author: David Krauss <potswa@gmail.com>
Date: Wed, 24 Jun 2015 17:44:52 +0800
Raw View
--Apple-Mail=_44A6BC3A-C329-4E6E-B722-B3EC9B0E10E1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Hi Mike,
Most libraries already implement factory function templates, e.g. make_thin=
g(). Why not just let them be named e.g. thing(), aliasing the class templa=
te?
No new deduction rules are needed.
It=E2=80=99s a non-breaking change because such aliasing is currently disal=
lowed.
It differs from established practice only by renaming.
The full flexibility of factory functions is preserved, including explicit =
template arguments.
It does not intrude into the class template implementation.
For the sake of member templates, such a function template (or function) sh=
ould still be found by a qualified-id preceded by the typename keyword. It =
should also be illegal to take its address, or to do anything with its name=
or template-id besides call it. The factory should defer to real construct=
ors when the explicit template argument list satisfies the class template p=
arameters.
Require the factory to be declared after the initial declaration of the cla=
ss template, and require its return type to be a specialization.
Implementation model: Attach the overload set of factory functions to the c=
lass template. When name lookup finds the class template, grab the factorie=
s too. If template arguments are provided, treat the class template as an o=
verload to the factories and run template argument deduction for explicit a=
rguments ([temp.deduct]/1-5). If the class template has not suffered a dedu=
ction failure, terminate deduction and restart overload resolution using it=
s constructors.
I=E2=80=99d also like to propose enforced copy elision, such that simple fa=
ctory functions don=E2=80=99t require move construction. (Call it =E2=80=9C=
perfect return.=E2=80=9D) This seems like a separate feature. However, it w=
ould be nice to have both.
Long ago, in some early C++ implementations at least, constructors were non=
-member factory functions. Hopefully this won=E2=80=99t be seen as =E2=80=
=9Ccoming full circle.=E2=80=9D It=E2=80=99s really not, since the factory =
has no special abilities or status besides sharing a name.
- D
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_44A6BC3A-C329-4E6E-B722-B3EC9B0E10E1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><div class=3D"">Hi=
Mike,</div><div class=3D""><br class=3D""></div><div class=3D"">Most libra=
ries already implement factory function templates, e.g. <font face=3D"Couri=
er" class=3D"">make_thing()</font>. Why not just let them be named e.g.&nbs=
p;<font face=3D"Courier" class=3D"">thing()</font>, aliasing the class temp=
late?</div><div class=3D""><br class=3D""></div><div class=3D""><ul class=
=3D""><li class=3D"">No new deduction rules are needed.</li><li class=3D"">=
It=E2=80=99s a non-breaking change because such aliasing is currently disal=
lowed.</li><li class=3D"">It differs from established practice only by rena=
ming.</li><li class=3D"">The full flexibility of factory functions is prese=
rved, including explicit template arguments.</li><li class=3D"">It does not=
intrude into the class template implementation.</li></ul></div><div class=
=3D""><br class=3D""></div><div class=3D"">For the sake of member templates=
, such a function template (or function) should still be found by a qualifi=
ed-id preceded by the <font face=3D"Courier" class=3D"">typename</font> key=
word. It should also be illegal to take its address, or to do anything with=
its name or template-id besides call it. The factory should defer to real =
constructors when the explicit template argument list satisfies the class t=
emplate parameters.</div><div class=3D""><br class=3D""></div><div class=3D=
"">Require the factory to be declared after the initial declaration of the =
class template, and require its return type to be a specialization.</div><d=
iv class=3D""><br class=3D""></div><div class=3D"">Implementation model: At=
tach the overload set of factory functions to the class template. When name=
lookup finds the class template, grab the factories too. If template argum=
ents are provided, treat the class template as an overload to the factories=
and run template argument deduction for explicit arguments ([temp.deduct]/=
1-5). If the class template has not suffered a deduction failure, terminate=
deduction and restart overload resolution using its constructors.</div><di=
v class=3D""><br class=3D""></div><div class=3D"">I=E2=80=99d also like to =
propose enforced copy elision, such that simple factory functions don=E2=80=
=99t require move construction. (Call it =E2=80=9Cperfect return.=E2=80=9D)=
This seems like a separate feature. However, it would be nice to have both=
..</div><div class=3D""><br class=3D""></div><div class=3D"">Long ago, in so=
me early C++ implementations at least, constructors <i class=3D"">were=
</i> non-member factory functions. Hopefully this won=E2=80=99t be see=
n as =E2=80=9Ccoming full circle.=E2=80=9D It=E2=80=99s really not, since t=
he factory has no special abilities or status besides sharing a name.</div>=
<div class=3D""><br class=3D""></div><div class=3D""><span class=3D"Apple-t=
ab-span" style=3D"white-space:pre"> </span>- D</div><div class=3D""><br cla=
ss=3D""></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_44A6BC3A-C329-4E6E-B722-B3EC9B0E10E1--
.
Author: =?UTF-8?Q?David_Rodr=C3=ADguez_Ibeas?= <dibeas@ieee.org>
Date: Wed, 24 Jun 2015 15:56:46 +0100
Raw View
--089e0158b6c041349a051944b75b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Let's see if I understand the proposal would be replacing
'make_shared<T>(arg1, arg2)' with 'shared_ptr<T>(arg1, arg2)' is it?
This could actually be a breaking change in some contexts, in particular
where there is an overlap on the arguments that the constructor and the
factories take. Consider a widget library where each widget can have an
optionally provided widget as the parent:
class Widget { ... };
class Window : public Widget { Button(Widget *parent =3D 0); ... };
Now the user that used to do:
shared_ptr<Window> parent =3D make_shared<Window>(...);
shared_ptr<Window> child =3D make_shared<Window>(parent.get());
would do:
auto parent =3D shared_ptr<Window>(...); // fine
auto child =3D shared_ptr<Window>(parent.get()); // ??
The second expression was meant to create a new object and manage by
'child', but the constructor taking a raw pointer might be picked up,
causing two different shared_ptr<Window> claim ownership of the same object
and leading to undefined behavior and a crash at the end of the day.
In general, there is no conflict between the name of the type returned from
the factory function and the name of the factory, but a choice to provide a
different name. For example, 'make_shared<T>' and 'make_unique<T>' would
very well be 'shared<T>' and 'unique<T>', no conflict but those are less
clear than the current name.
David
On Wed, Jun 24, 2015 at 10:44 AM, David Krauss <potswa@gmail.com> wrote:
> Hi Mike,
>
> Most libraries already implement factory function templates, e.g.
> make_thing(). Why not just let them be named e.g. thing(), aliasing the
> class template?
>
>
> - No new deduction rules are needed.
> - It=E2=80=99s a non-breaking change because such aliasing is currentl=
y
> disallowed.
> - It differs from established practice only by renaming.
> - The full flexibility of factory functions is preserved, including
> explicit template arguments.
> - It does not intrude into the class template implementation.
>
>
> For the sake of member templates, such a function template (or function)
> should still be found by a qualified-id preceded by the typename keyword.
> It should also be illegal to take its address, or to do anything with its
> name or template-id besides call it. The factory should defer to real
> constructors when the explicit template argument list satisfies the class
> template parameters.
>
> Require the factory to be declared after the initial declaration of the
> class template, and require its return type to be a specialization.
>
> Implementation model: Attach the overload set of factory functions to the
> class template. When name lookup finds the class template, grab the
> factories too. If template arguments are provided, treat the class templa=
te
> as an overload to the factories and run template argument deduction for
> explicit arguments ([temp.deduct]/1-5). If the class template has not
> suffered a deduction failure, terminate deduction and restart overload
> resolution using its constructors.
>
> I=E2=80=99d also like to propose enforced copy elision, such that simple =
factory
> functions don=E2=80=99t require move construction. (Call it =E2=80=9Cperf=
ect return.=E2=80=9D) This
> seems like a separate feature. However, it would be nice to have both.
>
> Long ago, in some early C++ implementations at least, constructors *were*=
non-member
> factory functions. Hopefully this won=E2=80=99t be seen as =E2=80=9Ccomin=
g full circle.=E2=80=9D
> It=E2=80=99s really not, since the factory has no special abilities or st=
atus
> besides sharing a name.
>
> - D
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--089e0158b6c041349a051944b75b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Let's see if I understand the proposal would be replac=
ing 'make_shared<T>(arg1, arg2)' with 'shared_ptr<T>=
;(arg1, arg2)' is it?<br><br>This could actually be a breaking change i=
n some contexts, in particular where there is an overlap on the arguments t=
hat the constructor and the factories take. Consider a widget library where=
each widget can have an optionally provided widget as the parent:<br><br>c=
lass Widget { ... };<br>class Window : public Widget { Button(Widget *paren=
t =3D 0); ... };<br><br>Now the user that used to do:<br><br>shared_ptr<=
Window> parent =3D make_shared<Window>(...);<br>shared_ptr<Wind=
ow> child =3D make_shared<Window>(parent.get());<br><br>would do:<=
br><br>auto parent =3D shared_ptr<Window>(...); =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0// fine<br>auto child =3D shared_ptr<Window>(pare=
nt.get()); // ??<br><br>The second expression was meant to create a new obj=
ect and manage by 'child', but the constructor taking a raw pointer=
might be picked up, causing two different shared_ptr<Window> claim o=
wnership of the same object and leading to undefined behavior and a crash a=
t the end of the day.<br><br>In general, there is no conflict between the n=
ame of the type returned from the factory function and the name of the fact=
ory, but a choice to provide a different name. For example, 'make_share=
d<T>' and 'make_unique<T>' would very well be '=
shared<T>' and 'unique<T>', no conflict but those a=
re less clear than the current name.<div><br>=C2=A0 =C2=A0 David</div></div=
><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Jun 24, =
2015 at 10:44 AM, David Krauss <span dir=3D"ltr"><<a href=3D"mailto:pots=
wa@gmail.com" target=3D"_blank">potswa@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 style=3D"word-wrap:break-word"><div>Hi M=
ike,</div><div><br></div><div>Most libraries already implement factory func=
tion templates, e.g. <font face=3D"Courier">make_thing()</font>. Why not ju=
st let them be named e.g.=C2=A0<font face=3D"Courier">thing()</font>, alias=
ing the class template?</div><div><br></div><div><ul><li>No new deduction r=
ules are needed.</li><li>It=E2=80=99s a non-breaking change because such al=
iasing is currently disallowed.</li><li>It differs from established practic=
e only by renaming.</li><li>The full flexibility of factory functions is pr=
eserved, including explicit template arguments.</li><li>It does not intrude=
into the class template implementation.</li></ul></div><div><br></div><div=
>For the sake of member templates, such a function template (or function) s=
hould still be found by a qualified-id preceded by the <font face=3D"Courie=
r">typename</font> keyword. It should also be illegal to take its address, =
or to do anything with its name or template-id besides call it. The factory=
should defer to real constructors when the explicit template argument list=
satisfies the class template parameters.</div><div><br></div><div>Require =
the factory to be declared after the initial declaration of the class templ=
ate, and require its return type to be a specialization.</div><div><br></di=
v><div>Implementation model: Attach the overload set of factory functions t=
o the class template. When name lookup finds the class template, grab the f=
actories too. If template arguments are provided, treat the class template =
as an overload to the factories and run template argument deduction for exp=
licit arguments ([temp.deduct]/1-5). If the class template has not suffered=
a deduction failure, terminate deduction and restart overload resolution u=
sing its constructors.</div><div><br></div><div>I=E2=80=99d also like to pr=
opose enforced copy elision, such that simple factory functions don=E2=80=
=99t require move construction. (Call it =E2=80=9Cperfect return.=E2=80=9D)=
This seems like a separate feature. However, it would be nice to have both=
..</div><div><br></div><div>Long ago, in some early C++ implementations at l=
east, constructors=C2=A0<i>were</i>=C2=A0non-member factory functions. Hope=
fully this won=E2=80=99t be seen as =E2=80=9Ccoming full circle.=E2=80=9D I=
t=E2=80=99s really not, since the factory has no special abilities or statu=
s besides sharing a name.</div><span class=3D"HOEnZb"><font color=3D"#88888=
8"><div><br></div><div><span style=3D"white-space:pre-wrap"> </span>- D</di=
v><div><br></div></font></span></div><span class=3D"HOEnZb"><font color=3D"=
#888888">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e0158b6c041349a051944b75b--
.
Author: Michael Spertus <mike_spertus@symantec.com>
Date: Wed, 24 Jun 2015 14:55:09 -0700
Raw View
--_000_9A3E0561DCF227429F72080EA81ADBC96077F5170FTUS1XCHEVSPIN_
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi David,
That sounds to me essentially like the factory functions part of the propos=
al except you allow bodies in them. Is that correct? We explicitly rejected=
that because I felt that the body belonged in the class and was consistent=
with C++=E2=80=99 traditional values about what should be in the class def=
inition (Although I can=E2=80=99t speak for Richard=E2=80=99s motivation, h=
e also explicitly forbid defining the body). A point in favor of your appr=
oach is that Bjarne=E2=80=99s unified function call syntax proposal is to s=
upport =E2=80=9Cexternally defined methods=E2=80=9D but doesn=E2=80=99t wor=
k for constructors.
I plan to start looking at the next revision in about a month. OK if we dis=
cuss then?
Thanks,
Mike
From: David Krauss [mailto:potswa@gmail.com]
Sent: Wednesday, June 24, 2015 4:45 AM
To: Michael Spertus; std-proposals@isocpp.org
Cc: Richard Smith
Subject: Factory functions as deducing constructors? (N4471)
Hi Mike,
Most libraries already implement factory function templates, e.g. make_thin=
g(). Why not just let them be named e.g. thing(), aliasing the class templa=
te?
* No new deduction rules are needed.
* It=E2=80=99s a non-breaking change because such aliasing is currently =
disallowed.
* It differs from established practice only by renaming.
* The full flexibility of factory functions is preserved, including expl=
icit template arguments.
* It does not intrude into the class template implementation.
For the sake of member templates, such a function template (or function) sh=
ould still be found by a qualified-id preceded by the typename keyword. It =
should also be illegal to take its address, or to do anything with its name=
or template-id besides call it. The factory should defer to real construct=
ors when the explicit template argument list satisfies the class template p=
arameters.
Require the factory to be declared after the initial declaration of the cla=
ss template, and require its return type to be a specialization.
Implementation model: Attach the overload set of factory functions to the c=
lass template. When name lookup finds the class template, grab the factorie=
s too. If template arguments are provided, treat the class template as an o=
verload to the factories and run template argument deduction for explicit a=
rguments ([temp.deduct]/1-5). If the class template has not suffered a dedu=
ction failure, terminate deduction and restart overload resolution using it=
s constructors.
I=E2=80=99d also like to propose enforced copy elision, such that simple fa=
ctory functions don=E2=80=99t require move construction. (Call it =E2=80=9C=
perfect return.=E2=80=9D) This seems like a separate feature. However, it w=
ould be nice to have both.
Long ago, in some early C++ implementations at least, constructors were non=
-member factory functions. Hopefully this won=E2=80=99t be seen as =E2=80=
=9Ccoming full circle.=E2=80=9D It=E2=80=99s really not, since the factory =
has no special abilities or status besides sharing a name.
- D
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--_000_9A3E0561DCF227429F72080EA81ADBC96077F5170FTUS1XCHEVSPIN_
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-Type content=
=3D"text/html; charset=3Dutf-8"><meta name=3DGenerator content=3D"Microsoft=
Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Courier;
panose-1:2 7 4 9 2 2 5 2 4 4;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
span.apple-tab-span
{mso-style-name:apple-tab-span;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle19
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
..MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:360207807;
mso-list-template-ids:-1544795998;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:=EF=82=B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:=EF=82=A7;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:=EF=82=A7;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:=EF=82=A7;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:=EF=82=A7;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:=EF=82=A7;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:=EF=82=A7;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:=EF=82=A7;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3D"#0563C1=
" vlink=3D"#954F72"><div class=3DWordSection1><p class=3DMsoNormal><span st=
yle=3D'font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Hi =
David,<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:1=
1.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>That sounds to me ess=
entially like the factory functions part of the proposal except you allow b=
odies in them. Is that correct? We explicitly rejected that because I felt =
that the body belonged in the class and was consistent with C++=E2=80=99 tr=
aditional values about what should be in the class definition (Although I c=
an=E2=80=99t speak for Richard=E2=80=99s motivation, he also explicitly for=
bid defining the body). =C2=A0A point in favor of your approach is that Bja=
rne=E2=80=99s unified function call syntax proposal is to support =E2=80=9C=
externally defined methods=E2=80=9D but doesn=E2=80=99t work for constructo=
rs.<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0=
pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span>=
</p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calib=
ri",sans-serif;color:#1F497D'>I plan to start looking at the next revision =
in about a month. OK if we discuss then?<o:p></o:p></span></p><p class=3DMs=
oNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif;co=
lor:#1F497D'><o:p> </o:p></span></p><p class=3DMsoNormal><span style=
=3D'font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Thanks=
,<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt=
;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></=
p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri=
",sans-serif;color:#1F497D'>Mike<o:p></o:p></span></p><p class=3DMsoNormal>=
<span style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4=
97D'><o:p> </o:p></span></p><div><div style=3D'border:none;border-top:=
solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=3DMsoNormal><b><spa=
n style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif'>From:</span><=
/b><span style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif'> David=
Krauss [mailto:potswa@gmail.com] <br><b>Sent:</b> Wednesday, June 24, 2015=
4:45 AM<br><b>To:</b> Michael Spertus; std-proposals@isocpp.org<br><b>Cc:<=
/b> Richard Smith<br><b>Subject:</b> Factory functions as deducing construc=
tors? (N4471)<o:p></o:p></span></p></div></div><p class=3DMsoNormal><o:p>&n=
bsp;</o:p></p><div><p class=3DMsoNormal>Hi Mike,<o:p></o:p></p></div><div><=
p class=3DMsoNormal><o:p> </o:p></p></div><div><p class=3DMsoNormal>Mo=
st libraries already implement factory function templates, e.g. <span style=
=3D'font-family:Courier'>make_thing()</span>. Why not just let them be name=
d e.g. <span style=3D'font-family:Courier'>thing()</span>, aliasing th=
e class template?<o:p></o:p></p></div><div><p class=3DMsoNormal><o:p> =
</o:p></p></div><div><ul type=3Ddisc><li class=3DMsoNormal style=3D'mso-mar=
gin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1'>No new=
deduction rules are needed.<o:p></o:p></li><li class=3DMsoNormal style=3D'=
mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1'=
>It=E2=80=99s a non-breaking change because such aliasing is currently disa=
llowed.<o:p></o:p></li><li class=3DMsoNormal style=3D'mso-margin-top-alt:au=
to;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1'>It differs from esta=
blished practice only by renaming.<o:p></o:p></li><li class=3DMsoNormal sty=
le=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1=
lfo1'>The full flexibility of factory functions is preserved, including ex=
plicit template arguments.<o:p></o:p></li><li class=3DMsoNormal style=3D'ms=
o-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1'>I=
t does not intrude into the class template implementation.<o:p></o:p></li><=
/ul></div><div><p class=3DMsoNormal><o:p> </o:p></p></div><div><p clas=
s=3DMsoNormal>For the sake of member templates, such a function template (o=
r function) should still be found by a qualified-id preceded by the <span s=
tyle=3D'font-family:Courier'>typename</span> keyword. It should also be ill=
egal to take its address, or to do anything with its name or template-id be=
sides call it. The factory should defer to real constructors when the expli=
cit template argument list satisfies the class template parameters.<o:p></o=
:p></p></div><div><p class=3DMsoNormal><o:p> </o:p></p></div><div><p c=
lass=3DMsoNormal>Require the factory to be declared after the initial decla=
ration of the class template, and require its return type to be a specializ=
ation.<o:p></o:p></p></div><div><p class=3DMsoNormal><o:p> </o:p></p><=
/div><div><p class=3DMsoNormal>Implementation model: Attach the overload se=
t of factory functions to the class template. When name lookup finds the cl=
ass template, grab the factories too. If template arguments are provided, t=
reat the class template as an overload to the factories and run template ar=
gument deduction for explicit arguments ([temp.deduct]/1-5). If the class t=
emplate has not suffered a deduction failure, terminate deduction and resta=
rt overload resolution using its constructors.<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p> </o:p></p></div><div><p class=3DMsoNormal>I=E2=
=80=99d also like to propose enforced copy elision, such that simple factor=
y functions don=E2=80=99t require move construction. (Call it =E2=80=9Cperf=
ect return.=E2=80=9D) This seems like a separate feature. However, it would=
be nice to have both.<o:p></o:p></p></div><div><p class=3DMsoNormal><o:p>&=
nbsp;</o:p></p></div><div><p class=3DMsoNormal>Long ago, in some early C++ =
implementations at least, constructors <i>were</i> non-member fac=
tory functions. Hopefully this won=E2=80=99t be seen as =E2=80=9Ccoming ful=
l circle.=E2=80=9D It=E2=80=99s really not, since the factory has no specia=
l abilities or status besides sharing a name.<o:p></o:p></p></div><div><p c=
lass=3DMsoNormal><o:p> </o:p></p></div><div><p class=3DMsoNormal><span=
class=3Dapple-tab-span>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 </span>- D<o:p></o:p></p></div><div><p class=3DMsoNormal><o=
:p> </o:p></p></div></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--_000_9A3E0561DCF227429F72080EA81ADBC96077F5170FTUS1XCHEVSPIN_--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Wed, 24 Jun 2015 16:59:06 -0700
Raw View
--bcaec5489e45cbcbb305194c4a26
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wed, Jun 24, 2015 at 2:55 PM, Michael Spertus <mike_spertus@symantec.com=
>
wrote:
> Hi David,
>
> That sounds to me essentially like the factory functions part of the
> proposal except you allow bodies in them. Is that correct? We explicitly
> rejected that because I felt that the body belonged in the class and was
> consistent with C++=E2=80=99 traditional values about what should be in t=
he class
> definition (Although I can=E2=80=99t speak for Richard=E2=80=99s motivati=
on, he also
> explicitly forbid defining the body).
>
I arrived at the current "guiding declarations" approach as a special case
of a more general mechanism. Sometimes you want a function template that
has some non-trivial way of computing its desired parameter types from the
types of its arguments. This can't be done in today's C++: if you capture
your argument types through deduction, your parameter types must exactly
match the argument types. So the feature I was considering would allow this=
:
template<typename ...Args> void f_impl(maybe_add_ref<Args>...);
template<typename ...Args> some_keyword_maybe f(Args...) ->
f_impl<Args...>;
The second declaration is a deduction guide: it says, when you see a call
f(blah), and that function is the best viable function, then proceed as if
f were replaced by f_impl<Args...>. And for constructors:
template<typename T> some_keyword_maybe vector(initializer_list<T>) ->
vector<T>;
.... says essentially the same thing: when you see vector{1, 2, 3}, if that
declaration is the best viable function (say, with T =3D int), then 'vector=
'
really means 'vector<int>'.
One reason why you would want something like this instead of giving a
definition to the constructor (or function template) is to avoid
duplication -- you already have the constructor definition, and shouldn't
be repeating it in the way the old make_-function pattern forced you to.
Another reason is to avoid unnecessary copies / moves of function arguments=
..
> A point in favor of your approach is that Bjarne=E2=80=99s unified funct=
ion call
> syntax proposal is to support =E2=80=9Cexternally defined methods=E2=80=
=9D but doesn=E2=80=99t work
> for constructors.
>
>
>
> I plan to start looking at the next revision in about a month. OK if we
> discuss then?
>
>
>
> Thanks,
>
>
>
> Mike
>
>
>
> *From:* David Krauss [mailto:potswa@gmail.com]
> *Sent:* Wednesday, June 24, 2015 4:45 AM
> *To:* Michael Spertus; std-proposals@isocpp.org
> *Cc:* Richard Smith
> *Subject:* Factory functions as deducing constructors? (N4471)
>
>
>
> Hi Mike,
>
>
>
> Most libraries already implement factory function templates, e.g.
> make_thing(). Why not just let them be named e.g. thing(), aliasing the
> class template?
>
>
>
> - No new deduction rules are needed.
> - It=E2=80=99s a non-breaking change because such aliasing is currentl=
y
> disallowed.
> - It differs from established practice only by renaming.
> - The full flexibility of factory functions is preserved, including
> explicit template arguments.
> - It does not intrude into the class template implementation.
>
>
>
> For the sake of member templates, such a function template (or function)
> should still be found by a qualified-id preceded by the typename keyword.
> It should also be illegal to take its address, or to do anything with its
> name or template-id besides call it. The factory should defer to real
> constructors when the explicit template argument list satisfies the class
> template parameters.
>
>
>
> Require the factory to be declared after the initial declaration of the
> class template, and require its return type to be a specialization.
>
>
>
> Implementation model: Attach the overload set of factory functions to the
> class template. When name lookup finds the class template, grab the
> factories too. If template arguments are provided, treat the class templa=
te
> as an overload to the factories and run template argument deduction for
> explicit arguments ([temp.deduct]/1-5). If the class template has not
> suffered a deduction failure, terminate deduction and restart overload
> resolution using its constructors.
>
>
>
> I=E2=80=99d also like to propose enforced copy elision, such that simple =
factory
> functions don=E2=80=99t require move construction. (Call it =E2=80=9Cperf=
ect return.=E2=80=9D) This
> seems like a separate feature. However, it would be nice to have both.
>
>
>
> Long ago, in some early C++ implementations at least, constructors *were*=
non-member
> factory functions. Hopefully this won=E2=80=99t be seen as =E2=80=9Ccomin=
g full circle.=E2=80=9D
> It=E2=80=99s really not, since the factory has no special abilities or st=
atus
> besides sharing a name.
>
>
>
> - D
>
>
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--bcaec5489e45cbcbb305194c4a26
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Jun 24, 2015 at 2:55 PM, Michael Spertus <span dir=3D"ltr"><<a href=
=3D"mailto:mike_spertus@symantec.com" target=3D"_blank">mike_spertus@symant=
ec.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 lang=3D=
"EN-US" link=3D"#0563C1" vlink=3D"#954F72"><div><p class=3D"MsoNormal"><spa=
n style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif;colo=
r:#1f497d">Hi David,<u></u><u></u></span></p><p class=3D"MsoNormal"><span s=
tyle=3D"font-size:11.0pt;font-family:"Calibri",sans-serif;color:#=
1f497d">That sounds to me essentially like the factory functions part of th=
e proposal except you allow bodies in them. Is that correct? We explicitly =
rejected that because I felt that the body belonged in the class and was co=
nsistent with C++=E2=80=99 traditional values about what should be in the c=
lass definition (Although I can=E2=80=99t speak for Richard=E2=80=99s motiv=
ation, he also explicitly forbid defining the body).</span></p></div></div>=
</blockquote><div><br></div><div>I arrived at the current "guiding dec=
larations" approach as a special case of a more general mechanism. Som=
etimes you want a function template that has some non-trivial way of comput=
ing its desired parameter types from the types of its arguments. This can&#=
39;t be done in today's C++: if you capture your argument types through=
deduction, your parameter types must exactly match the argument types. So =
the feature I was considering would allow this:</div><div><br></div><div>=
=C2=A0 template<typename ...Args> void f_impl(maybe_add_ref<Args&g=
t;...);</div><div>=C2=A0 template<typename ...Args> some_keyword_mayb=
e f(Args...) -> f_impl<Args...>;</div><div><br></div><div>The seco=
nd declaration is a deduction guide: it says, when you see a call f(blah), =
and that function is the best viable function, then proceed as if f were re=
placed by f_impl<Args...>. And for constructors:</div><div><br></div>=
<div>=C2=A0 template<typename T> some_keyword_maybe vector(initialize=
r_list<T>) -> vector<T>;</div><div><br></div><div>... says e=
ssentially the same thing: when you see vector{1, 2, 3}, if that declaratio=
n is the best viable function (say, with T =3D int), then 'vector' =
really means 'vector<int>'.</div><div><br></div><div>One reas=
on why you would want something like this instead of giving a definition to=
the constructor (or function template) is to avoid duplication -- you alre=
ady have the constructor definition, and shouldn't be repeating it in t=
he way the old make_-function pattern forced you to. Another reason is to a=
void unnecessary copies / moves of function arguments.</div><div>=C2=A0</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div lang=3D"EN-US" link=3D"#0563C1" vlink=
=3D"#954F72"><div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;fo=
nt-family:"Calibri",sans-serif;color:#1f497d"> =C2=A0A point in f=
avor of your approach is that Bjarne=E2=80=99s unified function call syntax=
proposal is to support =E2=80=9Cexternally defined methods=E2=80=9D but do=
esn=E2=80=99t work for constructors.<u></u><u></u></span></p><p class=3D"Ms=
oNormal"><span style=3D"font-size:11.0pt;font-family:"Calibri",sa=
ns-serif;color:#1f497d"><u></u>=C2=A0<u></u></span></p><p class=3D"MsoNorma=
l"><span style=3D"font-size:11.0pt;font-family:"Calibri",sans-ser=
if;color:#1f497d">I plan to start looking at the next revision in about a m=
onth. OK if we discuss then?<u></u><u></u></span></p><p class=3D"MsoNormal"=
><span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif=
;color:#1f497d"><u></u>=C2=A0<u></u></span></p><p class=3D"MsoNormal"><span=
style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif;color=
:#1f497d">Thanks,<u></u><u></u></span></p><p class=3D"MsoNormal"><span styl=
e=3D"font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f4=
97d"><u></u>=C2=A0<u></u></span></p><p class=3D"MsoNormal"><span style=3D"f=
ont-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">M=
ike<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size=
:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u>=
=C2=A0<u></u></span></p><div><div style=3D"border:none;border-top:solid #e1=
e1e1 1.0pt;padding:3.0pt 0in 0in 0in"><p class=3D"MsoNormal"><b><span style=
=3D"font-size:11.0pt;font-family:"Calibri",sans-serif">From:</spa=
n></b><span style=3D"font-size:11.0pt;font-family:"Calibri",sans-=
serif"> David Krauss [mailto:<a href=3D"mailto:potswa@gmail.com" target=3D"=
_blank">potswa@gmail.com</a>] <br><b>Sent:</b> Wednesday, June 24, 2015 4:4=
5 AM<br><b>To:</b> Michael Spertus; <a href=3D"mailto:std-proposals@isocpp.=
org" target=3D"_blank">std-proposals@isocpp.org</a><br><b>Cc:</b> Richard S=
mith<br><b>Subject:</b> Factory functions as deducing constructors? (N4471)=
<u></u><u></u></span></p></div></div><div><div class=3D"h5"><p class=3D"Mso=
Normal"><u></u>=C2=A0<u></u></p><div><p class=3D"MsoNormal">Hi Mike,<u></u>=
<u></u></p></div><div><p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p></div>=
<div><p class=3D"MsoNormal">Most libraries already implement factory functi=
on templates, e.g. <span style=3D"font-family:Courier">make_thing()</span>.=
Why not just let them be named e.g.=C2=A0<span style=3D"font-family:Courie=
r">thing()</span>, aliasing the class template?<u></u><u></u></p></div><div=
><p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p></div><div><ul type=3D"disc=
"><li class=3D"MsoNormal">No new deduction rules are needed.<u></u><u></u><=
/li><li class=3D"MsoNormal">It=E2=80=99s a non-breaking change because such=
aliasing is currently disallowed.<u></u><u></u></li><li class=3D"MsoNormal=
">It differs from established practice only by renaming.<u></u><u></u></li>=
<li class=3D"MsoNormal">The full flexibility of factory functions is preser=
ved, including explicit template arguments.<u></u><u></u></li><li class=3D"=
MsoNormal">It does not intrude into the class template implementation.<u></=
u><u></u></li></ul></div><div><p class=3D"MsoNormal"><u></u>=C2=A0<u></u></=
p></div><div><p class=3D"MsoNormal">For the sake of member templates, such =
a function template (or function) should still be found by a qualified-id p=
receded by the <span style=3D"font-family:Courier">typename</span> keyword.=
It should also be illegal to take its address, or to do anything with its =
name or template-id besides call it. The factory should defer to real const=
ructors when the explicit template argument list satisfies the class templa=
te parameters.<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=
=C2=A0<u></u></p></div><div><p class=3D"MsoNormal">Require the factory to b=
e declared after the initial declaration of the class template, and require=
its return type to be a specialization.<u></u><u></u></p></div><div><p cla=
ss=3D"MsoNormal"><u></u>=C2=A0<u></u></p></div><div><p class=3D"MsoNormal">=
Implementation model: Attach the overload set of factory functions to the c=
lass template. When name lookup finds the class template, grab the factorie=
s too. If template arguments are provided, treat the class template as an o=
verload to the factories and run template argument deduction for explicit a=
rguments ([temp.deduct]/1-5). If the class template has not suffered a dedu=
ction failure, terminate deduction and restart overload resolution using it=
s constructors.<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=
=C2=A0<u></u></p></div><div><p class=3D"MsoNormal">I=E2=80=99d also like to=
propose enforced copy elision, such that simple factory functions don=E2=
=80=99t require move construction. (Call it =E2=80=9Cperfect return.=E2=80=
=9D) This seems like a separate feature. However, it would be nice to have =
both.<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=C2=A0<u></=
u></p></div><div><p class=3D"MsoNormal">Long ago, in some early C++ impleme=
ntations at least, constructors=C2=A0<i>were</i>=C2=A0non-member factory fu=
nctions. Hopefully this won=E2=80=99t be seen as =E2=80=9Ccoming full circl=
e.=E2=80=9D It=E2=80=99s really not, since the factory has no special abili=
ties or status besides sharing a name.<u></u><u></u></p></div><div><p class=
=3D"MsoNormal"><u></u>=C2=A0<u></u></p></div><div><p class=3D"MsoNormal"><s=
pan>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </sp=
an>- D<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=C2=A0<u><=
/u></p></div></div></div></div></div></blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--bcaec5489e45cbcbb305194c4a26--
.
Author: Michael Spertus <mike_spertus@symantec.com>
Date: Wed, 24 Jun 2015 17:47:45 -0700
Raw View
--_000_9A3E0561DCF227429F72080EA81ADBC96077F517E6TUS1XCHEVSPIN_
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
It=E2=80=99s worth mentioning that since I regard the template deduction fo=
r existing constructors in the primary template as by far the most importan=
t part of the proposal (Indeed, I would strongly favor the proposal even wi=
thout any kind of factory functions), I lean towards a solution that looked=
as much like existing constructors as possible. I am open to the possibili=
ty that this implication (although not its premise) is fallacious reasoning=
on my part.
From: metafoo@gmail.com [mailto:metafoo@gmail.com] On Behalf Of Richard Smi=
th
Sent: Wednesday, June 24, 2015 6:59 PM
To: Michael Spertus
Cc: David Krauss; std-proposals@isocpp.org
Subject: Re: Factory functions as deducing constructors? (N4471)
On Wed, Jun 24, 2015 at 2:55 PM, Michael Spertus <mike_spertus@symantec.com=
<mailto:mike_spertus@symantec.com>> wrote:
Hi David,
That sounds to me essentially like the factory functions part of the propos=
al except you allow bodies in them. Is that correct? We explicitly rejected=
that because I felt that the body belonged in the class and was consistent=
with C++=E2=80=99 traditional values about what should be in the class def=
inition (Although I can=E2=80=99t speak for Richard=E2=80=99s motivation, h=
e also explicitly forbid defining the body).
I arrived at the current "guiding declarations" approach as a special case =
of a more general mechanism. Sometimes you want a function template that ha=
s some non-trivial way of computing its desired parameter types from the ty=
pes of its arguments. This can't be done in today's C++: if you capture you=
r argument types through deduction, your parameter types must exactly match=
the argument types. So the feature I was considering would allow this:
template<typename ...Args> void f_impl(maybe_add_ref<Args>...);
template<typename ...Args> some_keyword_maybe f(Args...) -> f_impl<Args..=
..>;
The second declaration is a deduction guide: it says, when you see a call f=
(blah), and that function is the best viable function, then proceed as if f=
were replaced by f_impl<Args...>. And for constructors:
template<typename T> some_keyword_maybe vector(initializer_list<T>) -> ve=
ctor<T>;
.... says essentially the same thing: when you see vector{1, 2, 3}, if that =
declaration is the best viable function (say, with T =3D int), then 'vector=
' really means 'vector<int>'.
One reason why you would want something like this instead of giving a defin=
ition to the constructor (or function template) is to avoid duplication -- =
you already have the constructor definition, and shouldn't be repeating it =
in the way the old make_-function pattern forced you to. Another reason is =
to avoid unnecessary copies / moves of function arguments.
A point in favor of your approach is that Bjarne=E2=80=99s unified functio=
n call syntax proposal is to support =E2=80=9Cexternally defined methods=E2=
=80=9D but doesn=E2=80=99t work for constructors.
I plan to start looking at the next revision in about a month. OK if we dis=
cuss then?
Thanks,
Mike
From: David Krauss [mailto:potswa@gmail.com<mailto:potswa@gmail.com>]
Sent: Wednesday, June 24, 2015 4:45 AM
To: Michael Spertus; std-proposals@isocpp.org<mailto:std-proposals@isocpp.o=
rg>
Cc: Richard Smith
Subject: Factory functions as deducing constructors? (N4471)
Hi Mike,
Most libraries already implement factory function templates, e.g. make_thin=
g(). Why not just let them be named e.g. thing(), aliasing the class templa=
te?
* No new deduction rules are needed.
* It=E2=80=99s a non-breaking change because such aliasing is currently =
disallowed.
* It differs from established practice only by renaming.
* The full flexibility of factory functions is preserved, including expl=
icit template arguments.
* It does not intrude into the class template implementation.
For the sake of member templates, such a function template (or function) sh=
ould still be found by a qualified-id preceded by the typename keyword. It =
should also be illegal to take its address, or to do anything with its name=
or template-id besides call it. The factory should defer to real construct=
ors when the explicit template argument list satisfies the class template p=
arameters.
Require the factory to be declared after the initial declaration of the cla=
ss template, and require its return type to be a specialization.
Implementation model: Attach the overload set of factory functions to the c=
lass template. When name lookup finds the class template, grab the factorie=
s too. If template arguments are provided, treat the class template as an o=
verload to the factories and run template argument deduction for explicit a=
rguments ([temp.deduct]/1-5). If the class template has not suffered a dedu=
ction failure, terminate deduction and restart overload resolution using it=
s constructors.
I=E2=80=99d also like to propose enforced copy elision, such that simple fa=
ctory functions don=E2=80=99t require move construction. (Call it =E2=80=9C=
perfect return.=E2=80=9D) This seems like a separate feature. However, it w=
ould be nice to have both.
Long ago, in some early C++ implementations at least, constructors were non=
-member factory functions. Hopefully this won=E2=80=99t be seen as =E2=80=
=9Ccoming full circle.=E2=80=9D It=E2=80=99s really not, since the factory =
has no special abilities or status besides sharing a name.
- D
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--_000_9A3E0561DCF227429F72080EA81ADBC96077F517E6TUS1XCHEVSPIN_
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-Type content=
=3D"text/html; charset=3Dutf-8"><meta name=3DGenerator content=3D"Microsoft=
Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Courier;
panose-1:2 7 4 9 2 2 5 2 4 4;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
..MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1450857017;
mso-list-template-ids:1230961700;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:=EF=82=B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:=EF=82=B7;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:=EF=82=B7;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:=EF=82=B7;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:=EF=82=B7;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:=EF=82=B7;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:=EF=82=B7;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:=EF=82=B7;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:=EF=82=B7;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli=
nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span style=3D'f=
ont-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>It=E2=80=99=
s worth mentioning that since I regard the template deduction for existing =
constructors in the primary template as by far the most important part of t=
he proposal (Indeed, I would strongly favor the proposal even without any k=
ind of factory functions), I lean towards a solution that looked as much li=
ke existing constructors as possible. I am open to the possibility that thi=
s implication (although not its premise) is fallacious reasoning on my part=
..<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt=
;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></=
p><p class=3DMsoNormal><b><span style=3D'font-size:11.0pt;font-family:"Cali=
bri",sans-serif'>From:</span></b><span style=3D'font-size:11.0pt;font-famil=
y:"Calibri",sans-serif'> metafoo@gmail.com [mailto:metafoo@gmail.com] <b>On=
Behalf Of </b>Richard Smith<br><b>Sent:</b> Wednesday, June 24, 2015 6:59 =
PM<br><b>To:</b> Michael Spertus<br><b>Cc:</b> David Krauss; std-proposals@=
isocpp.org<br><b>Subject:</b> Re: Factory functions as deducing constructor=
s? (N4471)<o:p></o:p></span></p><p class=3DMsoNormal><o:p> </o:p></p><=
div><div><div><p class=3DMsoNormal>On Wed, Jun 24, 2015 at 2:55 PM, Michael=
Spertus <<a href=3D"mailto:mike_spertus@symantec.com" target=3D"_blank"=
>mike_spertus@symantec.com</a>> wrote:<o:p></o:p></p><blockquote style=
=3D'border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;m=
argin-left:4.8pt;margin-right:0in'><div><div><p class=3DMsoNormal style=3D'=
mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style=3D'font-siz=
e:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Hi David,</span><o=
:p></o:p></p><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-marg=
in-bottom-alt:auto'><span style=3D'font-size:11.0pt;font-family:"Calibri",s=
ans-serif;color:#1F497D'>That sounds to me essentially like the factory fun=
ctions part of the proposal except you allow bodies in them. Is that correc=
t? We explicitly rejected that because I felt that the body belonged in the=
class and was consistent with C++=E2=80=99 traditional values about what s=
hould be in the class definition (Although I can=E2=80=99t speak for Richar=
d=E2=80=99s motivation, he also explicitly forbid defining the body).</span=
><o:p></o:p></p></div></div></blockquote><div><p class=3DMsoNormal><o:p>&nb=
sp;</o:p></p></div><div><p class=3DMsoNormal>I arrived at the current "=
;guiding declarations" approach as a special case of a more general me=
chanism. Sometimes you want a function template that has some non-trivial w=
ay of computing its desired parameter types from the types of its arguments=
.. This can't be done in today's C++: if you capture your argument types thr=
ough deduction, your parameter types must exactly match the argument types.=
So the feature I was considering would allow this:<o:p></o:p></p></div><di=
v><p class=3DMsoNormal><o:p> </o:p></p></div><div><p class=3DMsoNormal=
> template<typename ...Args> void f_impl(maybe_add_ref<Args&=
gt;...);<o:p></o:p></p></div><div><p class=3DMsoNormal> template<t=
ypename ...Args> some_keyword_maybe f(Args...) -> f_impl<Args...&g=
t;;<o:p></o:p></p></div><div><p class=3DMsoNormal><o:p> </o:p></p></di=
v><div><p class=3DMsoNormal>The second declaration is a deduction guide: it=
says, when you see a call f(blah), and that function is the best viable fu=
nction, then proceed as if f were replaced by f_impl<Args...>. And fo=
r constructors:<o:p></o:p></p></div><div><p class=3DMsoNormal><o:p> </=
o:p></p></div><div><p class=3DMsoNormal> template<typename T> s=
ome_keyword_maybe vector(initializer_list<T>) -> vector<T>;<=
o:p></o:p></p></div><div><p class=3DMsoNormal><o:p> </o:p></p></div><d=
iv><p class=3DMsoNormal>... says essentially the same thing: when you see v=
ector{1, 2, 3}, if that declaration is the best viable function (say, with =
T =3D int), then 'vector' really means 'vector<int>'.<o:p></o:p></p><=
/div><div><p class=3DMsoNormal><o:p> </o:p></p></div><div><p class=3DM=
soNormal>One reason why you would want something like this instead of givin=
g a definition to the constructor (or function template) is to avoid duplic=
ation -- you already have the constructor definition, and shouldn't be repe=
ating it in the way the old make_-function pattern forced you to. Another r=
eason is to avoid unnecessary copies / moves of function arguments.<o:p></o=
:p></p></div><div><p class=3DMsoNormal> <o:p></o:p></p></div><blockquo=
te style=3D'border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in=
6.0pt;margin-left:4.8pt;margin-right:0in'><div><div><p class=3DMsoNormal s=
tyle=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style=3D'=
font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'> A po=
int in favor of your approach is that Bjarne=E2=80=99s unified function cal=
l syntax proposal is to support =E2=80=9Cexternally defined methods=E2=80=
=9D but doesn=E2=80=99t work for constructors.</span><o:p></o:p></p><p clas=
s=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>=
<span style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F4=
97D'> </span><o:p></o:p></p><p class=3DMsoNormal style=3D'mso-margin-t=
op-alt:auto;mso-margin-bottom-alt:auto'><span style=3D'font-size:11.0pt;fon=
t-family:"Calibri",sans-serif;color:#1F497D'>I plan to start looking at the=
next revision in about a month. OK if we discuss then?</span><o:p></o:p></=
p><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto'><span style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif;c=
olor:#1F497D'> </span><o:p></o:p></p><p class=3DMsoNormal style=3D'mso=
-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style=3D'font-size:1=
1.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Thanks,</span><o:p></=
o:p></p><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bo=
ttom-alt:auto'><span style=3D'font-size:11.0pt;font-family:"Calibri",sans-s=
erif;color:#1F497D'> </span><o:p></o:p></p><p class=3DMsoNormal style=
=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style=3D'font=
-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Mike</span><o:=
p></o:p></p><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margi=
n-bottom-alt:auto'><span style=3D'font-size:11.0pt;font-family:"Calibri",sa=
ns-serif;color:#1F497D'> </span><o:p></o:p></p><div><div style=3D'bord=
er:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=
=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><=
b><span style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif'>From:</=
span></b><span style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif'>=
David Krauss [mailto:<a href=3D"mailto:potswa@gmail.com" target=3D"_blank"=
>potswa@gmail.com</a>] <br><b>Sent:</b> Wednesday, June 24, 2015 4:45 AM<br=
><b>To:</b> Michael Spertus; <a href=3D"mailto:std-proposals@isocpp.org" ta=
rget=3D"_blank">std-proposals@isocpp.org</a><br><b>Cc:</b> Richard Smith<br=
><b>Subject:</b> Factory functions as deducing constructors? (N4471)</span>=
<o:p></o:p></p></div></div><div><div><p class=3DMsoNormal style=3D'mso-marg=
in-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><p cl=
ass=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto=
'>Hi Mike,<o:p></o:p></p></div><div><p class=3DMsoNormal style=3D'mso-margi=
n-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div>=
<p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt=
:auto'>Most libraries already implement factory function templates, e.g. <s=
pan style=3D'font-family:Courier'>make_thing()</span>. Why not just let the=
m be named e.g. <span style=3D'font-family:Courier'>thing()</span>, al=
iasing the class template?<o:p></o:p></p></div><div><p class=3DMsoNormal st=
yle=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p=
></p></div><div><ul type=3Ddisc><li class=3DMsoNormal style=3D'mso-margin-t=
op-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1'>No new dedu=
ction rules are needed.<o:p></o:p></li><li class=3DMsoNormal style=3D'mso-m=
argin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1'>It=
=E2=80=99s a non-breaking change because such aliasing is currently disallo=
wed.<o:p></o:p></li><li class=3DMsoNormal style=3D'mso-margin-top-alt:auto;=
mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1'>It differs from establi=
shed practice only by renaming.<o:p></o:p></li><li class=3DMsoNormal style=
=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 l=
fo1'>The full flexibility of factory functions is preserved, including expl=
icit template arguments.<o:p></o:p></li><li class=3DMsoNormal style=3D'mso-=
margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1'>It =
does not intrude into the class template implementation.<o:p></o:p></li></u=
l></div><div><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-marg=
in-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=3DMsoNormal st=
yle=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>For the sake of =
member templates, such a function template (or function) should still be fo=
und by a qualified-id preceded by the <span style=3D'font-family:Courier'>t=
ypename</span> keyword. It should also be illegal to take its address, or t=
o do anything with its name or template-id besides call it. The factory sho=
uld defer to real constructors when the explicit template argument list sat=
isfies the class template parameters.<o:p></o:p></p></div><div><p class=3DM=
soNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> =
;<o:p></o:p></p></div><div><p class=3DMsoNormal style=3D'mso-margin-top-alt=
:auto;mso-margin-bottom-alt:auto'>Require the factory to be declared after =
the initial declaration of the class template, and require its return type =
to be a specialization.<o:p></o:p></p></div><div><p class=3DMsoNormal style=
=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></=
p></div><div><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-marg=
in-bottom-alt:auto'>Implementation model: Attach the overload set of factor=
y functions to the class template. When name lookup finds the class templat=
e, grab the factories too. If template arguments are provided, treat the cl=
ass template as an overload to the factories and run template argument dedu=
ction for explicit arguments ([temp.deduct]/1-5). If the class template has=
not suffered a deduction failure, terminate deduction and restart overload=
resolution using its constructors.<o:p></o:p></p></div><div><p class=3DMso=
Normal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <=
o:p></o:p></p></div><div><p class=3DMsoNormal style=3D'mso-margin-top-alt:a=
uto;mso-margin-bottom-alt:auto'>I=E2=80=99d also like to propose enforced c=
opy elision, such that simple factory functions don=E2=80=99t require move =
construction. (Call it =E2=80=9Cperfect return.=E2=80=9D) This seems like a=
separate feature. However, it would be nice to have both.<o:p></o:p></p></=
div><div><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-b=
ottom-alt:auto'> <o:p></o:p></p></div><div><p class=3DMsoNormal style=
=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Long ago, in some e=
arly C++ implementations at least, constructors <i>were</i> non-m=
ember factory functions. Hopefully this won=E2=80=99t be seen as =E2=80=9Cc=
oming full circle.=E2=80=9D It=E2=80=99s really not, since the factory has =
no special abilities or status besides sharing a name.<o:p></o:p></p></div>=
<div><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-botto=
m-alt:auto'> <o:p></o:p></p></div><div><p class=3DMsoNormal style=3D'm=
so-margin-top-alt:auto;mso-margin-bottom-alt:auto'> =
- D<o:p></o:p></p></div><div><p =
class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:au=
to'> <o:p></o:p></p></div></div></div></div></div></blockquote></div><=
p class=3DMsoNormal><o:p> </o:p></p></div></div></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--_000_9A3E0561DCF227429F72080EA81ADBC96077F517E6TUS1XCHEVSPIN_--
.
Author: David Krauss <potswa@gmail.com>
Date: Thu, 25 Jun 2015 10:05:32 +0800
Raw View
--Apple-Mail=_E7DE3F32-3CF9-4259-A081-5DB7D52502A1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9306=E2=80=9325, at 8:47 AM, Michael Spertus <mike_spertus@=
symantec.com> wrote:
>=20
> It=E2=80=99s worth mentioning that since I regard the template deduction =
for existing constructors in the primary template as by far the most import=
ant part of the proposal (Indeed, I would strongly favor the proposal even =
without any kind of factory functions), I lean towards a solution that look=
ed as much like existing constructors as possible. I am open to the possibi=
lity that this implication (although not its premise) is fallacious reasoni=
ng on my part.
Heh=E2=80=A6 are we discussing this now? :P
It seems that the transparent feature works well in the majority of simple =
cases (the template type parameter is exactly suitable as the constructor p=
arameter type, partial specializations don=E2=80=99t exist or are exactly c=
ompatible), but sometimes it will break and the programmer will want manual=
control.
How about implicit declaration of the non-member factory functions? Create =
one signature per suitable constructor, including partial and explicit spec=
ializations. Essentially, provide a visible window on the parallel overload=
set.
The implicit definition would follow conservative rules like in N4471, but =
in any doubtful cases it could be defined as deleted. Some cases could fall=
through the cracks, e.g. where a specialization constructor parallels a pr=
imary constructor but one is suitable and the other isn=E2=80=99t. But, the=
fidelity level should be pretty good, authority is returned to the author =
via explicit definitions, and it captures most existing factory functions.
Hopefully that would be the best of both worlds, capturing all the cases wh=
ere N4471 works. I=E2=80=99m happy to postpone detailed analysis until more=
brain cells are free, though.
> On 2015=E2=80=9306=E2=80=9324, at 10:56 PM, David Rodr=C3=ADguez Ibeas <d=
ibeas@ieee.org> wrote:
>=20
> Let's see if I understand the proposal would be replacing 'make_shared<T>=
(arg1, arg2)' with 'shared_ptr<T>(arg1, arg2)' is it?
It would provide a way to replace shared_ptr<T>( ptr ) with shared_ptr( ptr=
). Perhaps there could be a new constructor shared_ptr<T>::shared_ptr( in_=
place_construction_tag<T>, arg1, arg2 ), but it would need separate motivat=
ion. There are plenty of motivating cases, though, so intricate library det=
ails seem premature.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_E7DE3F32-3CF9-4259-A081-5DB7D52502A1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v class=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=
=E2=80=9306=E2=80=9325, at 8:47 AM, Michael Spertus <<a href=3D"mailto:m=
ike_spertus@symantec.com" class=3D"">mike_spertus@symantec.com</a>> wrot=
e:</div><br class=3D"Apple-interchange-newline"><div class=3D""><div class=
=3D"WordSection1" style=3D"page: WordSection1;"><div class=3D"" style=3D"ma=
rgin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', se=
rif;"><span class=3D"" style=3D"font-size: 11pt; font-family: Calibri, sans=
-serif; color: rgb(31, 73, 125);">It=E2=80=99s worth mentioning that since =
I regard the template deduction for existing constructors in the primary te=
mplate as by far the most important part of the proposal (Indeed, I would s=
trongly favor the proposal even without any kind of factory functions), I l=
ean towards a solution that looked as much like existing constructors as po=
ssible. I am open to the possibility that this implication (although not it=
s premise) is fallacious reasoning on my part.</span></div></div></div></bl=
ockquote><br class=3D""></div><div class=3D"">Heh=E2=80=A6 are we discussin=
g this now? :P</div><div class=3D""><br class=3D""></div><div class=3D"">It=
seems that the transparent feature works well in the majority of simple ca=
ses (the template type parameter is exactly suitable as the constructor par=
ameter type, partial specializations don=E2=80=99t exist or are exactly com=
patible), but sometimes it will break and the programmer will want manual c=
ontrol.</div><div class=3D""><br class=3D""></div><div class=3D"">How about=
implicit declaration of the non-member factory functions? Create one signa=
ture per suitable constructor, including partial and explicit specializatio=
ns. Essentially, provide a visible window on the parallel overload set.</di=
v><div class=3D""><br class=3D""></div><div class=3D"">The implicit definit=
ion would follow conservative rules like in N4471, but in any doubtful case=
s it could be defined as deleted. Some cases could fall through the cracks,=
e.g. where a specialization constructor parallels a primary constructor bu=
t one is suitable and the other isn=E2=80=99t. But, the fidelity level shou=
ld be pretty good, authority is returned to the author via explicit definit=
ions, and it captures most existing factory functions.</div><div class=3D""=
><br class=3D""></div><div class=3D"">Hopefully that would be the best of b=
oth worlds, capturing all the cases where N4471 works. I=E2=80=99m happy to=
postpone detailed analysis until more brain cells are free, though.</div><=
div class=3D""><br class=3D""></div><div class=3D""><br class=3D""></div><d=
iv class=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D"">On =
2015=E2=80=9306=E2=80=9324, at 10:56 PM, David Rodr=C3=ADguez Ibeas <<a =
href=3D"mailto:dibeas@ieee.org" class=3D"">dibeas@ieee.org</a>> wrote:</=
div><br class=3D"Apple-interchange-newline"><div class=3D""><span class=3D"=
" style=3D"float: none; display: inline !important;">Let's see if I underst=
and the proposal would be replacing 'make_shared<T>(arg1, arg2)' with=
'shared_ptr<T>(arg1, arg2)' is it?</span><br class=3D""></div></bloc=
kquote></div><br class=3D""><div class=3D"">It would provide a way to repla=
ce <font face=3D"Courier" class=3D"">shared_ptr<T>( ptr )</font>=
with <font face=3D"Courier" class=3D"">shared_ptr( ptr )</font>.=
Perhaps there could be a new constructor <font face=3D"Courier" class=
=3D"">shared_ptr<T>::shared_ptr( in_place_construction_tag<T>, =
arg1, arg2 )</font>, but it would need separate motivation. There are plent=
y of motivating cases, though, so intricate library details seem premature.=
</div></div><div class=3D""><br class=3D""></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_E7DE3F32-3CF9-4259-A081-5DB7D52502A1--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 25 Jun 2015 07:29:04 +0200
Raw View
This is a multi-part message in MIME format.
--------------000000030202050304010708
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 24/06/15 11:44, David Krauss a =C3=A9crit :
> Hi Mike,
>
> Most libraries already implement factory function templates, e.g.=20
> make_thing(). Why not just let them be named e.g. thing(), aliasing=20
> the class template?
>
> * No new deduction rules are needed.
> * It=E2=80=99s a non-breaking change because such aliasing is currently
> disallowed.
> * It differs from established practice only by renaming.
> * The full flexibility of factory functions is preserved, including
> explicit template arguments.
> * It does not intrude into the class template implementation.
>
>
> For the sake of member templates, such a function template (or=20
> function) should still be found by a qualified-id preceded by the=20
> typename keyword. It should also be illegal to take its address, or to=20
> do anything with its name or template-id besides call it. The factory=20
> should defer to real constructors when the explicit template argument=20
> list satisfies the class template parameters.
>
> Require the factory to be declared after the initial declaration of=20
> the class template, and require its return type to be a specialization.
>
I like both approaches.
I have a question. Could a generic function make use of these factory=20
functions or deduced constructors?
in oder word, can a class/function template deduce these factory=20
functions or deduced constructors from a class template parameter?
E.g. something like
template <template <typename ...> class TC, typename ...Xs>
auto f(Xs ... xs )
{
// ...
auto tc =3D TC(xs...);
// ...
}
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--------------000000030202050304010708
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<div class=3D"moz-cite-prefix">Le 24/06/15 11:44, David Krauss a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:C9C172D2-327C-47E6-B019-94D2FA0F3BF1@gmail.com"
type=3D"cite">
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf=
-8">
<div class=3D"">Hi Mike,</div>
<div class=3D""><br class=3D"">
</div>
<div class=3D"">Most libraries already implement factory function
templates, e.g. <font class=3D"" face=3D"Courier">make_thing()</fon=
t>.
Why not just let them be named e.g.=C2=A0<font class=3D""
face=3D"Courier">thing()</font>, aliasing the class template?</di=
v>
<div class=3D""><br class=3D"">
</div>
<div class=3D"">
<ul class=3D"">
<li class=3D"">No new deduction rules are needed.</li>
<li class=3D"">It=E2=80=99s a non-breaking change because such al=
iasing
is currently disallowed.</li>
<li class=3D"">It differs from established practice only by
renaming.</li>
<li class=3D"">The full flexibility of factory functions is
preserved, including explicit template arguments.</li>
<li class=3D"">It does not intrude into the class template
implementation.</li>
</ul>
</div>
<div class=3D""><br class=3D"">
</div>
<div class=3D"">For the sake of member templates, such a function
template (or function) should still be found by a qualified-id
preceded by the <font class=3D"" face=3D"Courier">typename</font>
keyword. It should also be illegal to take its address, or to do
anything with its name or template-id besides call it. The
factory should defer to real constructors when the explicit
template argument list satisfies the class template parameters.</di=
v>
<div class=3D""><br class=3D"">
</div>
<div class=3D"">Require the factory to be declared after the initial
declaration of the class template, and require its return type
to be a specialization.</div>
<div class=3D""><br class=3D"">
</div>
</blockquote>
I like both approaches.<br>
<br>
I have a question. Could a generic function make use of these
factory functions or deduced constructors?<br>
in oder word, can a class/function template deduce these factory
functions or deduced constructors from a class template parameter?<br>
<br>
E.g. something like<br>
<br>
template <template <typename ...> class TC, typename
...Xs><br>
auto f(Xs ... xs )<br>
{<br>
=C2=A0=C2=A0=C2=A0 // ...<br>
=C2=A0=C2=A0=C2=A0 auto tc =3D TC(xs...);<br>
=C2=A0=C2=A0=C2=A0 // ...<br>
}<br>
<br>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------000000030202050304010708--
.
Author: David Krauss <potswa@mac.com>
Date: Thu, 25 Jun 2015 13:37:22 +0800
Raw View
> On 2015=E2=80=9306=E2=80=9325, at 1:29 PM, Vicente J. Botet Escriba <vice=
nte.botet@wanadoo.fr> wrote:
>=20
> template <template <typename ...> class TC, typename ...Xs>
> auto f(Xs ... xs )
> {
> // ...
> auto tc =3D TC(xs=E2=80=A6);
Good point. This needs to be supported.
This reinforces the importance of attaching any free functions to the prima=
ry class template. My proposed factories are definitely not ordinary functi=
ons.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.