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

I find my self regularly creating static factory functions on classes to=20
better describe how something is being constructed or to avoid having flags=
=20
passed which may have some invalid permutations. Now some times this is=20
because of poor design(Lazy/efficient) but it does make me wonder if=20
constructers with names different to their class would be helpful.

Take this contrived example:
class Temperature
{
   public:
        Temperature(float k);
        Temperature(float c, bool celsiusOrFahrenheit); //An abomination

        float inKelvin() const;
        float inCelsius() const;
        float inFahrenheit() const;
   private:
       float kelvin;
};

auto zero =3D Temperature(0);
auto zeroC =3D Temperature(=E2=88=92273.15, true);
auto zeroF =3D Temperature(=E2=88=92459.67, false);

class Temperature
{
   public:
        struct F{};
        struct C{};
        struct K{};

        Temperature(float k, K);
        Temperature(float c, C);
        Temperature(float f, F);

        float inKelvin() const;
        float inCelsius() const;
        float inFahrenheit() const;
   private:
       float kelvin;
};


auto zero =3D Temperature(0, Temperature::K());
auto zeroC =3D Temperature(-273.15, Temperature::C());
auto zeroF =3D Temperature(=E2=88=92459.67, Temperature::F());

class Temperature
{
   public:
        static Temperature fromKelvin(float k);
        static Temperature fromCelsius(float c);
        static Temperature fromFahrenheight(float f);

        float inKelvin() const;
        float inCelsius() const;
        float inFahrenheit() const;
   private:
       float kelvin;
};


auto zero =3D Temperature::fromKelvin(0);
auto zeroC =3D Temperature::fromCelsius(-273.15);
auto zeroF =3D Temperature::fromFahrenheight(=E2=88=92459.67);



First. I think most people wouldn't like the first.

Second. Helpful for meta programming and I quite like it in general but=20
this becomes more complex the more arguments involved. (wish I came up with=
=20
a better example now.).

Third. You cannot construct the temperature on the heap. But is as clear as=
=20
the second.=20

Would it be nice to do something like:
class Temperature
{
   public:
        constructor fromKelvin(float k);
        constructor fromCelsius(float c);
        constructor fromFahrenheight(float f);

        float inKelvin() const;
        float inCelsius() const;
        float inFahrenheit() const;
   private:
       float kelvin;
};


auto zero_ptr =3D new Temperature::fromKelvin(0);
auto zeroC_ptr =3D new Temperature::fromCelsius(-273.15);
auto zeroF_ptr =3D new Temperature::fromFahrenheight(=E2=88=92459.67);

Please don't hold this against me but it does have some similarities to=20
Objective-C's init methods or other languages where the argument names are=
=20
used to select the call.

Thanks,
Stefan Pantos

--=20
The contents (including attachments) of this email are strictly=20
confidential, intended for the addressee(s) only and may be legally=20
privileged.  If you are not the intended recipient, please contact the=20
sender immediately and delete all copies of this email without distributing=
=20
it further in any way.  Torstone Technology Limited, its affiliates and=20
staff do not accept any liability for the contents of the message, and the=
=20
sending of this message is not intended to form a contract with the=20
recipient.  Torstone Technology Limited is registered in England and Wales=
=20
with company number 07490275 and registered office at 8 Lloyd's Avenue,=20
London EC3N 3EL, United Kingdom.

--=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/84cb007b-d3c2-4204-be97-27f7f0df0e7d%40isocpp.or=
g.

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

<div dir=3D"ltr">I find my self regularly creating static factory functions=
 on classes to better describe how something is being constructed or to avo=
id having flags passed which may have some invalid permutations. Now some t=
imes this is because of poor design(Lazy/efficient) but it does make me won=
der if constructers with names different to their class would be helpful.<d=
iv><br></div><div>Take this contrived example:</div><div class=3D"prettypri=
nt" style=3D"background-color: rgb(250, 250, 250); border: 1px solid rgb(18=
7, 187, 187); word-wrap: break-word;"><code class=3D"prettyprint"><div clas=
s=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">class</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Temperatur=
e</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0</span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">public</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 =C2=A0 =C2=A0 =C2=
=A0 </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Temper=
ature</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">float</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> k</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>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </s=
pan><span style=3D"color: #606;" class=3D"styled-by-prettify">Temperature</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">float</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> c</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">bool</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> celsiusOrFahrenheit</span><span style=3D"color: #660;" c=
lass=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">//An abomination</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">float</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> inKelvin</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">()</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">const</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 =C2=A0 =C2=A0 </span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">float</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> inCelsius</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">const</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">float</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> inFahrenheit</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">cons=
t</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">private</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0</span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
float</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> kelv=
in</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">};</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> zero </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styl=
ed-by-prettify">Temperature</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">(</span><span style=3D"color: #066;" class=3D"styled-by-pr=
ettify">0</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> zeroC </span><span s=
tyle=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: #=
606;" class=3D"styled-by-prettify">Temperature</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">(=E2=88=92</span><span style=3D"color: =
#066;" class=3D"styled-by-prettify">273.15</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">true</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">auto<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> zeroF </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Temperature</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">(=E2=88=92</span><span styl=
e=3D"color: #066;" class=3D"styled-by-prettify">459.67</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">false</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">class</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Tem=
perature</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r></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</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>struct</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> F<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">{};</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">struct</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 C</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{};</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">struct</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> K</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 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #606;" class=3D"style=
d-by-prettify">Temperature</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">float</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> k</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> K</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Temperatu=
re</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">float</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> c</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> C</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Temperature</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">float</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> f</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> F</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">float</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> inKelvin</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">const</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">float</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> inCelsius</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">const</=
span><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 =C2=A0 =C2=
=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>float</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> inF=
ahrenheit</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(=
)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">const</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0</span><span st=
yle=3D"color: #008;" 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 =C2=A0 =C2=A0 =C2=A0</span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">float</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> kelvin</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">};</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br><br><br></span><span style=3D"color: #008;"=
 class=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> zero </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: #606;" class=3D"styled-by-pretti=
fy">Temperature</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">(</span><span style=3D"color: #066;" class=3D"styled-by-prettify">0</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: #606;" class=3D"styled-by-prettify">Temperature</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">K</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: #008;" class=3D"st=
yled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> zeroC </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: #606;" class=3D"styled-by-prettify">Tempera=
ture</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(-</sp=
an><span style=3D"color: #066;" class=3D"styled-by-prettify">273.15</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #606;" class=3D"styled-by-prettify">Temperature</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">C</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">());</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> zeroF </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #606;" class=3D"styled-by-prettify">Temperature</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">(=E2=88=92</=
span><span style=3D"color: #066;" class=3D"styled-by-prettify">459.67</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #606;" class=3D"styled-by-prettify">Temperature</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">F</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">());</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br><br></span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">class</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettif=
y">Temperature</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">{<=
/span><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">publ=
ic</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0=
 =C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">static</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Temperat=
ure</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> fromKe=
lvin</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">float</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> k</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">static</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #606;" class=3D"styled-by-prettify">Temperature</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> fromCelsius</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">float</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> c</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">static</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;"=
 class=3D"styled-by-prettify">Temperature</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> fromFahrenheight</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">float</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> f</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">float</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> inKelvin</span><span style=3D"color: #660;" c=
lass=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">const</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">float</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> inCelsius</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">con=
st</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0=
 =C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">float</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 inFahrenheit</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">const</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 =C2=A0</span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">private</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0</=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">float</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> kelvin</span><sp=
an 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"co=
lor: #660;" class=3D"styled-by-prettify">};</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br><br><br></span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> zero </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"> </span><span style=3D"color: #606;" class=3D"styled-by-p=
rettify">Temperature</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">fromKelvin</span><span style=3D"color: #660;" 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 s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> zeroC </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: #606;" class=
=3D"styled-by-prettify">Temperature</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">fromCelsius</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">(-</span><span style=3D"color: #066;" class=3D"styled-by-=
prettify">273.15</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r></span><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> zeroF </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #606;" class=3D"styled-by-prettify">Temperature</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">fromFahrenheight</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">(=E2=88=92</span><span style=3D"co=
lor: #066;" class=3D"styled-by-prettify">459.67</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></div></code></div><div><br><br=
></div><div>First. I think most people wouldn&#39;t like the first.</div><d=
iv><br></div><div>Second. Helpful for meta programming and I quite like it =
in general but this becomes more complex the more arguments involved. (wish=
 I came up with a better example now.).</div><div><br></div><div>Third. You=
 cannot construct the temperature on the heap. But is as clear as the secon=
d.=C2=A0</div><div><br></div><div>Would it be nice to do something like:</d=
iv><div><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250,=
 250); border: 1px solid rgb(187, 187, 187); word-wrap: break-word;"><code =
class=3D"prettyprint"><div class=3D"subprettyprint"><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">Temperature</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>=C2=A0 =C2=A0</span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">public</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 constructor fromKelvin</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">float</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> k</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 constructor fromCelsius</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">float</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> c</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 constructor=
 fromFahrenheight</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">fl=
oat</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> f</spa=
n><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 =C2=A0 =
=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">float</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
inKelvin</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">const</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">float</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> inCelsius</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">const</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">float</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> inFahrenheit</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">const</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br>=C2=A0 =C2=A0</span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">private</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 =C2=A0 =C2=A0</span><span style=3D"color: =
#008;" class=3D"styled-by-prettify">float</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> kelvin</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">};</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br><br><br></span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">auto</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> zero_ptr </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #008;" class=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-by-prettify">Temperature</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">fromKelvin</span><span style=3D"colo=
r: #660;" 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"styled-=
by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">auto</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> zeroC_ptr </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: #008;" class=3D"styled-by-prettify">new</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Temperature</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">fromCelsius</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">(-</span><span style=3D"color: #06=
6;" class=3D"styled-by-prettify">273.15</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: #008;" class=3D"style=
d-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> zeroF_ptr </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">new</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #606;" class=3D"styled-by-prettify">Temperature</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">fromFahrenheight</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">(=E2=88=92</span><span=
 style=3D"color: #066;" class=3D"styled-by-prettify">459.67</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br></span></div></code></div><div=
 class=3D"subprettyprint" style=3D"font-family: monospace;"><div class=3D"s=
ubprettyprint" style=3D"color: rgb(34, 34, 34);"><span style=3D"color: rgb(=
102, 0, 102); font-family: Arial, Helvetica, sans-serif;"><br></span></div>=
</div></div><div>Please don&#39;t hold this against me but it does have som=
e similarities to Objective-C&#39;s init methods or other languages where t=
he argument names are used to select the call.</div><div><br></div><div>Tha=
nks,</div><div>Stefan Pantos</div></div>
<br>
<font face=3D"Arial, Helvetica, sans-serif"><span style=3D"font-size:1.3em"=
>The contents
(including attachments) of this email are strictly confidential, intended f=
or
the addressee(s) only and may be legally privileged.=C2=A0 If you are not t=
he intended
recipient, please contact the sender immediately and delete all copies of t=
his
email without distributing it further in any way.=C2=A0 Torstone Technology
Limited, its affiliates and staff do not accept any liability for the conte=
nts
of the message, and the sending of this message is not intended to form a
contract with the recipient. =C2=A0Torstone Technology Limited is registere=
d in England and Wales with company number 07490275 and registered office a=
t 8 Lloyd&#39;s Avenue, London EC3N 3EL, United Kingdom.</span></font>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/84cb007b-d3c2-4204-be97-27f7f0df0e7d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/84cb007b-d3c2-4204-be97-27f7f0df0e7d=
%40isocpp.org</a>.<br />

------=_Part_152_744654487.1484226455130--

.

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

Some sort of strong typedef facility would also help, create different
types for Fahrenheit and Celsius and overload constructor directly.

--
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/CAEddoJZrxMK1jsWzO%3DMrBBXsVL_rMxW6LnsYUvGej%3DsyRDu%2Byg%40mail.gmail.com.

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

<div dir=3D"auto">Some sort of strong typedef facility would also help, cre=
ate different types for Fahrenheit and Celsius and overload constructor dir=
ectly.</div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAEddoJZrxMK1jsWzO%3DMrBBXsVL_rMxW6Ln=
sYUvGej%3DsyRDu%2Byg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEddoJZrxM=
K1jsWzO%3DMrBBXsVL_rMxW6LnsYUvGej%3DsyRDu%2Byg%40mail.gmail.com</a>.<br />

--001a11407a10aa47700545e57e18--

.

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

Yes similar to the second example. I didn't want to list all possible ways.

I think it is considered good practice not to have flags as parameters to
function(depending on context obviously). Better to have a  separate
functions with a descriptive name and the appropriate parameters. Well this
is similar but for constructors.

On Thu, 12 Jan 2017 at 13:14, Jonathan M=C3=BCller <jonathanmueller.dev@gma=
il.com>
wrote:

> Some sort of strong typedef facility would also help, create different
> types for Fahrenheit and Celsius and overload constructor directly.
>
>
>
>
>
>
>
>
> --
>
>
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
>
>
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/HsChO8cvvVY/=
unsubscribe
> .
>
>
> To unsubscribe from this group and all its topics, 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/CAEddoJZrxMK=
1jsWzO%3DMrBBXsVL_rMxW6LnsYUvGej%3DsyRDu%2Byg%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEddoJZrxM=
K1jsWzO%3DMrBBXsVL_rMxW6LnsYUvGej%3DsyRDu%2Byg%40mail.gmail.com?utm_medium=
=3Demail&utm_source=3Dfooter>
> .
>
>
>

--=20
The contents (including attachments) of this email are strictly=20
confidential, intended for the addressee(s) only and may be legally=20
privileged.  If you are not the intended recipient, please contact the=20
sender immediately and delete all copies of this email without distributing=
=20
it further in any way.  Torstone Technology Limited, its affiliates and=20
staff do not accept any liability for the contents of the message, and the=
=20
sending of this message is not intended to form a contract with the=20
recipient.  Torstone Technology Limited is registered in England and Wales=
=20
with company number 07490275 and registered office at 8 Lloyd's Avenue,=20
London EC3N 3EL, United Kingdom.

--=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/CAKj5Z3o4z3hjvUnTnovK3MFfVaA2c_%2BZ-MMgYoMec%2B7=
4%2BDBzzw%40mail.gmail.com.

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

<div>Yes similar to the second example. I didn&#39;t want to list all possi=
ble ways.</div><div><br></div><div>I think it is considered good practice n=
ot to have flags as parameters to function(depending on context obviously).=
 Better to have a =C2=A0separate functions with a descriptive name and the =
appropriate parameters. Well this is similar but for constructors.</div><di=
v><br><div class=3D"gmail_quote"><div>On Thu, 12 Jan 2017 at 13:14, Jonatha=
n M=C3=BCller &lt;<a href=3D"mailto:jonathanmueller.dev@gmail.com">jonathan=
mueller.dev@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div class=3D"gmail_msg">Some sort of strong typedef facility would also =
help, create different types for Fahrenheit and Celsius and overload constr=
uctor directly.</div><br><br><br><br><p class=3D"gmail_msg"></p><br><br><br=
><br>-- <br class=3D"gmail_msg"><br><br>You received this message because y=
ou are subscribed to a topic in the Google Groups &quot;ISO C++ Standard - =
Future Proposals&quot; group.<br class=3D"gmail_msg"><br><br>To unsubscribe=
 from this topic, visit <a href=3D"https://groups.google.com/a/isocpp.org/d=
/topic/std-proposals/HsChO8cvvVY/unsubscribe" class=3D"gmail_msg" target=3D=
"_blank">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/HsChO=
8cvvVY/unsubscribe</a>.<br class=3D"gmail_msg"><br><br>To unsubscribe from =
this group and all its topics, send an email to <a href=3D"mailto:std-propo=
sals+unsubscribe@isocpp.org" class=3D"gmail_msg" target=3D"_blank">std-prop=
osals+unsubscribe@isocpp.org</a>.<br class=3D"gmail_msg"><br><br>To post to=
 this group, send email to <a href=3D"mailto:std-proposals@isocpp.org" clas=
s=3D"gmail_msg" target=3D"_blank">std-proposals@isocpp.org</a>.<br class=3D=
"gmail_msg"><br><br>To view this discussion on the web visit <a href=3D"htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEddoJZrxMK1jsWz=
O%3DMrBBXsVL_rMxW6LnsYUvGej%3DsyRDu%2Byg%40mail.gmail.com?utm_medium=3Demai=
l&amp;utm_source=3Dfooter" class=3D"gmail_msg" target=3D"_blank">https://gr=
oups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEddoJZrxMK1jsWzO%3DMrB=
BXsVL_rMxW6LnsYUvGej%3DsyRDu%2Byg%40mail.gmail.com</a>.<br class=3D"gmail_m=
sg"><br><br></blockquote></div></div>

<br>
<font face=3D"Arial, Helvetica, sans-serif"><span style=3D"font-size:1.3em"=
>The contents
(including attachments) of this email are strictly confidential, intended f=
or
the addressee(s) only and may be legally privileged.=C2=A0 If you are not t=
he intended
recipient, please contact the sender immediately and delete all copies of t=
his
email without distributing it further in any way.=C2=A0 Torstone Technology
Limited, its affiliates and staff do not accept any liability for the conte=
nts
of the message, and the sending of this message is not intended to form a
contract with the recipient. =C2=A0Torstone Technology Limited is registere=
d in England and Wales with company number 07490275 and registered office a=
t 8 Lloyd&#39;s Avenue, London EC3N 3EL, United Kingdom.</span></font>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKj5Z3o4z3hjvUnTnovK3MFfVaA2c_%2BZ-M=
MgYoMec%2B74%2BDBzzw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKj5Z3o4z3=
hjvUnTnovK3MFfVaA2c_%2BZ-MMgYoMec%2B74%2BDBzzw%40mail.gmail.com</a>.<br />

--001a113ad5da0453210545e5df24--

.

------=_Part_730_1838115120.1484234634883
Content-Type: multipart/alternative;
 boundary="----=_Part_731_557467787.1484234634884"

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



On Thursday, January 12, 2017 at 8:07:35 AM UTC-5,=20
stefan...@torstonetech.com wrote:
>
> I find my self regularly creating static factory functions on classes to=
=20
> better describe how something is being constructed or to avoid having fla=
gs=20
> passed which may have some invalid permutations. Now some times this is=
=20
> because of poor design(Lazy/efficient) but it does make me wonder if=20
> constructers with names different to their class would be helpful.
>
> Take this contrived example:
> class Temperature
> {
>    public:
>         Temperature(float k);
>         Temperature(float c, bool celsiusOrFahrenheit); //An abomination
>
>         float inKelvin() const;
>         float inCelsius() const;
>         float inFahrenheit() const;
>    private:
>        float kelvin;
> };
>
> auto zero =3D Temperature(0);
> auto zeroC =3D Temperature(=E2=88=92273.15, true);
> auto zeroF =3D Temperature(=E2=88=92459.67, false);
>
> class Temperature
> {
>    public:
>         struct F{};
>         struct C{};
>         struct K{};
>
>         Temperature(float k, K);
>         Temperature(float c, C);
>         Temperature(float f, F);
>
>         float inKelvin() const;
>         float inCelsius() const;
>         float inFahrenheit() const;
>    private:
>        float kelvin;
> };
>
>
> auto zero =3D Temperature(0, Temperature::K());
> auto zeroC =3D Temperature(-273.15, Temperature::C());
> auto zeroF =3D Temperature(=E2=88=92459.67, Temperature::F());
>
> class Temperature
> {
>    public:
>         static Temperature fromKelvin(float k);
>         static Temperature fromCelsius(float c);
>         static Temperature fromFahrenheight(float f);
>
>         float inKelvin() const;
>         float inCelsius() const;
>         float inFahrenheit() const;
>    private:
>        float kelvin;
> };
>
>
> auto zero =3D Temperature::fromKelvin(0);
> auto zeroC =3D Temperature::fromCelsius(-273.15);
> auto zeroF =3D Temperature::fromFahrenheight(=E2=88=92459.67);
>
>
>
> First. I think most people wouldn't like the first.
>
> Second. Helpful for meta programming and I quite like it in general but=
=20
> this becomes more complex the more arguments involved. (wish I came up wi=
th=20
> a better example now.).
>
> Third. You cannot construct the temperature on the heap. But is as clear=
=20
> as the second.
>

Watch me:

new auto(Temperature::fromCelsius(-273.15));

Oh look, it's constructed on the heap now. The system allocates memory,=20
passes it as the return value to `fromCelsius`, who calls the right=20
constructor of `Temperature` in a prvalue that gets returned. No copying.=
=20
No moving.

Behold the wonders of guaranteed elision ;)

--=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/fec0c273-1b76-4ff7-a323-6d2e4a0d5233%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Thursday, January 12, 2017 at 8:07:35 AM UTC-5,=
 stefan...@torstonetech.com 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 find my self regularly creating static factory fun=
ctions on classes to better describe how something is being constructed or =
to avoid having flags passed which may have some invalid permutations. Now =
some times this is because of poor design(Lazy/efficient) but it does make =
me wonder if constructers with names different to their class would be help=
ful.<div><br></div><div>Take this contrived example:</div><div style=3D"bac=
kground-color:rgb(250,250,250);border:1px solid rgb(187,187,187);word-wrap:=
break-word"><code><div><span style=3D"color:#008">class</span><span style=
=3D"color:#000"> </span><span style=3D"color:#606">Temperature</span><span =
style=3D"color:#000"><br></span><span style=3D"color:#660">{</span><span st=
yle=3D"color:#000"><br>=C2=A0 =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 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#606">Temperature</=
span><span style=3D"color:#660">(</span><span style=3D"color:#008">float</s=
pan><span style=3D"color:#000"> k</span><span style=3D"color:#660">);</span=
><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span st=
yle=3D"color:#606">Temperature</span><span style=3D"color:#660">(</span><sp=
an style=3D"color:#008">float</span><span style=3D"color:#000"> c</span><sp=
an style=3D"color:#660">,</span><span style=3D"color:#000"> </span><span st=
yle=3D"color:#008">bool</span><span style=3D"color:#000"> celsiusOrFahrenhe=
it</span><span style=3D"color:#660">);</span><span style=3D"color:#000"> </=
span><span style=3D"color:#800">//An abomination</span><span style=3D"color=
:#000"><br><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#008=
">float</span><span style=3D"color:#000"> inKelvin</span><span style=3D"col=
or:#660">()</span><span style=3D"color:#000"> </span><span style=3D"color:#=
008">const</span><span style=3D"color:#660">;</span><span style=3D"color:#0=
00"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#008">float=
</span><span style=3D"color:#000"> inCelsius</span><span style=3D"color:#66=
0">()</span><span style=3D"color:#000"> </span><span style=3D"color:#008">c=
onst</span><span style=3D"color:#660">;</span><span style=3D"color:#000"><b=
r>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#008">float</span=
><span style=3D"color:#000"> inFahrenheit</span><span style=3D"color:#660">=
()</span><span style=3D"color:#000"> </span><span style=3D"color:#008">cons=
t</span><span style=3D"color:#660">;</span><span style=3D"color:#000"><br>=
=C2=A0 =C2=A0</span><span style=3D"color:#008">private</span><span style=3D=
"color:#660">:</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0</span><span style=3D"color:#008">float</span><span style=3D"color:#0=
00"> kelvin</span><span style=3D"color:#660">;</span><span style=3D"color:#=
000"><br></span><span style=3D"color:#660">};</span><span style=3D"color:#0=
00"><br><br></span><span style=3D"color:#008">auto</span><span style=3D"col=
or:#000"> zero </span><span style=3D"color:#660">=3D</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#606">Temperature</span><span style=
=3D"color:#660">(</span><span style=3D"color:#066">0</span><span style=3D"c=
olor:#660">);</span><span style=3D"color:#000"><br></span><span style=3D"co=
lor:#008">auto</span><span style=3D"color:#000"> zeroC </span><span style=
=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><span style=3D=
"color:#606">Temperature</span><span style=3D"color:#660">(=E2=88=92</span>=
<span style=3D"color:#066">273.15</span><span style=3D"color:#660">,</span>=
<span style=3D"color:#000"> </span><span style=3D"color:#008">true</span><s=
pan style=3D"color:#660">);</span><span style=3D"color:#000"><br></span><sp=
an style=3D"color:#008">auto</span><span style=3D"color:#000"> zeroF </span=
><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><s=
pan style=3D"color:#606">Temperature</span><span style=3D"color:#660">(=E2=
=88=92</span><span style=3D"color:#066">459.67</span><span style=3D"color:#=
660">,</span><span style=3D"color:#000"> </span><span style=3D"color:#008">=
false</span><span style=3D"color:#660">);</span><span style=3D"color:#000">=
<br><br></span><span style=3D"color:#008">class</span><span style=3D"color:=
#000"> </span><span style=3D"color:#606">Temperature</span><span style=3D"c=
olor:#000"><br></span><span style=3D"color:#660">{</span><span style=3D"col=
or:#000"><br>=C2=A0 =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 =C2=
=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#008">struct</span><span styl=
e=3D"color:#000"> F</span><span style=3D"color:#660">{};</span><span style=
=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color=
:#008">struct</span><span style=3D"color:#000"> C</span><span style=3D"colo=
r:#660">{};</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 </span><span style=3D"color:#008">struct</span><span style=3D"color:#00=
0"> K</span><span style=3D"color:#660">{};</span><span style=3D"color:#000"=
><br><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#606">Temp=
erature</span><span style=3D"color:#660">(</span><span style=3D"color:#008"=
>float</span><span style=3D"color:#000"> k</span><span style=3D"color:#660"=
>,</span><span style=3D"color:#000"> K</span><span style=3D"color:#660">);<=
/span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><sp=
an style=3D"color:#606">Temperature</span><span style=3D"color:#660">(</spa=
n><span style=3D"color:#008">float</span><span style=3D"color:#000"> c</spa=
n><span style=3D"color:#660">,</span><span style=3D"color:#000"> C</span><s=
pan style=3D"color:#660">);</span><span style=3D"color:#000"><br>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#606">Temperature</span><span=
 style=3D"color:#660">(</span><span style=3D"color:#008">float</span><span =
style=3D"color:#000"> f</span><span style=3D"color:#660">,</span><span styl=
e=3D"color:#000"> F</span><span style=3D"color:#660">);</span><span style=
=3D"color:#000"><br><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"c=
olor:#008">float</span><span style=3D"color:#000"> inKelvin</span><span sty=
le=3D"color:#660">()</span><span style=3D"color:#000"> </span><span style=
=3D"color:#008">const</span><span style=3D"color:#660">;</span><span style=
=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color=
:#008">float</span><span style=3D"color:#000"> inCelsius</span><span style=
=3D"color:#660">()</span><span style=3D"color:#000"> </span><span style=3D"=
color:#008">const</span><span style=3D"color:#660">;</span><span style=3D"c=
olor:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#008=
">float</span><span style=3D"color:#000"> inFahrenheit</span><span style=3D=
"color:#660">()</span><span style=3D"color:#000"> </span><span style=3D"col=
or:#008">const</span><span style=3D"color:#660">;</span><span style=3D"colo=
r:#000"><br>=C2=A0 =C2=A0</span><span style=3D"color:#008">private</span><s=
pan style=3D"color:#660">:</span><span style=3D"color:#000"><br>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0</span><span style=3D"color:#008">float</span><span style=
=3D"color:#000"> kelvin</span><span style=3D"color:#660">;</span><span styl=
e=3D"color:#000"><br></span><span style=3D"color:#660">};</span><span style=
=3D"color:#000"><br><br><br></span><span style=3D"color:#008">auto</span><s=
pan style=3D"color:#000"> zero </span><span style=3D"color:#660">=3D</span>=
<span style=3D"color:#000"> </span><span style=3D"color:#606">Temperature</=
span><span style=3D"color:#660">(</span><span style=3D"color:#066">0</span>=
<span style=3D"color:#660">,</span><span style=3D"color:#000"> </span><span=
 style=3D"color:#606">Temperature</span><span style=3D"color:#660">::</span=
><span style=3D"color:#000">K</span><span style=3D"color:#660">());</span><=
span style=3D"color:#000"><br></span><span style=3D"color:#008">auto</span>=
<span style=3D"color:#000"> zeroC </span><span style=3D"color:#660">=3D</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#606">Temperatur=
e</span><span style=3D"color:#660">(-</span><span style=3D"color:#066">273.=
15</span><span style=3D"color:#660">,</span><span style=3D"color:#000"> </s=
pan><span style=3D"color:#606">Temperature</span><span style=3D"color:#660"=
>::</span><span style=3D"color:#000">C</span><span style=3D"color:#660">())=
;</span><span style=3D"color:#000"><br></span><span style=3D"color:#008">au=
to</span><span style=3D"color:#000"> zeroF </span><span style=3D"color:#660=
">=3D</span><span style=3D"color:#000"> </span><span style=3D"color:#606">T=
emperature</span><span style=3D"color:#660">(=E2=88=92</span><span style=3D=
"color:#066">459.67</span><span style=3D"color:#660">,</span><span style=3D=
"color:#000"> </span><span style=3D"color:#606">Temperature</span><span sty=
le=3D"color:#660">::</span><span style=3D"color:#000">F</span><span style=
=3D"color:#660">());</span><span style=3D"color:#000"><br><br></span><span =
style=3D"color:#008">class</span><span style=3D"color:#000"> </span><span s=
tyle=3D"color:#606">Temperature</span><span style=3D"color:#000"><br></span=
><span style=3D"color:#660">{</span><span style=3D"color:#000"><br>=C2=A0 =
=C2=A0</span><span style=3D"color:#008">public</span><span style=3D"color:#=
660">:</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </s=
pan><span style=3D"color:#008">static</span><span style=3D"color:#000"> </s=
pan><span style=3D"color:#606">Temperature</span><span style=3D"color:#000"=
> fromKelvin</span><span style=3D"color:#660">(</span><span style=3D"color:=
#008">float</span><span style=3D"color:#000"> k</span><span style=3D"color:=
#660">);</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <=
/span><span style=3D"color:#008">static</span><span style=3D"color:#000"> <=
/span><span style=3D"color:#606">Temperature</span><span style=3D"color:#00=
0"> fromCelsius</span><span style=3D"color:#660">(</span><span style=3D"col=
or:#008">float</span><span style=3D"color:#000"> c</span><span style=3D"col=
or:#660">);</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 </span><span style=3D"color:#008">static</span><span style=3D"color:#00=
0"> </span><span style=3D"color:#606">Temperature</span><span style=3D"colo=
r:#000"> fromFahrenheight</span><span style=3D"color:#660">(</span><span st=
yle=3D"color:#008">float</span><span style=3D"color:#000"> f</span><span st=
yle=3D"color:#660">);</span><span style=3D"color:#000"><br><br>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#008">float</span><span style=
=3D"color:#000"> inKelvin</span><span style=3D"color:#660">()</span><span s=
tyle=3D"color:#000"> </span><span style=3D"color:#008">const</span><span st=
yle=3D"color:#660">;</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 </span><span style=3D"color:#008">float</span><span style=3D"col=
or:#000"> inCelsius</span><span style=3D"color:#660">()</span><span style=
=3D"color:#000"> </span><span style=3D"color:#008">const</span><span style=
=3D"color:#660">;</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0=
 =C2=A0 </span><span style=3D"color:#008">float</span><span style=3D"color:=
#000"> inFahrenheit</span><span style=3D"color:#660">()</span><span style=
=3D"color:#000"> </span><span style=3D"color:#008">const</span><span style=
=3D"color:#660">;</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0</span>=
<span style=3D"color:#008">private</span><span style=3D"color:#660">:</span=
><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0</span><span sty=
le=3D"color:#008">float</span><span style=3D"color:#000"> kelvin</span><spa=
n style=3D"color:#660">;</span><span style=3D"color:#000"><br></span><span =
style=3D"color:#660">};</span><span style=3D"color:#000"><br><br><br></span=
><span style=3D"color:#008">auto</span><span style=3D"color:#000"> zero </s=
pan><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </span=
><span style=3D"color:#606">Temperature</span><span style=3D"color:#660">::=
</span><span style=3D"color:#000">fromKelvin</span><span style=3D"color:#66=
0">(</span><span style=3D"color:#066">0</span><span style=3D"color:#660">);=
</span><span style=3D"color:#000"><br></span><span style=3D"color:#008">aut=
o</span><span style=3D"color:#000"> zeroC </span><span style=3D"color:#660"=
>=3D</span><span style=3D"color:#000"> </span><span style=3D"color:#606">Te=
mperature</span><span style=3D"color:#660">::</span><span style=3D"color:#0=
00">fromCelsius</span><span style=3D"color:#660">(-</span><span style=3D"co=
lor:#066">273.<wbr>15</span><span style=3D"color:#660">);</span><span style=
=3D"color:#000"><br></span><span style=3D"color:#008">auto</span><span styl=
e=3D"color:#000"> zeroF </span><span style=3D"color:#660">=3D</span><span s=
tyle=3D"color:#000"> </span><span style=3D"color:#606">Temperature</span><s=
pan style=3D"color:#660">::</span><span style=3D"color:#000">fromFahrenheig=
ht</span><span style=3D"color:#660">(<wbr>=E2=88=92</span><span style=3D"co=
lor:#066">459.67</span><span style=3D"color:#660">);</span><span style=3D"c=
olor:#000"><br><br></span></div></code></div><div><br><br></div><div>First.=
 I think most people wouldn&#39;t like the first.</div><div><br></div><div>=
Second. Helpful for meta programming and I quite like it in general but thi=
s becomes more complex the more arguments involved. (wish I came up with a =
better example now.).</div><div><br></div><div>Third. You cannot construct =
the temperature on the heap. But is as clear as the second.</div></div></bl=
ockquote><div><br>Watch me:<br><br><div style=3D"background-color: rgb(250,=
 250, 250); border-color: rgb(187, 187, 187); border-style: solid; border-w=
idth: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code class=3D=
"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">new</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">auto</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">(</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Temp=
erature</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">fromCelsius=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(-</span><=
span style=3D"color: #066;" class=3D"styled-by-prettify">273.15</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">));</span></div></code=
></div><br>Oh look, it&#39;s constructed on the heap now. The system alloca=
tes memory, passes it as the return value to `fromCelsius`, who calls the r=
ight constructor of `Temperature` in a prvalue that gets returned. No copyi=
ng. No moving.<br><br> Behold the wonders of guaranteed elision ;)</div><br=
></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/fec0c273-1b76-4ff7-a323-6d2e4a0d5233%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fec0c273-1b76-4ff7-a323-6d2e4a0d5233=
%40isocpp.org</a>.<br />

------=_Part_731_557467787.1484234634884--

------=_Part_730_1838115120.1484234634883--

.

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

On Thu, Jan 12, 2017 at 8:07 AM, <stefan.pantos@torstonetech.com> wrote:

> I find my self regularly creating static factory functions on classes to
> better describe how something is being constructed or to avoid having flags
> passed which may have some invalid permutations. Now some times this is
> because of poor design(Lazy/efficient) but it does make me wonder if
> constructers with names different to their class would be helpful.
>

I agree that the language needs named constructors, though this obviously
needs a paper and the syntax probably has to undergo bikeshedding. The
standard library keeps adding constructor tags to effectively get names,
and we often have to make wacky SFINAE hacks to make those constructor
overloads play nicely with other overloads. Named constructors more
directly solve the problem (in contrast to tag types) and also makes
overload sets smaller, making the code easier to reason about and to
specify correctly (indirectly, it might even slightly improve compile times
as well, but this is less of a concern). Guaranteed copy elision gets us
close to having an equivalent of named constructors because it allows for
named factory functions that return by value yet don't need the type to
even be movable. That only solves some of the issues, though, and in
practice, it still sometimes requires having (likely private) tagged
constructor overloads. Named constructors might also be able to have a
beneficial relationship with C++17 deduction guides.

I'd really like for someone to flesh out named constructors more in a paper
and come back with something more tangible/formal, covering all of the
details.

--
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/CANh8DEnKPGpj-0CQEiz_vtWivaKFC31tyJ9gfHL0KYqfCVrJTw%40mail.gmail.com.

--001a113a9a4ec367120545e78468
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 T=
hu, Jan 12, 2017 at 8:07 AM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:stefa=
n.pantos@torstonetech.com" target=3D"_blank">stefan.pantos@torstonetech.com=
</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
><div dir=3D"ltr">I find my self regularly creating static factory function=
s on classes to better describe how something is being constructed or to av=
oid having flags passed which may have some invalid permutations. Now some =
times this is because of poor design(Lazy/efficient) but it does make me wo=
nder if constructers with names different to their class would be helpful.<=
/div></blockquote><div><br></div><div>I agree that the language needs named=
 constructors, though this obviously needs a paper and the syntax probably =
has to undergo bikeshedding. The standard library keeps adding constructor =
tags to effectively get names, and we often have to make wacky SFINAE hacks=
 to make those constructor overloads play nicely with other overloads. Name=
d constructors more directly solve the problem (in contrast to tag types) a=
nd also makes overload sets smaller, making the code easier to reason about=
 and to specify correctly (indirectly, it might even slightly improve compi=
le times as well, but this is less of a concern). Guaranteed copy elision g=
ets us close to having an equivalent of named constructors because it allow=
s for named factory functions that return by value yet don&#39;t need the t=
ype to even be movable. That only solves some of the issues, though, and in=
 practice, it still sometimes requires having (likely private) tagged const=
ructor overloads. Named constructors might also be able to have a beneficia=
l relationship with C++17 deduction guides.</div><div><br></div><div>I&#39;=
d really like for someone to flesh out named constructors more in a paper a=
nd come back with something more tangible/formal, covering all of the detai=
ls.</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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANh8DEnKPGpj-0CQEiz_vtWivaKFC31tyJ9g=
fHL0KYqfCVrJTw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEnKPGpj-0CQ=
Eiz_vtWivaKFC31tyJ9gfHL0KYqfCVrJTw%40mail.gmail.com</a>.<br />

--001a113a9a4ec367120545e78468--

.

------=_Part_704_1658765649.1484236923634
Content-Type: multipart/alternative;
 boundary="----=_Part_705_254924102.1484236923634"

------=_Part_705_254924102.1484236923634
Content-Type: text/plain; charset=UTF-8

On Thursday, January 12, 2017 at 10:39:12 AM UTC-5, Matt Calabrese wrote:
>
> On Thu, Jan 12, 2017 at 8:07 AM, <stefan...@torstonetech.com <javascript:>
> > wrote:
>
>> I find my self regularly creating static factory functions on classes to
>> better describe how something is being constructed or to avoid having flags
>> passed which may have some invalid permutations. Now some times this is
>> because of poor design(Lazy/efficient) but it does make me wonder if
>> constructers with names different to their class would be helpful.
>>
>
> I agree that the language needs named constructors, though this obviously
> needs a paper and the syntax probably has to undergo bikeshedding. The
> standard library keeps adding constructor tags to effectively get names,
> and we often have to make wacky SFINAE hacks to make those constructor
> overloads play nicely with other overloads. Named constructors more
> directly solve the problem (in contrast to tag types) and also makes
> overload sets smaller, making the code easier to reason about and to
> specify correctly (indirectly, it might even slightly improve compile times
> as well, but this is less of a concern). Guaranteed copy elision gets us
> close to having an equivalent of named constructors because it allows for
> named factory functions that return by value yet don't need the type to
> even be movable. That only solves some of the issues, though, and in
> practice, it still sometimes requires having (likely private) tagged
> constructor overloads. Named constructors might also be able to have a
> beneficial relationship with C++17 deduction guides.
>
> I'd really like for someone to flesh out named constructors more in a
> paper and come back with something more tangible/formal, covering all of
> the details.
>

One problem I have with named constructors (as opposed to just static
functions that return `T`) is that it doesn't solve the problem. The whole
point of named constructors is that you have to provide a name to call the
right function, yes?

Well, `T(...)` doesn't provide that name, so it can only call regular
constructors. List-initialization can only call regular constructors, since
it also has no name, just a type and parameters. Indirect initialization
(`emplace`, `in_place_t` constructors, `make/allocate_shared/unique`, etc)
can only call regular constructors for the same reason.

That's a *lot* of places where named constructors just aren't available to
you. A `vector<Temperature>` *must* use the tagged version if you want to
construct the object in-place. So those tagged versions have to be public.

Basically, the only code that can use named constructors is code that has
direct knowledge of the class it is working with. Which admittedly is a
decent amount of code. But the fact that you instantly lose this ability
when you're dealing with a container of `T` makes it clear that these named
constructors are not equal in power to regular ones.

As such, I don't see how named constructors as a language feature would be
any improvement over a static function that returns `T`.

--
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/d7f7eb99-6e33-448f-9eed-5acc3697369b%40isocpp.org.

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

<div dir=3D"ltr">On Thursday, January 12, 2017 at 10:39:12 AM UTC-5, Matt C=
alabrese 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><div class=3D"gmail_quote">On Thu, Jan 12, 2017 at 8:07 AM,  <span d=
ir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mai=
lto=3D"hMr8e0-QBgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javas=
cript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;retu=
rn true;">stefan...@torstonetech.<wbr>com</a>&gt;</span> wrote:<br><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"><div dir=3D"ltr">I find my self r=
egularly creating static factory functions on classes to better describe ho=
w something is being constructed or to avoid having flags passed which may =
have some invalid permutations. Now some times this is because of poor desi=
gn(Lazy/efficient) but it does make me wonder if constructers with names di=
fferent to their class would be helpful.</div></blockquote><div><br></div><=
div>I agree that the language needs named constructors, though this obvious=
ly needs a paper and the syntax probably has to undergo bikeshedding. The s=
tandard library keeps adding constructor tags to effectively get names, and=
 we often have to make wacky SFINAE hacks to make those constructor overloa=
ds play nicely with other overloads. Named constructors more directly solve=
 the problem (in contrast to tag types) and also makes overload sets smalle=
r, making the code easier to reason about and to specify correctly (indirec=
tly, it might even slightly improve compile times as well, but this is less=
 of a concern). Guaranteed copy elision gets us close to having an equivale=
nt of named constructors because it allows for named factory functions that=
 return by value yet don&#39;t need the type to even be movable. That only =
solves some of the issues, though, and in practice, it still sometimes requ=
ires having (likely private) tagged constructor overloads. Named constructo=
rs might also be able to have a beneficial relationship with C++17 deductio=
n guides.</div><div><br></div><div>I&#39;d really like for someone to flesh=
 out named constructors more in a paper and come back with something more t=
angible/formal, covering all of the details.</div></div></div></div></block=
quote><div><br>One problem I have with named constructors (as opposed to ju=
st static=20
functions that return `T`) is that it doesn&#39;t solve the problem. The wh=
ole point of named constructors is that you have to provide a name to call =
the right function, yes?<br><br>Well, `T(...)` doesn&#39;t provide that nam=
e, so it can only call regular constructors. List-initialization can only c=
all regular constructors, since it also has no name, just a type and parame=
ters. Indirect initialization (`emplace`, `in_place_t` constructors, `make/=
allocate_shared/unique`, etc) can only call regular constructors for the sa=
me reason.<br><br>That&#39;s a <i>lot</i> of places where named constructor=
s just aren&#39;t available to you. A `vector&lt;Temperature&gt;` <i>must</=
i> use the tagged version if you want to construct the object in-place. So =
those tagged versions have to be public.<br><br>Basically, the only code th=
at can use named constructors is code that has direct knowledge of the clas=
s it is working with. Which admittedly is a decent amount of code. But the =
fact that you instantly lose this ability when you&#39;re dealing with a co=
ntainer of `T` makes it clear that these named constructors are not equal i=
n power to regular ones.<br><br>As such, I don&#39;t see how named construc=
tors as a language feature would be any improvement over a static function =
that returns `T`.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d7f7eb99-6e33-448f-9eed-5acc3697369b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d7f7eb99-6e33-448f-9eed-5acc3697369b=
%40isocpp.org</a>.<br />

------=_Part_705_254924102.1484236923634--

------=_Part_704_1658765649.1484236923634--

.

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

On Thu, Jan 12, 2017 at 11:02 AM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Thursday, January 12, 2017 at 10:39:12 AM UTC-5, Matt Calabrese wrote:
>>
>> On Thu, Jan 12, 2017 at 8:07 AM, <stefan...@torstonetech.com> wrote:
>>
>>> I find my self regularly creating static factory functions on classes to
>>> better describe how something is being constructed or to avoid having flags
>>> passed which may have some invalid permutations. Now some times this is
>>> because of poor design(Lazy/efficient) but it does make me wonder if
>>> constructers with names different to their class would be helpful.
>>>
>>
>> I agree that the language needs named constructors, though this obviously
>> needs a paper and the syntax probably has to undergo bikeshedding. The
>> standard library keeps adding constructor tags to effectively get names,
>> and we often have to make wacky SFINAE hacks to make those constructor
>> overloads play nicely with other overloads. Named constructors more
>> directly solve the problem (in contrast to tag types) and also makes
>> overload sets smaller, making the code easier to reason about and to
>> specify correctly (indirectly, it might even slightly improve compile times
>> as well, but this is less of a concern). Guaranteed copy elision gets us
>> close to having an equivalent of named constructors because it allows for
>> named factory functions that return by value yet don't need the type to
>> even be movable. That only solves some of the issues, though, and in
>> practice, it still sometimes requires having (likely private) tagged
>> constructor overloads. Named constructors might also be able to have a
>> beneficial relationship with C++17 deduction guides.
>>
>> I'd really like for someone to flesh out named constructors more in a
>> paper and come back with something more tangible/formal, covering all of
>> the details.
>>
>
> One problem I have with named constructors (as opposed to just static
> functions that return `T`) is that it doesn't solve the problem. The whole
> point of named constructors is that you have to provide a name to call the
> right function, yes?
>
> Well, `T(...)` doesn't provide that name, so it can only call regular
> constructors.
>

The reason I want the idea fleshed out is because there ideally would be
syntax for the name there.


> List-initialization can only call regular constructors, since it also has
> no name, just a type and parameters. Indirect initialization (`emplace`,
> `in_place_t` constructors, `make/allocate_shared/unique`, etc) can only
> call regular constructors for the same reason.
>

If the change were made without considering library, then I agree, but I
don't think that's a roadblock. The addition of named constructors would
likely have implications on how we design new/update existing library
facilities and there's no reason to believe that we couldn't adjust
appropriately.

Here's one example of what I mean -- previously in these forums I've
described that it would have been nice to have had something more akin to a
conceptified version of boost's in_place facilities rather than or in
addition to what we do today for emplacement. One of the reasons I say this
is because if done correctly, users could, for example, perform emplacement
via the result of a function call. The benefit of this particular approach,
especially with respect to *guaranteed* copy/move elision of C++17, is that
it allows for zero copies/moves even if you are constructing via a named
function with no directly corresponding constructor. Short of that kind of
abstraction, you could certainly imagine an "emplace_with_result" that
takes an Invocable and a set of arguments, where it constructs in-place
with the result of the function call. With that kind of facility, also
consider the possibility of being able to take the address of a named
constructor (why not? think of the constructor sort of like static function
that returns the constructed object). Then, all you'd have to do is pass
that in as the Invocable, followed by your desired arguments. Now you can
emplace with a named constructor. Regarding named constructors that are
*overloaded* or are templates, there are already proposals to allow easily
converting a set of overloads into a lambda that does the dispatching (and
it's a less controversial proposal for the closed-set of overloads of class
members). If we get something like that, then this solution even works
concisely when you have such a templated or overloaded named constructor.

With such an "emplace_with_result" kind of function, the benefits of named
constructors over a named function that simply returns T are the ability to
directly initialize bases and members. Without the ability to do that, your
named function needs to use some existing constructor (maybe private, and
likely still requiring the tag/SFINAE dance behind the scenes).

My point is, these are all solvable problems, they just have broader
implications if. It could end up being that these aren't changes that we
end up wanting to do, but without a paper that really formally explores the
options, it's hard to say.

--
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/CANh8DEm0yZnZ4zf1mp4Pn_c%3DpkgJ%3DW71Nz3Kugd8th3wVcUzsg%40mail.gmail.com.

--001a113dcb065454ab0545e86d87
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 T=
hu, Jan 12, 2017 at 11:02 AM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"=
mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Thursday=
, January 12, 2017 at 10:39:12 AM UTC-5, Matt Calabrese wrote:<span class=
=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div cl=
ass=3D"gmail_quote">On Thu, Jan 12, 2017 at 8:07 AM,  <span dir=3D"ltr">&lt=
;<a rel=3D"nofollow">stefan...@torstonetech.com</a>&gt;</span> wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">I find my =
self regularly creating static factory functions on classes to better descr=
ibe how something is being constructed or to avoid having flags passed whic=
h may have some invalid permutations. Now some times this is because of poo=
r design(Lazy/efficient) but it does make me wonder if constructers with na=
mes different to their class would be helpful.</div></blockquote><div><br><=
/div><div>I agree that the language needs named constructors, though this o=
bviously needs a paper and the syntax probably has to undergo bikeshedding.=
 The standard library keeps adding constructor tags to effectively get name=
s, and we often have to make wacky SFINAE hacks to make those constructor o=
verloads play nicely with other overloads. Named constructors more directly=
 solve the problem (in contrast to tag types) and also makes overload sets =
smaller, making the code easier to reason about and to specify correctly (i=
ndirectly, it might even slightly improve compile times as well, but this i=
s less of a concern). Guaranteed copy elision gets us close to having an eq=
uivalent of named constructors because it allows for named factory function=
s that return by value yet don&#39;t need the type to even be movable. That=
 only solves some of the issues, though, and in practice, it still sometime=
s requires having (likely private) tagged constructor overloads. Named cons=
tructors might also be able to have a beneficial relationship with C++17 de=
duction guides.</div><div><br></div><div>I&#39;d really like for someone to=
 flesh out named constructors more in a paper and come back with something =
more tangible/formal, covering all of the details.</div></div></div></div><=
/blockquote></span><div><br>One problem I have with named constructors (as =
opposed to just static=20
functions that return `T`) is that it doesn&#39;t solve the problem. The wh=
ole point of named constructors is that you have to provide a name to call =
the right function, yes?<br><br>Well, `T(...)` doesn&#39;t provide that nam=
e, so it can only call regular constructors.</div></div></blockquote><div><=
br></div><div>The reason I want the idea fleshed out is because there ideal=
ly would be syntax for the name there.</div><div>=C2=A0</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"><div> List-initialization can only call r=
egular constructors, since it also has no name, just a type and parameters.=
 Indirect initialization (`emplace`, `in_place_t` constructors, `make/alloc=
ate_shared/unique`, etc) can only call regular constructors for the same re=
ason.<br></div></div></blockquote><div><br></div><div>If the change were ma=
de without considering library, then I agree, but I don&#39;t think that&#3=
9;s a roadblock. The addition of named constructors would likely have impli=
cations on how we design new/update existing library facilities and there&#=
39;s no reason to believe that we couldn&#39;t adjust appropriately.</div><=
div><br></div><div>Here&#39;s one example of what I mean -- previously in t=
hese forums I&#39;ve described that it would have been nice to have had som=
ething more akin to a conceptified version of boost&#39;s in_place faciliti=
es rather than or in addition to what we do today for emplacement. One of t=
he reasons I say this is because if done correctly, users could, for exampl=
e, perform emplacement via the result of a function call. The benefit of th=
is particular approach, especially with respect to *guaranteed* copy/move e=
lision of C++17, is that it allows for zero copies/moves even if you are co=
nstructing via a named function with no directly corresponding constructor.=
 Short of that kind of abstraction, you could certainly imagine an &quot;em=
place_with_result&quot; that takes an Invocable and a set of arguments, whe=
re it constructs in-place with the result of the function call. With that k=
ind of facility, also consider the possibility of being able to take the ad=
dress of a named constructor (why not? think of the constructor sort of lik=
e static function that returns the constructed object). Then, all you&#39;d=
 have to do is pass that in as the Invocable, followed by your desired argu=
ments. Now you can emplace with a named constructor. Regarding named constr=
uctors that are *overloaded* or are templates, there are already proposals =
to allow easily converting a set of overloads into a lambda that does the d=
ispatching (and it&#39;s a less controversial proposal for the closed-set o=
f overloads of class members). If we get something like that, then this sol=
ution even works concisely when you have such a templated or overloaded nam=
ed constructor.</div><div><br></div><div>With such an &quot;emplace_with_re=
sult&quot; kind of function, the benefits of named constructors over a name=
d function that simply returns T are the ability to directly initialize bas=
es and members. Without the ability to do that, your named function needs t=
o use some existing constructor (maybe private, and likely still requiring =
the tag/SFINAE dance behind the scenes).</div><div><br></div><div>My point =
is, these are all solvable problems, they just have broader implications if=
.. It could end up being that these aren&#39;t changes that we end up wantin=
g to do, but without a paper that really formally explores the options, it&=
#39;s hard to say.</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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANh8DEm0yZnZ4zf1mp4Pn_c%3DpkgJ%3DW71=
Nz3Kugd8th3wVcUzsg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEm0yZnZ=
4zf1mp4Pn_c%3DpkgJ%3DW71Nz3Kugd8th3wVcUzsg%40mail.gmail.com</a>.<br />

--001a113dcb065454ab0545e86d87--

.

------=_Part_834_1810648518.1484240731356
Content-Type: multipart/alternative;
 boundary="----=_Part_835_1513807751.1484240731357"

------=_Part_835_1513807751.1484240731357
Content-Type: text/plain; charset=UTF-8



On Thursday, January 12, 2017 at 11:44:14 AM UTC-5, Matt Calabrese wrote:
>
> On Thu, Jan 12, 2017 at 11:02 AM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> On Thursday, January 12, 2017 at 10:39:12 AM UTC-5, Matt Calabrese wrote:
>>>
>>> On Thu, Jan 12, 2017 at 8:07 AM, <stefan...@torstonetech.com> wrote:
>>>
>>>> I find my self regularly creating static factory functions on classes
>>>> to better describe how something is being constructed or to avoid having
>>>> flags passed which may have some invalid permutations. Now some times this
>>>> is because of poor design(Lazy/efficient) but it does make me wonder if
>>>> constructers with names different to their class would be helpful.
>>>>
>>>
>>> I agree that the language needs named constructors, though this
>>> obviously needs a paper and the syntax probably has to undergo
>>> bikeshedding. The standard library keeps adding constructor tags to
>>> effectively get names, and we often have to make wacky SFINAE hacks to make
>>> those constructor overloads play nicely with other overloads. Named
>>> constructors more directly solve the problem (in contrast to tag types) and
>>> also makes overload sets smaller, making the code easier to reason about
>>> and to specify correctly (indirectly, it might even slightly improve
>>> compile times as well, but this is less of a concern). Guaranteed copy
>>> elision gets us close to having an equivalent of named constructors because
>>> it allows for named factory functions that return by value yet don't need
>>> the type to even be movable. That only solves some of the issues, though,
>>> and in practice, it still sometimes requires having (likely private) tagged
>>> constructor overloads. Named constructors might also be able to have a
>>> beneficial relationship with C++17 deduction guides.
>>>
>>> I'd really like for someone to flesh out named constructors more in a
>>> paper and come back with something more tangible/formal, covering all of
>>> the details.
>>>
>>
>> One problem I have with named constructors (as opposed to just static
>> functions that return `T`) is that it doesn't solve the problem. The whole
>> point of named constructors is that you have to provide a name to call the
>> right function, yes?
>>
>> Well, `T(...)` doesn't provide that name, so it can only call regular
>> constructors.
>>
>
> The reason I want the idea fleshed out is because there ideally would be
> syntax for the name there.
>
>
>> List-initialization can only call regular constructors, since it also has
>> no name, just a type and parameters. Indirect initialization (`emplace`,
>> `in_place_t` constructors, `make/allocate_shared/unique`, etc) can only
>> call regular constructors for the same reason.
>>
>
> If the change were made without considering library, then I agree, but I
> don't think that's a roadblock. The addition of named constructors would
> likely have implications on how we design new/update existing library
> facilities and there's no reason to believe that we couldn't adjust
> appropriately.
>
> Here's one example of what I mean -- previously in these forums I've
> described that it would have been nice to have had something more akin to a
> conceptified version of boost's in_place facilities rather than or in
> addition to what we do today for emplacement. One of the reasons I say this
> is because if done correctly, users could, for example, perform emplacement
> via the result of a function call. The benefit of this particular approach,
> especially with respect to *guaranteed* copy/move elision of C++17, is that
> it allows for zero copies/moves even if you are constructing via a named
> function with no directly corresponding constructor. Short of that kind of
> abstraction, you could certainly imagine an "emplace_with_result" that
> takes an Invocable and a set of arguments, where it constructs in-place
> with the result of the function call. With that kind of facility, also
> consider the possibility of being able to take the address of a named
> constructor (why not? think of the constructor sort of like static function
> that returns the constructed object). Then, all you'd have to do is pass
> that in as the Invocable, followed by your desired arguments. Now you can
> emplace with a named constructor. Regarding named constructors that are
> *overloaded* or are templates, there are already proposals to allow easily
> converting a set of overloads into a lambda that does the dispatching (and
> it's a less controversial proposal for the closed-set of overloads of class
> members). If we get something like that, then this solution even works
> concisely when you have such a templated or overloaded named constructor.
>
> With such an "emplace_with_result" kind of function, the benefits of named
> constructors over a named function that simply returns T are the ability to
> directly initialize bases and members. Without the ability to do that, your
> named function needs to use some existing constructor (maybe private, and
> likely still requiring the tag/SFINAE dance behind the scenes).
>
> My point is, these are all solvable problems, they just have broader
> implications if. It could end up being that these aren't changes that we
> end up wanting to do, but without a paper that really formally explores the
> options, it's hard to say.
>

So let's say we go through this effort. We add a lot of functions to the
standard library. We add yet another language feature: lifting lambdas
(which I'm all in favor of, regardless of this stuff). And probably some
lip-service to list-initialization. Whatever.

And after all of that work, we get... the ability to do this:

auto t = Temperature::FromKelvin(...);

rather than this:

auto t = Temperature::FromKelvin(...);

Or the ability to do this:

v.emplace_back_with_result([]Temperature::FromKelvin, ...);

Rather than this:

v.emplace_back(..., Temperature::FromKelvin);

I'm really trying to understand how the named constructor version is an
improvement, but it's just not coming to me. From the perspective of the
person calling the code, named constructors don't seem to be an improvement
over static members and tags.

You keep talking about "the tag/SFINAE dance" as though it were some
complex and nightmarish code. But in most cases I've seen, it's pretty
simple stuff. The result on the user end side is quite readable. I wouldn't
even bother with a type for the case of `Temperature`; an enum is perfectly
acceptable.

And whatever SFINAE gymnastics you have to do will become much more
reasonable once we get concepts, right?

--
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/fb643c63-11ee-4d15-a577-1321362ceb99%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Thursday, January 12, 2017 at 11:44:14 AM UTC-5=
, Matt Calabrese wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr"><div><div class=3D"gmail_quote">On Thu, Jan 12, 2017 at 11:02 AM,=
 Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank=
" gdf-obfuscated-mailto=3D"63o_6duTBgAJ" rel=3D"nofollow" onmousedown=3D"th=
is.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;j=
avascript:&#39;;return true;">jmck...@gmail.com</a>&gt;</span> wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr">On Thursday, January 12, 2017=
 at 10:39:12 AM UTC-5, Matt Calabrese wrote:<span><blockquote class=3D"gmai=
l_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote">On Thu, Jan=
 12, 2017 at 8:07 AM,  <span dir=3D"ltr">&lt;<a rel=3D"nofollow">stefan...@=
torstonetech.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex"><div dir=3D"ltr">I find my self regularly creating static =
factory functions on classes to better describe how something is being cons=
tructed or to avoid having flags passed which may have some invalid permuta=
tions. Now some times this is because of poor design(Lazy/efficient) but it=
 does make me wonder if constructers with names different to their class wo=
uld be helpful.</div></blockquote><div><br></div><div>I agree that the lang=
uage needs named constructors, though this obviously needs a paper and the =
syntax probably has to undergo bikeshedding. The standard library keeps add=
ing constructor tags to effectively get names, and we often have to make wa=
cky SFINAE hacks to make those constructor overloads play nicely with other=
 overloads. Named constructors more directly solve the problem (in contrast=
 to tag types) and also makes overload sets smaller, making the code easier=
 to reason about and to specify correctly (indirectly, it might even slight=
ly improve compile times as well, but this is less of a concern). Guarantee=
d copy elision gets us close to having an equivalent of named constructors =
because it allows for named factory functions that return by value yet don&=
#39;t need the type to even be movable. That only solves some of the issues=
, though, and in practice, it still sometimes requires having (likely priva=
te) tagged constructor overloads. Named constructors might also be able to =
have a beneficial relationship with C++17 deduction guides.</div><div><br><=
/div><div>I&#39;d really like for someone to flesh out named constructors m=
ore in a paper and come back with something more tangible/formal, covering =
all of the details.</div></div></div></div></blockquote></span><div><br>One=
 problem I have with named constructors (as opposed to just static=20
functions that return `T`) is that it doesn&#39;t solve the problem. The wh=
ole point of named constructors is that you have to provide a name to call =
the right function, yes?<br><br>Well, `T(...)` doesn&#39;t provide that nam=
e, so it can only call regular constructors.</div></div></blockquote><div><=
br></div><div>The reason I want the idea fleshed out is because there ideal=
ly would be syntax for the name there.</div><div>=C2=A0</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"><div> List-initialization can only call r=
egular constructors, since it also has no name, just a type and parameters.=
 Indirect initialization (`emplace`, `in_place_t` constructors, `make/alloc=
ate_shared/unique`, etc) can only call regular constructors for the same re=
ason.<br></div></div></blockquote><div><br></div><div>If the change were ma=
de without considering library, then I agree, but I don&#39;t think that&#3=
9;s a roadblock. The addition of named constructors would likely have impli=
cations on how we design new/update existing library facilities and there&#=
39;s no reason to believe that we couldn&#39;t adjust appropriately.</div><=
div><br></div><div>Here&#39;s one example of what I mean -- previously in t=
hese forums I&#39;ve described that it would have been nice to have had som=
ething more akin to a conceptified version of boost&#39;s in_place faciliti=
es rather than or in addition to what we do today for emplacement. One of t=
he reasons I say this is because if done correctly, users could, for exampl=
e, perform emplacement via the result of a function call. The benefit of th=
is particular approach, especially with respect to *guaranteed* copy/move e=
lision of C++17, is that it allows for zero copies/moves even if you are co=
nstructing via a named function with no directly corresponding constructor.=
 Short of that kind of abstraction, you could certainly imagine an &quot;em=
place_with_result&quot; that takes an Invocable and a set of arguments, whe=
re it constructs in-place with the result of the function call. With that k=
ind of facility, also consider the possibility of being able to take the ad=
dress of a named constructor (why not? think of the constructor sort of lik=
e static function that returns the constructed object). Then, all you&#39;d=
 have to do is pass that in as the Invocable, followed by your desired argu=
ments. Now you can emplace with a named constructor. Regarding named constr=
uctors that are *overloaded* or are templates, there are already proposals =
to allow easily converting a set of overloads into a lambda that does the d=
ispatching (and it&#39;s a less controversial proposal for the closed-set o=
f overloads of class members). If we get something like that, then this sol=
ution even works concisely when you have such a templated or overloaded nam=
ed constructor.</div><div><br></div><div>With such an &quot;emplace_with_re=
sult&quot; kind of function, the benefits of named constructors over a name=
d function that simply returns T are the ability to directly initialize bas=
es and members. Without the ability to do that, your named function needs t=
o use some existing constructor (maybe private, and likely still requiring =
the tag/SFINAE dance behind the scenes).</div><div><br></div><div>My point =
is, these are all solvable problems, they just have broader implications if=
.. It could end up being that these aren&#39;t changes that we end up wantin=
g to do, but without a paper that really formally explores the options, it&=
#39;s hard to say.</div></div></div></div></blockquote><div><br>So let&#39;=
s say we go through this effort. We add a lot of functions to the standard =
library. We add yet another language feature: lifting lambdas (which I&#39;=
m all in favor of, regardless of this stuff). And probably some lip-service=
 to list-initialization. Whatever.<br><br>And after all of that work, we ge=
t... the ability to do this:<br><br><div style=3D"background-color: rgb(250=
, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; border-=
width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;"=
 class=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> t </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify"=
>Temperature</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">::</span><span style=3D"color: #606;" class=3D"styled-by-prettify">FromKe=
lvin</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(...);=
</span></div></code></div><br>rather than this:<br><br><div style=3D"backgr=
ound-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-st=
yle: solid; border-width: 1px; overflow-wrap: break-word;" class=3D"prettyp=
rint"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=
=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> t </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"st=
yled-by-prettify">Temperature</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">::</span><span style=3D"color: #606;" class=3D"styled-by=
-prettify">FromKelvin</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">(...);</span></div></code></div><br>Or the ability to do this:<b=
r><br><div style=3D"background-color: rgb(250, 250, 250); border-color: rgb=
(187, 187, 187); border-style: solid; border-width: 1px; overflow-wrap: bre=
ak-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"s=
ubprettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">v<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">emplace_back_with_re=
sult</span><span style=3D"color: #660;" class=3D"styled-by-prettify">([]</s=
pan><span style=3D"color: #606;" class=3D"styled-by-prettify">Temperature</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><sp=
an style=3D"color: #606;" class=3D"styled-by-prettify">FromKelvin</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=
: #660;" class=3D"styled-by-prettify">...);</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span></div></code></div><br>Rather t=
han this:<br><br><div style=3D"background-color: rgb(250, 250, 250); border=
-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; overflo=
w-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div=
 class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">v</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
..</span><span style=3D"color: #000;" class=3D"styled-by-prettify">emplace_b=
ack</span><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: #606;" class=3D"styled-by-prettify">Temperature</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">FromKelvin</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">);</span></div></code></div>=
<br>I&#39;m really trying to understand how the named constructor version i=
s an improvement, but it&#39;s just not coming to me. From the perspective =
of the person calling the code, named constructors don&#39;t seem to be an =
improvement over static members and tags.<br><br>You keep talking about &qu=
ot;the tag/SFINAE dance&quot; as though it were some complex and nightmaris=
h code. But in most cases I&#39;ve seen, it&#39;s pretty simple stuff. The =
result on the user end side is quite readable. I wouldn&#39;t even bother w=
ith a type for the case of `Temperature`; an enum is perfectly acceptable.<=
br><br>And whatever SFINAE gymnastics you have to do will become much more =
reasonable once we get concepts, right?<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/fb643c63-11ee-4d15-a577-1321362ceb99%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fb643c63-11ee-4d15-a577-1321362ceb99=
%40isocpp.org</a>.<br />

------=_Part_835_1513807751.1484240731357--

------=_Part_834_1810648518.1484240731356--

.

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

On Thu, Jan 12, 2017 at 12:05 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> So let's say we go through this effort. We add a lot of functions to the
> standard library. We add yet another language feature: lifting lambdas
> (which I'm all in favor of, regardless of this stuff). And probably some
> lip-service to list-initialization. Whatever.
>
> And after all of that work, we get... the ability to do this:
>
> auto t = Temperature::FromKelvin(...);
>
> rather than this:
>
> auto t = Temperature::FromKelvin(...);
>
> Or the ability to do this:
>
> v.emplace_back_with_result([]Temperature::FromKelvin, ...);
>
> Rather than this:
>
> v.emplace_back(..., Temperature::FromKelvin);
>
> I'm really trying to understand how the named constructor version is an
> improvement, but it's just not coming to me. From the perspective of the
> person calling the code, named constructors don't seem to be an improvement
> over static members and tags.
>

The temperature class presented here isn't a particularly great example for
reasons you've mentioned. The benefit comes primarily from development of
the constructor/creation functions and from minimizing the amount of
confusing overloads in an overload set. Forget about constructors for a
moment -- imagine we lived in a hellish world where all functions were
required to be called "foo" (perhaps almost as hellish as a world where
everyone programmed in Java). In order to disambiguate what we were doing,
we'd have to do things like make silly tag types for certain cases and
write each overload in a way that was aware of all of the other overloads
in order to make sure we don't have unintended ambiguities or incorrect
matches. Obviously this is not the world of C++... except when in the
limited scope of a type's constructors. Though we have fewer overloads to
think about, it's the same kind of issue only on a smaller scale. We've
gotten used to our tricks enough to get by, but they're still pretty weird
tricks and are definitely not helping those who are new to the language.
With respect to the standard library, these tricks tend to snowball as
well, especially as we add more constructor overloads in each standard --
consider the evolution that the std::tuple constructors have gone through (
http://en.cppreference.com/w/cpp/utility/tuple/tuple ).

On Thu, Jan 12, 2017 at 12:05 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> You keep talking about "the tag/SFINAE dance" as though it were some
> complex and nightmarish code. But in most cases I've seen, it's pretty
> simple stuff. The result on the user end side is quite readable.
>

Depending on how it's taught, the user side of the problem isn't nearly as
difficult as getting the implementation side correct, but that said, a
nontrivial amount of time and analysis needs to be spent to specify the
constraints properly for many types that have constructors like these. For
user-developed types, I'm sure that either a similar amount of time is
spent, or (worse) constraints are incorrect. If you don't buy the
trickiness, again, check out all of the gross constraints that need to
exist for tuple ( http://en.cppreference.com/w/cpp/utility/tuple/tuple ).
It's tricky and I don't have much faith in myself nor even in the committee
as a whole to always get things exactly "correct" 100% of the time. That's
scary to me, especially when I think of everyday users who might attempt
analogous things.

In a similar respect, there are a couple of ways that users, as opposed to
the committee and implementors, are impacted by this, even if they
themselves only *use* such constructors. For one, trying to figure out what
on earth the tuple constructors do and which overloads would be picked by
simply reading the documentation of those constructors is sometimes
difficult for moderately experienced developers, let alone those newer to
the language. I find this particularly embarrassing because a tuple isn't
exactly a complicated notion to understand. As well, because it can be
tricky to get these constraints correct without ambiguities and (worse)
without unintended overloads being a better match, we may even specify
these constraints incorrectly, in which case the user can be faced with
some wacky compiler errors or unexpected run-time behavior.

On Thu, Jan 12, 2017 at 12:05 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
> And whatever SFINAE gymnastics you have to do will become much more
> reasonable once we get concepts, right?
>

I suppose it depends on what you mean by "reasonable" there, but my view is
not really. By that I mean for these *particular* kinds of cases, the code
would look nicer, but the same kinds of constraints will need to be there.
In this situation, the SFINAE gymnastics would be replaced by requires
clauses, but we'd still need the same amount and kinds of constraints. What
we might get in this case with concepts is the potential for better error
messages when a user does something wrong, which is at least something, but
the implementation and usage complexity remains mostly unchanged. Benefits
of concepts are much greater for constraining and specializing generic code
rather than for disambiguating tagged constructors and non-tagged overloads.

Anyway, again, I'm not absolutely convinced that named constructors are the
best option, but I do think that they are an option that is very worthy of
exploration in a paper. I think that there is a reasonable chance that we
could get to a more sane place than where we are right now, but that's
still somewhat of a guess without a deeper analysis.

--
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/CANh8DEknW_EUP%3D0CNCHJ-fofhX62WOGNVYjBTi8F6hS69V%3DmJQ%40mail.gmail.com.

--94eb2c04fa8289f61e0545ea1bae
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 T=
hu, Jan 12, 2017 at 12:05 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"=
mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div>So let&#39;s say we go through this effort. We add a lot of f=
unctions to the standard library. We add yet another language feature: lift=
ing lambdas (which I&#39;m all in favor of, regardless of this stuff). And =
probably some lip-service to list-initialization. Whatever.<br><br>And afte=
r all of that work, we get... the ability to do this:<br><br><div style=3D"=
background-color:rgb(250,250,250);border-color:rgb(187,187,187);border-styl=
e:solid;border-width:1px" class=3D"gmail-m_3806399670965190470prettyprint">=
<code class=3D"gmail-m_3806399670965190470prettyprint"><div class=3D"gmail-=
m_3806399670965190470subprettyprint"><span style=3D"color:rgb(0,0,136)" cla=
ss=3D"gmail-m_3806399670965190470styled-by-prettify">auto</span><span style=
=3D"color:rgb(0,0,0)" class=3D"gmail-m_3806399670965190470styled-by-prettif=
y"> t </span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_38063996=
70965190470styled-by-prettify">=3D</span><span style=3D"color:rgb(0,0,0)" c=
lass=3D"gmail-m_3806399670965190470styled-by-prettify"> </span><span style=
=3D"color:rgb(102,0,102)" class=3D"gmail-m_3806399670965190470styled-by-pre=
ttify">Temperature</span><span style=3D"color:rgb(102,102,0)" class=3D"gmai=
l-m_3806399670965190470styled-by-prettify">::</span><span style=3D"color:rg=
b(102,0,102)" class=3D"gmail-m_3806399670965190470styled-by-prettify">FromK=
elvin</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_380639967=
0965190470styled-by-prettify">(...);</span></div></code></div><br>rather th=
an this:<br><br><div style=3D"background-color:rgb(250,250,250);border-colo=
r:rgb(187,187,187);border-style:solid;border-width:1px" class=3D"gmail-m_38=
06399670965190470prettyprint"><code class=3D"gmail-m_3806399670965190470pre=
ttyprint"><div class=3D"gmail-m_3806399670965190470subprettyprint"><span st=
yle=3D"color:rgb(0,0,136)" class=3D"gmail-m_3806399670965190470styled-by-pr=
ettify">auto</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_380639=
9670965190470styled-by-prettify"> t </span><span style=3D"color:rgb(102,102=
,0)" class=3D"gmail-m_3806399670965190470styled-by-prettify">=3D</span><spa=
n style=3D"color:rgb(0,0,0)" class=3D"gmail-m_3806399670965190470styled-by-=
prettify"> </span><span style=3D"color:rgb(102,0,102)" class=3D"gmail-m_380=
6399670965190470styled-by-prettify">Temperature</span><span style=3D"color:=
rgb(102,102,0)" class=3D"gmail-m_3806399670965190470styled-by-prettify">::<=
/span><span style=3D"color:rgb(102,0,102)" class=3D"gmail-m_380639967096519=
0470styled-by-prettify">FromKelvin</span><span style=3D"color:rgb(102,102,0=
)" class=3D"gmail-m_3806399670965190470styled-by-prettify">(...);</span></d=
iv></code></div><br>Or the ability to do this:<br><br><div style=3D"backgro=
und-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid=
;border-width:1px" class=3D"gmail-m_3806399670965190470prettyprint"><code c=
lass=3D"gmail-m_3806399670965190470prettyprint"><div class=3D"gmail-m_38063=
99670965190470subprettyprint"><span style=3D"color:rgb(0,0,0)" class=3D"gma=
il-m_3806399670965190470styled-by-prettify">v</span><span style=3D"color:rg=
b(102,102,0)" class=3D"gmail-m_3806399670965190470styled-by-prettify">.</sp=
an><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_3806399670965190470sty=
led-by-prettify">emplace_back_with_result</span><span style=3D"color:rgb(10=
2,102,0)" class=3D"gmail-m_3806399670965190470styled-by-prettify">([]</span=
><span style=3D"color:rgb(102,0,102)" class=3D"gmail-m_3806399670965190470s=
tyled-by-prettify">T<wbr>emperature</span><span style=3D"color:rgb(102,102,=
0)" class=3D"gmail-m_3806399670965190470styled-by-prettify">::</span><span =
style=3D"color:rgb(102,0,102)" class=3D"gmail-m_3806399670965190470styled-b=
y-prettify">FromKelvin</span><span style=3D"color:rgb(102,102,0)" class=3D"=
gmail-m_3806399670965190470styled-by-prettify">,</span><span style=3D"color=
:rgb(0,0,0)" class=3D"gmail-m_3806399670965190470styled-by-prettify"> </spa=
n><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_3806399670965190470=
styled-by-prettify">...);</span><span style=3D"color:rgb(0,0,0)" class=3D"g=
mail-m_3806399670965190470styled-by-prettify"><br></span></div></code></div=
><br>Rather than this:<br><br><div style=3D"background-color:rgb(250,250,25=
0);border-color:rgb(187,187,187);border-style:solid;border-width:1px" class=
=3D"gmail-m_3806399670965190470prettyprint"><code class=3D"gmail-m_38063996=
70965190470prettyprint"><div class=3D"gmail-m_3806399670965190470subprettyp=
rint"><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_3806399670965190470=
styled-by-prettify">v</span><span style=3D"color:rgb(102,102,0)" class=3D"g=
mail-m_3806399670965190470styled-by-prettify">.</span><span style=3D"color:=
rgb(0,0,0)" class=3D"gmail-m_3806399670965190470styled-by-prettify">emplace=
_back</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_380639967=
0965190470styled-by-prettify">(...,</span><span style=3D"color:rgb(0,0,0)" =
class=3D"gmail-m_3806399670965190470styled-by-prettify"> </span><span style=
=3D"color:rgb(102,0,102)" class=3D"gmail-m_3806399670965190470styled-by-pre=
ttify">Temperature</span><span style=3D"color:rgb(102,102,0)" class=3D"gmai=
l-m_3806399670965190470styled-by-prettify">::</span><span style=3D"color:rg=
b(102,0,102)" class=3D"gmail-m_3806399670965190470styled-by-prettify">FromK=
elvin</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_380639967=
0965190470styled-by-prettify">);</span></div></code></div><br>I&#39;m reall=
y trying to understand how the named constructor version is an improvement,=
 but it&#39;s just not coming to me. From the perspective of the person cal=
ling the code, named constructors don&#39;t seem to be an improvement over =
static members and tags.<br></div></div></blockquote><div><br></div><div>Th=
e temperature class presented here isn&#39;t a particularly great example f=
or reasons you&#39;ve mentioned. The benefit comes primarily from developme=
nt of the constructor/creation functions and from minimizing the amount of =
confusing overloads in an overload set. Forget about constructors for a mom=
ent -- imagine we lived in a hellish world where all functions were require=
d to be called &quot;foo&quot; (perhaps almost as hellish as a world where =
everyone programmed in Java). In order to disambiguate what we were doing, =
we&#39;d have to do things like make silly tag types for certain cases and =
write each overload in a way that was aware of all of the other overloads i=
n order to make sure we don&#39;t have unintended ambiguities or incorrect =
matches. Obviously this is not the world of C++... except when in the limit=
ed scope of a type&#39;s constructors. Though we have fewer overloads to th=
ink about, it&#39;s the same kind of issue only on a smaller scale. We&#39;=
ve gotten used to our tricks enough to get by, but they&#39;re still pretty=
 weird tricks and are definitely not helping those who are new to the langu=
age. With respect to the standard library, these tricks tend to snowball as=
 well, especially as we add more constructor overloads in each standard -- =
consider the evolution that the std::tuple constructors have gone through (=
 <a href=3D"http://en.cppreference.com/w/cpp/utility/tuple/tuple">http://en=
..cppreference.com/w/cpp/utility/tuple/tuple</a> ).</div><div><br></div><div=
>On Thu, Jan 12, 2017 at 12:05 PM, Nicol Bolas=C2=A0<span dir=3D"ltr">&lt;<=
a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com=
</a>&gt;</span>=C2=A0wrote:</div><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"><div dir=3D"ltr"><div>You keep talking about &quot;the tag/SFINAE d=
ance&quot; as though it were some complex and nightmarish code. But in most=
 cases I&#39;ve seen, it&#39;s pretty simple stuff. The result on the user =
end side is quite readable.<br></div></div></blockquote><div><br></div><div=
>Depending on how it&#39;s taught, the user side of the problem isn&#39;t n=
early as difficult as getting the implementation side correct, but that sai=
d, a nontrivial amount of time and analysis needs to be spent to specify th=
e constraints properly for many types that have constructors like these. Fo=
r user-developed types, I&#39;m sure that either a similar amount of time i=
s spent, or (worse) constraints are incorrect. If you don&#39;t buy the tri=
ckiness, again, check out all of the gross constraints that need to exist f=
or tuple ( <a href=3D"http://en.cppreference.com/w/cpp/utility/tuple/tuple"=
>http://en.cppreference.com/w/cpp/utility/tuple/tuple</a> ). It&#39;s trick=
y and I don&#39;t have much faith in myself nor even in the committee as a =
whole to always get things exactly &quot;correct&quot; 100% of the time. Th=
at&#39;s scary to me, especially when I think of everyday users who might a=
ttempt analogous things.</div><div><br></div><div>In a similar respect, the=
re are a couple of ways that users, as opposed to the committee and impleme=
ntors, are impacted by this, even if they themselves only *use* such constr=
uctors. For one, trying to figure out what on earth the tuple constructors =
do and which overloads would be picked by simply reading the documentation =
of those constructors is sometimes difficult for moderately experienced dev=
elopers, let alone those newer to the language. I find this particularly em=
barrassing because a tuple isn&#39;t exactly a complicated notion to unders=
tand. As well, because it can be tricky to get these constraints correct wi=
thout ambiguities and (worse) without unintended overloads being a better m=
atch, we may even specify these constraints incorrectly, in which case the =
user can be faced with some wacky compiler errors or unexpected run-time be=
havior.</div><br class=3D"gmail-Apple-interchange-newline">On Thu, Jan 12, =
2017 at 12:05 PM, Nicol Bolas=C2=A0<span dir=3D"ltr">&lt;<a href=3D"mailto:=
jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</span>=
=C2=A0wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"l=
tr"><div>And whatever SFINAE gymnastics you have to do will become much mor=
e reasonable once we get concepts, right?</div></div></blockquote><div><br>=
</div><div>I suppose it depends on what you mean by &quot;reasonable&quot; =
there, but my view is not really. By that I mean for these *particular* kin=
ds of cases, the code would look nicer, but the same kinds of constraints w=
ill need to be there. In this situation, the SFINAE gymnastics would be rep=
laced by requires clauses, but we&#39;d still need the same amount and kind=
s of constraints. What we might get in this case with concepts is the poten=
tial for better error messages when a user does something wrong, which is a=
t least something, but the implementation and usage complexity remains most=
ly unchanged. Benefits of concepts are much greater for constraining and sp=
ecializing generic code rather than for disambiguating tagged constructors =
and non-tagged overloads.</div><div><br></div><div>Anyway, again, I&#39;m n=
ot absolutely convinced that named constructors are the best option, but I =
do think that they are an option that is very worthy of exploration in a pa=
per. I think that there is a reasonable chance that we could get to a more =
sane place than where we are right now, but that&#39;s still somewhat of a =
guess without a deeper analysis.</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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANh8DEknW_EUP%3D0CNCHJ-fofhX62WOGNVY=
jBTi8F6hS69V%3DmJQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEknW_EU=
P%3D0CNCHJ-fofhX62WOGNVYjBTi8F6hS69V%3DmJQ%40mail.gmail.com</a>.<br />

--94eb2c04fa8289f61e0545ea1bae--

.

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

It hadn't occurred to me about elision would likely happen and I wasn't
aware of 'Guaranteed Copy Elision' being in the standard.

In the world of 'almost always auto' the pattern auto x = T(blah); is quite
common and it works quite nicely with auto x = T::FromKelvin();

Just off the top of my head, I'm not suggesting this is a good idea(gut
feeling is that it isn't) but a named constructor could be an aliases to
the unnamed constructor if it is uniquely identified by its arguments,
explicit would in effect undo this. Temperature zero(0); and it would call
FromKelvin constructor. You could even give a default constructor have a
name making some things more explicit. optional<int>::null() for example,
ok nullopt is better.

This makes me think about enum classes. You have a class which had several
zero-argument constructors which all had different names.

class Colour
{
   public:
       constructor red();
       constructor green();
       constructor blue();

   private:
       int r, g, b;
};


Is there anything about them being constructors over static functions which
would be good?
Initialisation list, noexcept?

If people think it would be a worth while effort to write a proposal/paper
to further explore the possibilities, I wouldn't mind having a go. Is
anyone prepared to mentor me in such an endeavour? I don't have a massive
amount of free time but I would certainly like to have a go.

Hope this isn't too rambling.



On 12 January 2017 at 17:05, Nicol Bolas <jmckesson@gmail.com> wrote:

>
>
> On Thursday, January 12, 2017 at 11:44:14 AM UTC-5, Matt Calabrese wrote:
>>
>> On Thu, Jan 12, 2017 at 11:02 AM, Nicol Bolas <jmck...@gmail.com> wrote:
>>
>>> On Thursday, January 12, 2017 at 10:39:12 AM UTC-5, Matt Calabrese wrote:
>>>>
>>>> On Thu, Jan 12, 2017 at 8:07 AM, <stefan...@torstonetech.com> wrote:
>>>>
>>>>> I find my self regularly creating static factory functions on classes
>>>>> to better describe how something is being constructed or to avoid having
>>>>> flags passed which may have some invalid permutations. Now some times this
>>>>> is because of poor design(Lazy/efficient) but it does make me wonder if
>>>>> constructers with names different to their class would be helpful.
>>>>>
>>>>
>>>> I agree that the language needs named constructors, though this
>>>> obviously needs a paper and the syntax probably has to undergo
>>>> bikeshedding. The standard library keeps adding constructor tags to
>>>> effectively get names, and we often have to make wacky SFINAE hacks to make
>>>> those constructor overloads play nicely with other overloads. Named
>>>> constructors more directly solve the problem (in contrast to tag types) and
>>>> also makes overload sets smaller, making the code easier to reason about
>>>> and to specify correctly (indirectly, it might even slightly improve
>>>> compile times as well, but this is less of a concern). Guaranteed copy
>>>> elision gets us close to having an equivalent of named constructors because
>>>> it allows for named factory functions that return by value yet don't need
>>>> the type to even be movable. That only solves some of the issues, though,
>>>> and in practice, it still sometimes requires having (likely private) tagged
>>>> constructor overloads. Named constructors might also be able to have a
>>>> beneficial relationship with C++17 deduction guides.
>>>>
>>>> I'd really like for someone to flesh out named constructors more in a
>>>> paper and come back with something more tangible/formal, covering all of
>>>> the details.
>>>>
>>>
>>> One problem I have with named constructors (as opposed to just static
>>> functions that return `T`) is that it doesn't solve the problem. The whole
>>> point of named constructors is that you have to provide a name to call the
>>> right function, yes?
>>>
>>> Well, `T(...)` doesn't provide that name, so it can only call regular
>>> constructors.
>>>
>>
>> The reason I want the idea fleshed out is because there ideally would be
>> syntax for the name there.
>>
>>
>>> List-initialization can only call regular constructors, since it also
>>> has no name, just a type and parameters. Indirect initialization
>>> (`emplace`, `in_place_t` constructors, `make/allocate_shared/unique`, etc)
>>> can only call regular constructors for the same reason.
>>>
>>
>> If the change were made without considering library, then I agree, but I
>> don't think that's a roadblock. The addition of named constructors would
>> likely have implications on how we design new/update existing library
>> facilities and there's no reason to believe that we couldn't adjust
>> appropriately.
>>
>> Here's one example of what I mean -- previously in these forums I've
>> described that it would have been nice to have had something more akin to a
>> conceptified version of boost's in_place facilities rather than or in
>> addition to what we do today for emplacement. One of the reasons I say this
>> is because if done correctly, users could, for example, perform emplacement
>> via the result of a function call. The benefit of this particular approach,
>> especially with respect to *guaranteed* copy/move elision of C++17, is that
>> it allows for zero copies/moves even if you are constructing via a named
>> function with no directly corresponding constructor. Short of that kind of
>> abstraction, you could certainly imagine an "emplace_with_result" that
>> takes an Invocable and a set of arguments, where it constructs in-place
>> with the result of the function call. With that kind of facility, also
>> consider the possibility of being able to take the address of a named
>> constructor (why not? think of the constructor sort of like static function
>> that returns the constructed object). Then, all you'd have to do is pass
>> that in as the Invocable, followed by your desired arguments. Now you can
>> emplace with a named constructor. Regarding named constructors that are
>> *overloaded* or are templates, there are already proposals to allow easily
>> converting a set of overloads into a lambda that does the dispatching (and
>> it's a less controversial proposal for the closed-set of overloads of class
>> members). If we get something like that, then this solution even works
>> concisely when you have such a templated or overloaded named constructor.
>>
>> With such an "emplace_with_result" kind of function, the benefits of
>> named constructors over a named function that simply returns T are the
>> ability to directly initialize bases and members. Without the ability to do
>> that, your named function needs to use some existing constructor (maybe
>> private, and likely still requiring the tag/SFINAE dance behind the scenes).
>>
>> My point is, these are all solvable problems, they just have broader
>> implications if. It could end up being that these aren't changes that we
>> end up wanting to do, but without a paper that really formally explores the
>> options, it's hard to say.
>>
>
> So let's say we go through this effort. We add a lot of functions to the
> standard library. We add yet another language feature: lifting lambdas
> (which I'm all in favor of, regardless of this stuff). And probably some
> lip-service to list-initialization. Whatever.
>
> And after all of that work, we get... the ability to do this:
>
> auto t = Temperature::FromKelvin(...);
>
> rather than this:
>
> auto t = Temperature::FromKelvin(...);
>
> Or the ability to do this:
>
> v.emplace_back_with_result([]Temperature::FromKelvin, ...);
>
> Rather than this:
>
> v.emplace_back(..., Temperature::FromKelvin);
>
> I'm really trying to understand how the named constructor version is an
> improvement, but it's just not coming to me. From the perspective of the
> person calling the code, named constructors don't seem to be an improvement
> over static members and tags.
>
> You keep talking about "the tag/SFINAE dance" as though it were some
> complex and nightmarish code. But in most cases I've seen, it's pretty
> simple stuff. The result on the user end side is quite readable. I wouldn't
> even bother with a type for the case of `Temperature`; an enum is perfectly
> acceptable.
>
> And whatever SFINAE gymnastics you have to do will become much more
> reasonable once we get concepts, right?
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/
> isocpp.org/d/topic/std-proposals/HsChO8cvvVY/unsubscribe.
> To unsubscribe from this group and all its topics, 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/fb643c63-11ee-4d15-
> a577-1321362ceb99%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/fb643c63-11ee-4d15-a577-1321362ceb99%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>



--
*Torstone** Technology Limited*
8 Lloyd's Avenue, London, EC3N 3EL United Kingdom
T: +44 (0) 20 74187912  | E: stefan.pantos@torstonetech.com
<stefan.pantos@torstonetech.com>| W: www.torstonetech.com

--
The contents (including attachments) of this email are strictly
confidential, intended for the addressee(s) only and may be legally
privileged.  If you are not the intended recipient, please contact the
sender immediately and delete all copies of this email without distributing
it further in any way.  Torstone Technology Limited, its affiliates and
staff do not accept any liability for the contents of the message, and the
sending of this message is not intended to form a contract with the
recipient.  Torstone Technology Limited is registered in England and Wales
with company number 07490275 and registered office at 8 Lloyd's Avenue,
London EC3N 3EL, United Kingdom.

--
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/CAKj5Z3o1LuGYj9g%3D_WWSb3Eb0TzJ-0GZOZzeE3ME9jUmnw6WFQ%40mail.gmail.com.

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

<div dir=3D"ltr">It hadn&#39;t occurred to me about elision would likely ha=
ppen and I wasn&#39;t aware of=C2=A0&#39;Guaranteed Copy Elision&#39; being=
 in the standard.<div><br></div><div>In the world of &#39;almost always aut=
o&#39; the pattern auto x =3D T(blah); is quite common and it works quite n=
icely with auto x =3D T::FromKelvin();</div><div><br></div><div>Just off th=
e top of my head, I&#39;m not suggesting this is a good idea(gut feeling is=
 that it isn&#39;t) but a named constructor could be an aliases to the unna=
med constructor if it is uniquely identified by its arguments, explicit wou=
ld in effect undo this. Temperature zero(0); and it would call FromKelvin c=
onstructor. You could even give a default constructor have a name making so=
me things more explicit. optional&lt;int&gt;::null() for example, ok nullop=
t is better.</div><div><br></div><div>This makes me think about enum classe=
s. You have a class which had several zero-argument constructors which all =
had different names.</div><div><br></div><div>class Colour</div><div>{</div=
><div>=C2=A0 =C2=A0public:</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0constructor=
 red();</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0constructor green();<br></div>=
<div>=C2=A0 =C2=A0 =C2=A0 =C2=A0constructor blue();<br></div><div><br></div=
><div>=C2=A0 =C2=A0private:</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0int r, g, =
b;</div><div>};</div><div><br></div><div><br></div><div>Is there anything a=
bout them being constructors over static functions which would be good?</di=
v><div>Initialisation list, noexcept?=C2=A0</div><div><br><div><div>If peop=
le think it would be a worth while effort to write a proposal/paper to furt=
her explore the possibilities, I wouldn&#39;t mind having a go. Is anyone p=
repared to mentor me in such an endeavour? I don&#39;t have a massive amoun=
t of free time but I would certainly like to have a go.</div><div><br></div=
><div>Hope this isn&#39;t too rambling.</div><div><br></div><div><br></div>=
</div></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"=
>On 12 January 2017 at 17:05, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"=
mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br>On =
Thursday, January 12, 2017 at 11:44:14 AM UTC-5, Matt Calabrese wrote:<span=
 class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><=
div class=3D"gmail_quote">On Thu, Jan 12, 2017 at 11:02 AM, Nicol Bolas <sp=
an dir=3D"ltr">&lt;<a rel=3D"nofollow">jmck...@gmail.com</a>&gt;</span> wro=
te:<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">On Thursday, January=
 12, 2017 at 10:39:12 AM UTC-5, Matt Calabrese wrote:<span><blockquote clas=
s=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 class=3D"gmail_quote">On=
 Thu, Jan 12, 2017 at 8:07 AM,  <span dir=3D"ltr">&lt;<a rel=3D"nofollow">s=
tefan...@torstonetech.com</a>&gt;</span> wrote:<br><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"><div dir=3D"ltr">I find my self regularly creatin=
g static factory functions on classes to better describe how something is b=
eing constructed or to avoid having flags passed which may have some invali=
d permutations. Now some times this is because of poor design(Lazy/efficien=
t) but it does make me wonder if constructers with names different to their=
 class would be helpful.</div></blockquote><div><br></div><div>I agree that=
 the language needs named constructors, though this obviously needs a paper=
 and the syntax probably has to undergo bikeshedding. The standard library =
keeps adding constructor tags to effectively get names, and we often have t=
o make wacky SFINAE hacks to make those constructor overloads play nicely w=
ith other overloads. Named constructors more directly solve the problem (in=
 contrast to tag types) and also makes overload sets smaller, making the co=
de easier to reason about and to specify correctly (indirectly, it might ev=
en slightly improve compile times as well, but this is less of a concern). =
Guaranteed copy elision gets us close to having an equivalent of named cons=
tructors because it allows for named factory functions that return by value=
 yet don&#39;t need the type to even be movable. That only solves some of t=
he issues, though, and in practice, it still sometimes requires having (lik=
ely private) tagged constructor overloads. Named constructors might also be=
 able to have a beneficial relationship with C++17 deduction guides.</div><=
div><br></div><div>I&#39;d really like for someone to flesh out named const=
ructors more in a paper and come back with something more tangible/formal, =
covering all of the details.</div></div></div></div></blockquote></span><di=
v><br>One problem I have with named constructors (as opposed to just static=
=20
functions that return `T`) is that it doesn&#39;t solve the problem. The wh=
ole point of named constructors is that you have to provide a name to call =
the right function, yes?<br><br>Well, `T(...)` doesn&#39;t provide that nam=
e, so it can only call regular constructors.</div></div></blockquote><div><=
br></div><div>The reason I want the idea fleshed out is because there ideal=
ly would be syntax for the name there.</div><div>=C2=A0</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"><div> List-initialization can only call r=
egular constructors, since it also has no name, just a type and parameters.=
 Indirect initialization (`emplace`, `in_place_t` constructors, `make/alloc=
ate_shared/unique`, etc) can only call regular constructors for the same re=
ason.<br></div></div></blockquote><div><br></div><div>If the change were ma=
de without considering library, then I agree, but I don&#39;t think that&#3=
9;s a roadblock. The addition of named constructors would likely have impli=
cations on how we design new/update existing library facilities and there&#=
39;s no reason to believe that we couldn&#39;t adjust appropriately.</div><=
div><br></div><div>Here&#39;s one example of what I mean -- previously in t=
hese forums I&#39;ve described that it would have been nice to have had som=
ething more akin to a conceptified version of boost&#39;s in_place faciliti=
es rather than or in addition to what we do today for emplacement. One of t=
he reasons I say this is because if done correctly, users could, for exampl=
e, perform emplacement via the result of a function call. The benefit of th=
is particular approach, especially with respect to *guaranteed* copy/move e=
lision of C++17, is that it allows for zero copies/moves even if you are co=
nstructing via a named function with no directly corresponding constructor.=
 Short of that kind of abstraction, you could certainly imagine an &quot;em=
place_with_result&quot; that takes an Invocable and a set of arguments, whe=
re it constructs in-place with the result of the function call. With that k=
ind of facility, also consider the possibility of being able to take the ad=
dress of a named constructor (why not? think of the constructor sort of lik=
e static function that returns the constructed object). Then, all you&#39;d=
 have to do is pass that in as the Invocable, followed by your desired argu=
ments. Now you can emplace with a named constructor. Regarding named constr=
uctors that are *overloaded* or are templates, there are already proposals =
to allow easily converting a set of overloads into a lambda that does the d=
ispatching (and it&#39;s a less controversial proposal for the closed-set o=
f overloads of class members). If we get something like that, then this sol=
ution even works concisely when you have such a templated or overloaded nam=
ed constructor.</div><div><br></div><div>With such an &quot;emplace_with_re=
sult&quot; kind of function, the benefits of named constructors over a name=
d function that simply returns T are the ability to directly initialize bas=
es and members. Without the ability to do that, your named function needs t=
o use some existing constructor (maybe private, and likely still requiring =
the tag/SFINAE dance behind the scenes).</div><div><br></div><div>My point =
is, these are all solvable problems, they just have broader implications if=
.. It could end up being that these aren&#39;t changes that we end up wantin=
g to do, but without a paper that really formally explores the options, it&=
#39;s hard to say.</div></div></div></div></blockquote></span><div><br>So l=
et&#39;s say we go through this effort. We add a lot of functions to the st=
andard library. We add yet another language feature: lifting lambdas (which=
 I&#39;m all in favor of, regardless of this stuff). And probably some lip-=
service to list-initialization. Whatever.<br><br>And after all of that work=
, we get... the ability to do this:<br><br><div style=3D"background-color:r=
gb(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-wid=
th:1px" class=3D"m_5602562183150205042prettyprint"><code class=3D"m_5602562=
183150205042prettyprint"><div class=3D"m_5602562183150205042subprettyprint"=
><span style=3D"color:#008" class=3D"m_5602562183150205042styled-by-prettif=
y">auto</span><span style=3D"color:#000" class=3D"m_5602562183150205042styl=
ed-by-prettify"> t </span><span style=3D"color:#660" class=3D"m_56025621831=
50205042styled-by-prettify">=3D</span><span style=3D"color:#000" class=3D"m=
_5602562183150205042styled-by-prettify"> </span><span style=3D"color:#606" =
class=3D"m_5602562183150205042styled-by-prettify">Temperature</span><span s=
tyle=3D"color:#660" class=3D"m_5602562183150205042styled-by-prettify">::</s=
pan><span style=3D"color:#606" class=3D"m_5602562183150205042styled-by-pret=
tify">FromKelvin</span><span style=3D"color:#660" class=3D"m_56025621831502=
05042styled-by-prettify">(...);</span></div></code></div><br>rather than th=
is:<br><br><div style=3D"background-color:rgb(250,250,250);border-color:rgb=
(187,187,187);border-style:solid;border-width:1px" class=3D"m_5602562183150=
205042prettyprint"><code class=3D"m_5602562183150205042prettyprint"><div cl=
ass=3D"m_5602562183150205042subprettyprint"><span style=3D"color:#008" clas=
s=3D"m_5602562183150205042styled-by-prettify">auto</span><span style=3D"col=
or:#000" class=3D"m_5602562183150205042styled-by-prettify"> t </span><span =
style=3D"color:#660" class=3D"m_5602562183150205042styled-by-prettify">=3D<=
/span><span style=3D"color:#000" class=3D"m_5602562183150205042styled-by-pr=
ettify"> </span><span style=3D"color:#606" class=3D"m_5602562183150205042st=
yled-by-prettify">Temperature</span><span style=3D"color:#660" class=3D"m_5=
602562183150205042styled-by-prettify">::</span><span style=3D"color:#606" c=
lass=3D"m_5602562183150205042styled-by-prettify">FromKelvin</span><span sty=
le=3D"color:#660" class=3D"m_5602562183150205042styled-by-prettify">(...);<=
/span></div></code></div><br>Or the ability to do this:<br><br><div style=
=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);border-=
style:solid;border-width:1px" class=3D"m_5602562183150205042prettyprint"><c=
ode class=3D"m_5602562183150205042prettyprint"><div class=3D"m_560256218315=
0205042subprettyprint"><span style=3D"color:#000" class=3D"m_56025621831502=
05042styled-by-prettify">v</span><span style=3D"color:#660" class=3D"m_5602=
562183150205042styled-by-prettify">.</span><span style=3D"color:#000" class=
=3D"m_5602562183150205042styled-by-prettify">emplace_back_with_result</span=
><span style=3D"color:#660" class=3D"m_5602562183150205042styled-by-prettif=
y">([]</span><span style=3D"color:#606" class=3D"m_5602562183150205042style=
d-by-prettify">T<wbr>emperature</span><span style=3D"color:#660" class=3D"m=
_5602562183150205042styled-by-prettify">::</span><span style=3D"color:#606"=
 class=3D"m_5602562183150205042styled-by-prettify">FromKelvin</span><span s=
tyle=3D"color:#660" class=3D"m_5602562183150205042styled-by-prettify">,</sp=
an><span style=3D"color:#000" class=3D"m_5602562183150205042styled-by-prett=
ify"> </span><span style=3D"color:#660" class=3D"m_5602562183150205042style=
d-by-prettify">...);</span><span style=3D"color:#000" class=3D"m_5602562183=
150205042styled-by-prettify"><br></span></div></code></div><br>Rather than =
this:<br><br><div style=3D"background-color:rgb(250,250,250);border-color:r=
gb(187,187,187);border-style:solid;border-width:1px" class=3D"m_56025621831=
50205042prettyprint"><code class=3D"m_5602562183150205042prettyprint"><div =
class=3D"m_5602562183150205042subprettyprint"><span style=3D"color:#000" cl=
ass=3D"m_5602562183150205042styled-by-prettify">v</span><span style=3D"colo=
r:#660" class=3D"m_5602562183150205042styled-by-prettify">.</span><span sty=
le=3D"color:#000" class=3D"m_5602562183150205042styled-by-prettify">emplace=
_back</span><span style=3D"color:#660" class=3D"m_5602562183150205042styled=
-by-prettify">(...,</span><span style=3D"color:#000" class=3D"m_56025621831=
50205042styled-by-prettify"> </span><span style=3D"color:#606" class=3D"m_5=
602562183150205042styled-by-prettify">Temperature</span><span style=3D"colo=
r:#660" class=3D"m_5602562183150205042styled-by-prettify">::</span><span st=
yle=3D"color:#606" class=3D"m_5602562183150205042styled-by-prettify">FromKe=
lvin</span><span style=3D"color:#660" class=3D"m_5602562183150205042styled-=
by-prettify">);</span></div></code></div><br>I&#39;m really trying to under=
stand how the named constructor version is an improvement, but it&#39;s jus=
t not coming to me. From the perspective of the person calling the code, na=
med constructors don&#39;t seem to be an improvement over static members an=
d tags.<br><br>You keep talking about &quot;the tag/SFINAE dance&quot; as t=
hough it were some complex and nightmarish code. But in most cases I&#39;ve=
 seen, it&#39;s pretty simple stuff. The result on the user end side is qui=
te readable. I wouldn&#39;t even bother with a type for the case of `Temper=
ature`; an enum is perfectly acceptable.<br><br>And whatever SFINAE gymnast=
ics you have to do will become much more reasonable once we get concepts, r=
ight?<br></div></div><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/HsChO8cvvVY/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/H=
sChO8cvvVY/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+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/fb643c63-11ee-4d15-a577-1321362ceb99%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/fb64=
3c63-11ee-4d15-<wbr>a577-1321362ceb99%40isocpp.org</a><wbr>.<br>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div class=
=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><d=
iv><div dir=3D"ltr"><div style=3D"color:rgb(0,0,0);font-size:12pt;font-fami=
ly:&#39;Times New Roman&#39;,serif;margin:0in 0in 0.0001pt"><b><span style=
=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(225,0,75)">Tors=
tone</span></b><b><span style=3D"font-size:11pt;font-family:Calibri,sans-se=
rif">=C2=A0Technology Limited</span></b></div><div style=3D"color:rgb(0,0,0=
);font-size:12pt;font-family:&#39;Times New Roman&#39;,serif;margin:0in 0in=
 0.0001pt"><span style=3D"font-size:8pt;font-family:Calibri,sans-serif;colo=
r:gray">8 Lloyd&#39;s Avenue, London, EC3N 3EL United Kingdom</span></div><=
div style=3D"color:rgb(0,0,0);font-size:12pt;font-family:&#39;Times New Rom=
an&#39;,serif;margin:0in 0in 0.0001pt"><span style=3D"font-family:Calibri,s=
ans-serif;font-size:8pt;color:rgb(225,0,75)">T:</span><span style=3D"font-f=
amily:Calibri,sans-serif;font-size:8pt;color:gray">=C2=A0+44 (0) 20 7418791=
2 =C2=A0|=C2=A0</span><span style=3D"font-family:Calibri,sans-serif;font-si=
ze:8pt;color:rgb(225,0,75)">E:</span><font color=3D"#8026b6" style=3D"font-=
family:Helvetica;font-size:medium"><span style=3D"font-family:Calibri,sans-=
serif;font-size:8pt">=C2=A0</span><a href=3D"mailto:stefan.pantos@torstonet=
ech.com" style=3D"font-size:11px" target=3D"_blank"><font face=3D"Calibri" =
color=3D"#8026b6">stefan.pantos@torstonetech.com=C2=A0</font></a></font><sp=
an style=3D"font-family:Calibri,sans-serif;font-size:8pt;color:gray">|=C2=
=A0</span><span style=3D"font-family:Calibri,sans-serif;font-size:8pt;color=
:rgb(225,0,75)">W:</span><font face=3D"Calibri" style=3D"font-size:medium">=
<span style=3D"font-size:11px"><span style=3D"color:gray">=C2=A0</span><a h=
ref=3D"http://www.torstonetech.com/" target=3D"_blank"><font color=3D"#8026=
b6">www.torstonetech.com</font></a></span></font></div></div></div></div></=
div>
</div>

<br>
<font face=3D"Arial, Helvetica, sans-serif"><span style=3D"font-size:1.3em"=
>The contents
(including attachments) of this email are strictly confidential, intended f=
or
the addressee(s) only and may be legally privileged.=C2=A0 If you are not t=
he intended
recipient, please contact the sender immediately and delete all copies of t=
his
email without distributing it further in any way.=C2=A0 Torstone Technology
Limited, its affiliates and staff do not accept any liability for the conte=
nts
of the message, and the sending of this message is not intended to form a
contract with the recipient. =C2=A0Torstone Technology Limited is registere=
d in England and Wales with company number 07490275 and registered office a=
t 8 Lloyd&#39;s Avenue, London EC3N 3EL, United Kingdom.</span></font>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKj5Z3o1LuGYj9g%3D_WWSb3Eb0TzJ-0GZOZ=
zeE3ME9jUmnw6WFQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKj5Z3o1LuGYj9=
g%3D_WWSb3Eb0TzJ-0GZOZzeE3ME9jUmnw6WFQ%40mail.gmail.com</a>.<br />

--001a113d729e2428d80545ea1cd2--

.

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

On Thu, Jan 12, 2017 at 1:44 PM, Matt Calabrese <calabrese@google.com>
wrote:

> The temperature class presented here isn't a particularly great example
> for reasons you've mentioned. The benefit comes primarily from development
> of the constructor/creation functions and from minimizing the amount of
> confusing overloads in an overload set. Forget about constructors for a
> moment -- imagine we lived in a hellish world where all functions were
> required to be called "foo" (perhaps almost as hellish as a world where
> everyone programmed in Java). In order to disambiguate what we were doing,
> we'd have to do things like make silly tag types for certain cases and
> write each overload in a way that was aware of all of the other overloads
> in order to make sure we don't have unintended ambiguities or incorrect
> matches.
>

Another thing to note, if we simply restricted ourselves to *always* using
tags for constructors that aren't intended to be copy/move, we'd simplify
our problem a bit, but that's not what we've done in the past.

--
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/CANh8DEk06v%3D_0fFG9roTpz2zGhK6mb-mputaYboV4Tv743i_HQ%40mail.gmail.com.

--001a113a9a4efee5420545ea2618
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 T=
hu, Jan 12, 2017 at 1:44 PM, Matt Calabrese <span dir=3D"ltr">&lt;<a href=
=3D"mailto:calabrese@google.com" target=3D"_blank">calabrese@google.com</a>=
&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D""><div>The =
temperature class presented here isn&#39;t a particularly great example for=
 reasons you&#39;ve mentioned. The benefit comes primarily from development=
 of the constructor/creation functions and from minimizing the amount of co=
nfusing overloads in an overload set. Forget about constructors for a momen=
t -- imagine we lived in a hellish world where all functions were required =
to be called &quot;foo&quot; (perhaps almost as hellish as a world where ev=
eryone programmed in Java). In order to disambiguate what we were doing, we=
&#39;d have to do things like make silly tag types for certain cases and wr=
ite each overload in a way that was aware of all of the other overloads in =
order to make sure we don&#39;t have unintended ambiguities or incorrect ma=
tches.</div></span></div></div></div></blockquote><div><br></div><div>Anoth=
er thing to note, if we simply restricted ourselves to *always* using tags =
for constructors that aren&#39;t intended to be copy/move, we&#39;d simplif=
y our problem a bit, but that&#39;s not what we&#39;ve done in the past.</d=
iv></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANh8DEk06v%3D_0fFG9roTpz2zGhK6mb-mpu=
taYboV4Tv743i_HQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEk06v%3D_=
0fFG9roTpz2zGhK6mb-mputaYboV4Tv743i_HQ%40mail.gmail.com</a>.<br />

--001a113a9a4efee5420545ea2618--

.

------=_Part_1039_1473398950.1484249591778
Content-Type: multipart/alternative;
 boundary="----=_Part_1040_1296750968.1484249591779"

------=_Part_1040_1296750968.1484249591779
Content-Type: text/plain; charset=UTF-8



On Thursday, January 12, 2017 at 1:44:32 PM UTC-5, Matt Calabrese wrote:
>
> On Thu, Jan 12, 2017 at 12:05 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> So let's say we go through this effort. We add a lot of functions to the
>> standard library. We add yet another language feature: lifting lambdas
>> (which I'm all in favor of, regardless of this stuff). And probably some
>> lip-service to list-initialization. Whatever.
>>
>> And after all of that work, we get... the ability to do this:
>>
>> auto t = Temperature::FromKelvin(...);
>>
>> rather than this:
>>
>> auto t = Temperature::FromKelvin(...);
>>
>> Or the ability to do this:
>>
>> v.emplace_back_with_result([]Temperature::FromKelvin, ...);
>>
>> Rather than this:
>>
>> v.emplace_back(..., Temperature::FromKelvin);
>>
>> I'm really trying to understand how the named constructor version is an
>> improvement, but it's just not coming to me. From the perspective of the
>> person calling the code, named constructors don't seem to be an improvement
>> over static members and tags.
>>
>
> The temperature class presented here isn't a particularly great example
> for reasons you've mentioned. The benefit comes primarily from development
> of the constructor/creation functions and from minimizing the amount of
> confusing overloads in an overload set. Forget about constructors for a
> moment -- imagine we lived in a hellish world where all functions were
> required to be called "foo" (perhaps almost as hellish as a world where
> everyone programmed in Java). In order to disambiguate what we were doing,
> we'd have to do things like make silly tag types for certain cases and
> write each overload in a way that was aware of all of the other overloads
> in order to make sure we don't have unintended ambiguities or incorrect
> matches.
>

That world would look like this:

foo(ActualFunctionName{}, params);

We would have a useless `foo`, followed by a type whose name describes the
function we want to call, followed by the parameters to those overloads.
Besides the unnecessary syntax, I don't see this as being particularly
worse than today.

It's also not that much worse when defining new overloads:

struct ActualFunctionName{};

void foo(ActualFunctionName, Type1 param1, Type2 param2)
{...}

Yes, it's long-winded with a lot of extraneous syntax. But *it's not hard*.
And it's not even particularly confusing for the user or the writer of the
function. You've got one argument that is used to disambiguate the
overload, and that's all you need. There's no complex SFINAE gymnastics
being employed. It's something that beginning C++ programmers can handle
just fine.

As I think about it, the world you're describing is a lot like a world
where we do this for every function call:

invoke([]ActualFunctionName, params);

You have a parameter that disambiguates the call, followed by parameters
that do the work.

Is that not *exactly* what we would have to do with `emplace_with_result`?

Obviously this is not the world of C++... except when in the limited scope
> of a type's constructors. Though we have fewer overloads to think about,
> it's the same kind of issue only on a smaller scale. We've gotten used to
> our tricks enough to get by, but they're still pretty weird tricks and are
> definitely not helping those who are new to the language. With respect to
> the standard library, these tricks tend to snowball as well, especially as
> we add more constructor overloads in each standard -- consider the
> evolution that the std::tuple constructors have gone through (
> http://en.cppreference.com/w/cpp/utility/tuple/tuple ).
>

Let's say you take all of the `allocator_arg_t` and make them named
constructors: `tuple::with_allocator(...)`. What have you changed? What
have you improved?

If you want to do indirect initialization, you still have to use the
long-winded `[]tuple::with_allocator` syntax. I fail to see how that is an
improvement over `std::allocator_arg_t{}` as the first parameter.


> On Thu, Jan 12, 2017 at 12:05 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> You keep talking about "the tag/SFINAE dance" as though it were some
>> complex and nightmarish code. But in most cases I've seen, it's pretty
>> simple stuff. The result on the user end side is quite readable.
>>
>
> Depending on how it's taught, the user side of the problem isn't nearly as
> difficult as getting the implementation side correct, but that said, a
> nontrivial amount of time and analysis needs to be spent to specify the
> constraints properly for many types that have constructors like these. For
> user-developed types, I'm sure that either a similar amount of time is
> spent, or (worse) constraints are incorrect. If you don't buy the
> trickiness, again, check out all of the gross constraints that need to
> exist for tuple ( http://en.cppreference.com/w/cpp/utility/tuple/tuple ).
> It's tricky and I don't have much faith in myself nor even in the committee
> as a whole to always get things exactly "correct" 100% of the time. That's
> scary to me, especially when I think of everyday users who might attempt
> analogous things.
>

Those SFINAE tricks have nothing to do with it being a single overload.

If you had a `tuple::convert` named constructor, one which performed
implicit conversions like the variadic-template constructors that exist
now, they would still need to use SFINAE to decide to be explicit or not,
and they would still need SFINAE to not be present if the given types don't
allow implicit conversions.

The complexity is not there to prevent inter-overload conflicts. It's there
to make the type do what we need it to do.

In a similar respect, there are a couple of ways that users, as opposed to
> the committee and implementors, are impacted by this, even if they
> themselves only *use* such constructors. For one, trying to figure out what
> on earth the tuple constructors do and which overloads would be picked by
> simply reading the documentation of those constructors is sometimes
> difficult for moderately experienced developers, let alone those newer to
> the language.
>

Really? While looking at the list of constructors may be dizzying, actually
*using* `tuple` is pretty straightforward:

using tpl = tuple<int, float, double>;

tpl a(5, 32.f, 60.0);
tpl b(5, 32, 60.0);
tpl c(5, 32.f, 60);
tpl d(5, 32, 60);

Those constructors are a complex way of saying, "We can implicitly convert
from whatever you give us to the various types the tuple actually stores."

I fail to see how this is better:

using tpl = tuple<int, float, double>;

tpl a(5, 32.f, 60.0);
tpl b::implicit(5, 32, 60.0);
tpl c::implicit(5, 32.f, 60);
tpl d::implicit(5, 32, 60);

> I find this particularly embarrassing because a tuple isn't exactly a
> complicated notion to understand. As well, because it can be tricky to get
> these constraints correct without ambiguities and (worse) without
> unintended overloads being a better match, we may even specify these
> constraints incorrectly, in which case the user can be faced with some
> wacky compiler errors or unexpected run-time behavior.
>
> On Thu, Jan 12, 2017 at 12:05 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>>
>> And whatever SFINAE gymnastics you have to do will become much more
>> reasonable once we get concepts, right?
>>
>
> I suppose it depends on what you mean by "reasonable" there, but my view
> is not really. By that I mean for these *particular* kinds of cases, the
> code would look nicer, but the same kinds of constraints will need to be
> there. In this situation, the SFINAE gymnastics would be replaced by
> requires clauses, but we'd still need the same amount and kinds of
> constraints. What we might get in this case with concepts is the potential
> for better error messages when a user does something wrong, which is at
> least something, but the implementation and usage complexity remains mostly
> unchanged. Benefits of concepts are much greater for constraining and
> specializing generic code rather than for disambiguating tagged
> constructors and non-tagged overloads.
>
> Anyway, again, I'm not absolutely convinced that named constructors are
> the best option, but I do think that they are an option that is very worthy
> of exploration in a paper. I think that there is a reasonable chance that
> we could get to a more sane place than where we are right now, but that's
> still somewhat of a guess without a deeper analysis.
>

--
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/9a3af928-dc66-4f7c-9d0c-a35f8f095489%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Thursday, January 12, 2017 at 1:44:32 PM UTC-5,=
 Matt Calabrese 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><div class=3D"gmail_quote">On Thu, Jan 12, 2017 at 12:05 PM, =
Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank"=
 gdf-obfuscated-mailto=3D"vM_kW2yaBgAJ" rel=3D"nofollow" onmousedown=3D"thi=
s.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;ja=
vascript:&#39;;return true;">jmck...@gmail.com</a>&gt;</span> wrote:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>So let=
&#39;s say we go through this effort. We add a lot of functions to the stan=
dard library. We add yet another language feature: lifting lambdas (which I=
&#39;m all in favor of, regardless of this stuff). And probably some lip-se=
rvice to list-initialization. Whatever.<br><br>And after all of that work, =
we get... the ability to do this:<br><br><div style=3D"background-color:rgb=
(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-width=
:1px"><code><div><span style=3D"color:rgb(0,0,136)">auto</span><span style=
=3D"color:rgb(0,0,0)"> t </span><span style=3D"color:rgb(102,102,0)">=3D</s=
pan><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,0=
,102)">Temperature</span><span style=3D"color:rgb(102,102,0)">::</span><spa=
n style=3D"color:rgb(102,0,102)">FromKelvin</span><span style=3D"color:rgb(=
102,102,0)">(...);</span></div></code></div><br>rather than this:<br><br><d=
iv style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187)=
;border-style:solid;border-width:1px"><code><div><span style=3D"color:rgb(0=
,0,136)">auto</span><span style=3D"color:rgb(0,0,0)"> t </span><span style=
=3D"color:rgb(102,102,0)">=3D</span><span style=3D"color:rgb(0,0,0)"> </spa=
n><span style=3D"color:rgb(102,0,102)">Temperature</span><span style=3D"col=
or:rgb(102,102,0)">::</span><span style=3D"color:rgb(102,0,102)">FromKelvin=
</span><span style=3D"color:rgb(102,102,0)">(...);</span></div></code></div=
><br>Or the ability to do this:<br><br><div style=3D"background-color:rgb(2=
50,250,250);border-color:rgb(187,187,187);border-style:solid;border-width:1=
px"><code><div><span style=3D"color:rgb(0,0,0)">v</span><span style=3D"colo=
r:rgb(102,102,0)">.</span><span style=3D"color:rgb(0,0,0)">emplace_back_wit=
h_result</span><span style=3D"color:rgb(102,102,0)">([]</span><span style=
=3D"color:rgb(102,0,102)">T<wbr>emperature</span><span style=3D"color:rgb(1=
02,102,0)">::</span><span style=3D"color:rgb(102,0,102)">FromKelvin</span><=
span style=3D"color:rgb(102,102,0)">,</span><span style=3D"color:rgb(0,0,0)=
"> </span><span style=3D"color:rgb(102,102,0)">...);</span><span style=3D"c=
olor:rgb(0,0,0)"><br></span></div></code></div><br>Rather than this:<br><br=
><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,1=
87);border-style:solid;border-width:1px"><code><div><span style=3D"color:rg=
b(0,0,0)">v</span><span style=3D"color:rgb(102,102,0)">.</span><span style=
=3D"color:rgb(0,0,0)">emplace_back</span><span style=3D"color:rgb(102,102,0=
)">(...,</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"colo=
r:rgb(102,0,102)">Temperature</span><span style=3D"color:rgb(102,102,0)">::=
</span><span style=3D"color:rgb(102,0,102)">FromKelvin</span><span style=3D=
"color:rgb(102,102,0)">);</span></div></code></div><br>I&#39;m really tryin=
g to understand how the named constructor version is an improvement, but it=
&#39;s just not coming to me. From the perspective of the person calling th=
e code, named constructors don&#39;t seem to be an improvement over static =
members and tags.<br></div></div></blockquote><div><br></div><div>The tempe=
rature class presented here isn&#39;t a particularly great example for reas=
ons you&#39;ve mentioned. The benefit comes primarily from development of t=
he constructor/creation functions and from minimizing the amount of confusi=
ng overloads in an overload set. Forget about constructors for a moment -- =
imagine we lived in a hellish world where all functions were required to be=
 called &quot;foo&quot; (perhaps almost as hellish as a world where everyon=
e programmed in Java). In order to disambiguate what we were doing, we&#39;=
d have to do things like make silly tag types for certain cases and write e=
ach overload in a way that was aware of all of the other overloads in order=
 to make sure we don&#39;t have unintended ambiguities or incorrect matches=
..</div></div></div></div></blockquote><div><br>That world would look like t=
his:<br><br><div style=3D"background-color: rgb(250, 250, 250); border-colo=
r: rgb(187, 187, 187); border-style: solid; border-width: 1px; overflow-wra=
p: break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div clas=
s=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">foo</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</=
span><span style=3D"color: #606;" class=3D"styled-by-prettify">ActualFuncti=
onName</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: #008;" class=3D"styled-by-prettify">params</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></div></code></div><b=
r>We would have a useless `foo`, followed by a type whose name describes th=
e function we want to call, followed by the parameters to those overloads. =
Besides the unnecessary syntax, I don&#39;t see this as being particularly =
worse than today.<br><br>It&#39;s also not that much worse when defining ne=
w overloads:<br><br><div style=3D"background-color: rgb(250, 250, 250); bor=
der-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; over=
flow-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><=
div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">struct</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">A=
ctualFunctionName</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">{};</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">vo=
id</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> foo</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span =
style=3D"color: #606;" class=3D"styled-by-prettify">ActualFunctionName</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #606;" class=3D"styled-by-prettify">Type1</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> param1</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: #606;" class=3D"styl=
ed-by-prettify">Type2</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> param2</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">)</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><br>Yes, it&#39;s long-winded with a lot of extrane=
ous syntax. But <i>it&#39;s not hard</i>. And it&#39;s not even particularl=
y confusing for the user or the writer of the function. You&#39;ve got one =
argument that is used to disambiguate the overload, and that&#39;s all you =
need. There&#39;s no complex SFINAE gymnastics being employed. It&#39;s som=
ething that beginning C++ programmers can handle just fine.<br><br>As I thi=
nk about it, the world you&#39;re describing is a lot like a world where we=
 do this for every function call:<br><br><div style=3D"background-color: rg=
b(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; bo=
rder-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code cl=
ass=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">invoke</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">([]</span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">ActualFunctionName</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">params</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">);</span></div></code></div><br>You have a parameter that disamb=
iguates the call, followed by parameters that do the work.<br><br>Is that n=
ot <i>exactly</i> what we would have to do with `emplace_with_result`?<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=
><div class=3D"gmail_quote"><div>Obviously this is not the world of C++... =
except when in the limited scope of a type&#39;s constructors. Though we ha=
ve fewer overloads to think about, it&#39;s the same kind of issue only on =
a smaller scale. We&#39;ve gotten used to our tricks enough to get by, but =
they&#39;re still pretty weird tricks and are definitely not helping those =
who are new to the language. With respect to the standard library, these tr=
icks tend to snowball as well, especially as we add more constructor overlo=
ads in each standard -- consider the evolution that the std::tuple construc=
tors have gone through ( <a href=3D"http://en.cppreference.com/w/cpp/utilit=
y/tuple/tuple" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fen.cppreference.com%2Fw=
%2Fcpp%2Futility%2Ftuple%2Ftuple\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEX=
-kSYfX83O0xfYx_zM8f7aYdxkA&#39;;return true;" onclick=3D"this.href=3D&#39;h=
ttp://www.google.com/url?q\x3dhttp%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2F=
utility%2Ftuple%2Ftuple\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEX-kSYfX83O=
0xfYx_zM8f7aYdxkA&#39;;return true;">http://en.cppreference.com/w/<wbr>cpp/=
utility/tuple/tuple</a> ).</div></div></div></div></blockquote><div><br>Let=
&#39;s say you take all of the `allocator_arg_t` and make them named constr=
uctors: `tuple::with_allocator(...)`. What have you changed? What have you =
improved?<br><br>If you want to do indirect initialization, you still have =
to use the long-winded `[]tuple::with_allocator` syntax. I fail to see how =
that is an improvement over `std::allocator_arg_t{}` as the first parameter=
..<br>=C2=A0</div><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><div class=3D"gmail_quote"><div></div><div>On Thu, Jan 12, 2017 at=
 12:05 PM, Nicol Bolas=C2=A0<span dir=3D"ltr">&lt;<a href=3D"javascript:" t=
arget=3D"_blank" gdf-obfuscated-mailto=3D"vM_kW2yaBgAJ" rel=3D"nofollow" on=
mousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"thi=
s.href=3D&#39;javascript:&#39;;return true;">jmck...@gmail.com</a>&gt;</spa=
n>=C2=A0<wbr>wrote:</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">=
<div dir=3D"ltr"><div>You keep talking about &quot;the tag/SFINAE dance&quo=
t; as though it were some complex and nightmarish code. But in most cases I=
&#39;ve seen, it&#39;s pretty simple stuff. The result on the user end side=
 is quite readable.<br></div></div></blockquote><div><br></div><div>Dependi=
ng on how it&#39;s taught, the user side of the problem isn&#39;t nearly as=
 difficult as getting the implementation side correct, but that said, a non=
trivial amount of time and analysis needs to be spent to specify the constr=
aints properly for many types that have constructors like these. For user-d=
eveloped types, I&#39;m sure that either a similar amount of time is spent,=
 or (worse) constraints are incorrect. If you don&#39;t buy the trickiness,=
 again, check out all of the gross constraints that need to exist for tuple=
 ( <a href=3D"http://en.cppreference.com/w/cpp/utility/tuple/tuple" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Futility%2Ftup=
le%2Ftuple\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEX-kSYfX83O0xfYx_zM8f7aY=
dxkA&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.google.com/u=
rl?q\x3dhttp%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Futility%2Ftuple%2Ftupl=
e\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEX-kSYfX83O0xfYx_zM8f7aYdxkA&#39;=
;return true;">http://en.cppreference.com/w/<wbr>cpp/utility/tuple/tuple</a=
> ). It&#39;s tricky and I don&#39;t have much faith in myself nor even in =
the committee as a whole to always get things exactly &quot;correct&quot; 1=
00% of the time. That&#39;s scary to me, especially when I think of everyda=
y users who might attempt analogous things.</div></div></div></div></blockq=
uote><div><br>Those SFINAE tricks have nothing to do with it being a single=
 overload.<br><br>If you had a `tuple::convert` named constructor, one whic=
h performed implicit conversions like the variadic-template constructors th=
at exist now, they would still need to use SFINAE to decide to be explicit =
or not, and they would still need SFINAE to not be present if the given typ=
es don&#39;t allow implicit conversions.<br><br>The complexity is not there=
 to prevent inter-overload conflicts. It&#39;s there to make the type do wh=
at we need it to do.<br><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); p=
adding-left: 1ex;"></blockquote><blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>In a similar respec=
t, there are a couple of ways that users, as opposed to the committee and i=
mplementors, are impacted by this, even if they themselves only *use* such =
constructors. For one, trying to figure out what on earth the tuple constru=
ctors do and which overloads would be picked by simply reading the document=
ation of those constructors is sometimes difficult for moderately experienc=
ed developers, let alone those newer to the language.</div></div></div></di=
v></blockquote><div><br>Really? While looking at the list of constructors m=
ay be dizzying, actually <i>using</i> `tuple` is pretty straightforward:<br=
><br><div style=3D"background-color: rgb(250, 250, 250); border-color: rgb(=
187, 187, 187); border-style: solid; border-width: 1px; overflow-wrap: brea=
k-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"su=
bprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">usi=
ng</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> tpl </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> tuple</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">float</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>double</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt=
;;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>=
tpl a</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</sp=
an><span style=3D"color: #066;" class=3D"styled-by-prettify">5</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=
66;" class=3D"styled-by-prettify">32.f</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-=
prettify">60.0</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
tpl b</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</sp=
an><span style=3D"color: #066;" class=3D"styled-by-prettify">5</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=
66;" class=3D"styled-by-prettify">32</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-pr=
ettify">60.0</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>tp=
l c</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span=
><span style=3D"color: #066;" class=3D"styled-by-prettify">5</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066=
;" class=3D"styled-by-prettify">32.f</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-pr=
ettify">60</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>tpl =
d</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><=
span style=3D"color: #066;" class=3D"styled-by-prettify">5</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: #066;"=
 class=3D"styled-by-prettify">32</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: #066;" class=3D"styled-by-pret=
tify">60</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);=
</span></div></code></div><br>Those constructors are a complex way of sayin=
g, &quot;We can implicitly convert from whatever you give us to the various=
 types the tuple actually stores.&quot;<br><br>I fail to see how this is be=
tter:<br><br><div style=3D"background-color: rgb(250, 250, 250); border-col=
or: rgb(187, 187, 187); border-style: solid; border-width: 1px; overflow-wr=
ap: break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div cla=
ss=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">using</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 tpl </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> tuple</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">float</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">double</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">&gt;;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
><br>tpl a</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
(</span><span style=3D"color: #066;" class=3D"styled-by-prettify">5</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #066;" class=3D"styled-by-prettify">32.f</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: #066;" class=3D"style=
d-by-prettify">60.0</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br>tpl b</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
::</span><span style=3D"color: #008;" class=3D"styled-by-prettify">implicit=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><s=
pan style=3D"color: #066;" class=3D"styled-by-prettify">5</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" =
class=3D"styled-by-prettify">32</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettif=
y">60.0</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>tpl c</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">implicit</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D=
"color: #066;" class=3D"styled-by-prettify">5</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"sty=
led-by-prettify">32.f</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">60</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br>tpl d</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">implicit</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #066=
;" class=3D"styled-by-prettify">5</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: #066;" class=3D"styled-by-pret=
tify">32</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: #066;" class=3D"styled-by-prettify">60</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">);</span></div></code></div>=
</div><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><d=
iv class=3D"gmail_quote"><div>I find this particularly embarrassing because=
 a tuple isn&#39;t exactly a complicated notion to understand. As well, bec=
ause it can be tricky to get these constraints correct without ambiguities =
and (worse) without unintended overloads being a better match, we may even =
specify these constraints incorrectly, in which case the user can be faced =
with some wacky compiler errors or unexpected run-time behavior.</div><br>O=
n Thu, Jan 12, 2017 at 12:05 PM, Nicol Bolas=C2=A0<span dir=3D"ltr">&lt;<a =
href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"vM_kW2yaBgA=
J" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return=
 true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">jmck...@=
gmail.com</a>&gt;</span>=C2=A0<wbr>wrote:<blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex"><div dir=3D"ltr"><div>And whatever SFINAE gymnastics you ha=
ve to do will become much more reasonable once we get concepts, right?</div=
></div></blockquote><div><br></div><div>I suppose it depends on what you me=
an by &quot;reasonable&quot; there, but my view is not really. By that I me=
an for these *particular* kinds of cases, the code would look nicer, but th=
e same kinds of constraints will need to be there. In this situation, the S=
FINAE gymnastics would be replaced by requires clauses, but we&#39;d still =
need the same amount and kinds of constraints. What we might get in this ca=
se with concepts is the potential for better error messages when a user doe=
s something wrong, which is at least something, but the implementation and =
usage complexity remains mostly unchanged. Benefits of concepts are much gr=
eater for constraining and specializing generic code rather than for disamb=
iguating tagged constructors and non-tagged overloads.</div><div><br></div>=
<div>Anyway, again, I&#39;m not absolutely convinced that named constructor=
s are the best option, but I do think that they are an option that is very =
worthy of exploration in a paper. I think that there is a reasonable chance=
 that we could get to a more sane place than where we are right now, but th=
at&#39;s still somewhat of a guess without a deeper analysis.</div></div></=
div></div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9a3af928-dc66-4f7c-9d0c-a35f8f095489%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9a3af928-dc66-4f7c-9d0c-a35f8f095489=
%40isocpp.org</a>.<br />

------=_Part_1040_1296750968.1484249591779--

------=_Part_1039_1473398950.1484249591778--

.

Hope this isn't stupid but I'm not familiar with this syntax.
v.emplace_back_with_result([]Temperature::FromKelvin, ...);

What is happening with the '[]Temperature::FromKelvin'
Thought it might have been a typo at first but it was used a couple of times. Thought I would look it up but I'm struggling to find it.

I'm also not convinced by my own suggestion. It is comforting that I wasn't completely alone in thinking it might be nice though.

--
The contents (including attachments) of this email are strictly
confidential, intended for the addressee(s) only and may be legally
privileged.  If you are not the intended recipient, please contact the
sender immediately and delete all copies of this email without distributing
it further in any way.  Torstone Technology Limited, its affiliates and
staff do not accept any liability for the contents of the message, and the
sending of this message is not intended to form a contract with the
recipient.  Torstone Technology Limited is registered in England and Wales
with company number 07490275 and registered office at 8 Lloyd's Avenue,
London EC3N 3EL, United Kingdom.

--
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/b6bc31c6-397d-4809-bb40-84b086651614%40isocpp.org.

.

------=_Part_1273_2051775509.1484264394026
Content-Type: multipart/alternative;
 boundary="----=_Part_1274_1652762531.1484264394026"

------=_Part_1274_1652762531.1484264394026
Content-Type: text/plain; charset=UTF-8

On Thursday, January 12, 2017 at 5:03:04 PM UTC-5,
stefan...@torstonetech.com wrote:
>
> Hope this isn't stupid but I'm not familiar with this syntax.
> v.emplace_back_with_result([]Temperature::FromKelvin, ...);
>
> What is happening with the '[]Temperature::FromKelvin'
> Thought it might have been a typo at first but it was used a couple of
> times. Thought I would look it up but I'm struggling to find it.
>

It's not real C++. Or at least, not yet.

Matt and I are referring to a proposal for lifting lambda expressions.
`[]Name` generates a lambda expression as if defined something like this:

[](auto &&...args) -> decltype(auto) {return Name(std::forward<decltype(args
)>(args)...));}

Name can also be a typename, in which case it results in a lambda that
constructs an object of that type. So in the above case,
[]Temperature::FromKelvin would be a lambda that forwards to that function
and returns what it returns.

I'm also not convinced by my own suggestion. It is comforting that I wasn't
> completely alone in thinking it might be nice though.
>
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/bb9a39aa-cd27-46d3-8a0d-3a67d8ddb84c%40isocpp.org.

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

<div dir=3D"ltr">On Thursday, January 12, 2017 at 5:03:04 PM UTC-5, stefan.=
...@torstonetech.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hope=
 this isn&#39;t stupid but I&#39;m not familiar with this syntax.<br>v.empl=
ace_back_with_result([]<wbr>Temperature::FromKelvin, ...);<p>What is happen=
ing with the &#39;[]Temperature::FromKelvin&#39;<br>Thought it might have b=
een a typo at first but it was used a couple of times. Thought I would look=
 it up but I&#39;m struggling to find it.</p></blockquote><div><br>It&#39;s=
 not real C++. Or at least, not yet.<br><br>Matt and I are referring to a p=
roposal for lifting lambda expressions. `[]Name` generates a lambda express=
ion as if defined something like this:<br><br><div style=3D"background-colo=
r: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: soli=
d; border-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><co=
de class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color=
: #660;" class=3D"styled-by-prettify">[](</span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">&amp;&amp;...</span><span style=3D"color: #000;" 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-pretti=
fy"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">-&gt;=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">decltype</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"co=
lor: #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: #008;" class=3D"style=
d-by-prettify">return</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify=
">Name</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">std</span><sp=
an 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;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">decltype</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">args</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">)&gt;(</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">args</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">)...));}</span></div></code></div><br>Name can also be a typenam=
e, in which case it results in a lambda that constructs an object of that t=
ype. So in the above case, []Temperature::FromKelvin would be a lambda that=
 forwards to that function and returns what it returns.<br><br></div><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><p>I&#39;m also not convinced by my =
own suggestion. It is comforting that I wasn&#39;t completely alone in thin=
king it might be nice though.<br></p><p></p></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/bb9a39aa-cd27-46d3-8a0d-3a67d8ddb84c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/bb9a39aa-cd27-46d3-8a0d-3a67d8ddb84c=
%40isocpp.org</a>.<br />

------=_Part_1274_1652762531.1484264394026--

------=_Part_1273_2051775509.1484264394026--

.

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

When I do this, I write an essentially constexpr Temperature<R> where R is
some empty tag class (Celsius, Fahrenheit, Kelvin) such that

auto k =3D 273_K; // Temperature<Kelvin>
Temperature<Celsius> c =3D k; // converts from =C2=B0K to =C2=B0C

I find this reduces the amount of conversions to write (I use a neutral
unit, in this case Celsius, and I offer pre-tag to_neutral/ from_neutral
constexpr conversions through per-tag traits). I find this has some
=C2=ABplus=C2=BBes :


   - units are explicit
   - lots of conversions can be done at compile-time
   - a Temperature<R> =C2=ABknows=C2=BB what its measurement unit is, which=
 can make
   I/O nicer

Client code ends up being quite nice; such things as =C2=ABfromCelsius()=C2=
=BB feel
as an unsafe interface to me, making the user do things the type system
could do by itself. There's a way to get a fast and safe interface with
C++11 code as is.




2017-01-13 15:50 GMT-05:00 Bo Persson <bop@gmb.dk>:

> On 2017-01-12 14:07, stefan.pantos@torstonetech.com wrote:
>
>> I find my self regularly creating static factory functions on classes to
>> better describe how something is being constructed or to avoid having
>> flags passed which may have some invalid permutations. Now some times
>> this is because of poor design(Lazy/efficient) but it does make me
>> wonder if constructers with names different to their class would be
>> helpful.
>>
>> Take this contrived example:
>> |
>> classTemperature
>> {
>>    public:
>>         Temperature(floatk);
>>         Temperature(floatc,boolcelsiusOrFahrenheit);//An abomination
>>
>>         floatinKelvin()const;
>>         floatinCelsius()const;
>>         floatinFahrenheit()const;
>>    private:
>>        floatkelvin;
>> };
>>
>> autozero =3DTemperature(0);
>> autozeroC =3DTemperature(=E2=88=92273.15,true);
>> autozeroF =3DTemperature(=E2=88=92459.67,false);
>>
>> classTemperature
>> {
>>    public:
>>         structF{};
>>         structC{};
>>         structK{};
>>
>>         Temperature(floatk,K);
>>         Temperature(floatc,C);
>>         Temperature(floatf,F);
>>
>>         floatinKelvin()const;
>>         floatinCelsius()const;
>>         floatinFahrenheit()const;
>>    private:
>>        floatkelvin;
>> };
>>
>>
>> autozero =3DTemperature(0,Temperature::K());
>> autozeroC =3DTemperature(-273.15,Temperature::C());
>> autozeroF =3DTemperature(=E2=88=92459.67,Temperature::F());
>>
>> classTemperature
>> {
>>    public:
>>         staticTemperaturefromKelvin(floatk);
>>         staticTemperaturefromCelsius(floatc);
>>         staticTemperaturefromFahrenheight(floatf);
>>
>>         floatinKelvin()const;
>>         floatinCelsius()const;
>>         floatinFahrenheit()const;
>>    private:
>>        floatkelvin;
>> };
>>
>>
>> autozero =3DTemperature::fromKelvin(0);
>> autozeroC =3DTemperature::fromCelsius(-273.15);
>> autozeroF =3DTemperature::fromFahrenheight(=E2=88=92459.67);
>>
>> |
>>
>>
>> First. I think most people wouldn't like the first.
>>
>> Second. Helpful for meta programming and I quite like it in general but
>> this becomes more complex the more arguments involved. (wish I came up
>> with a better example now.).
>>
>> Third. You cannot construct the temperature on the heap. But is as clear
>> as the second.
>>
>> Would it be nice to do something like:
>> |
>> classTemperature
>> {
>>    public:
>>         constructor fromKelvin(floatk);
>>         constructor fromCelsius(floatc);
>>         constructor fromFahrenheight(floatf);
>>
>>         floatinKelvin()const;
>>         floatinCelsius()const;
>>         floatinFahrenheit()const;
>>    private:
>>        floatkelvin;
>> };
>>
>>
>> autozero_ptr =3DnewTemperature::fromKelvin(0);
>> autozeroC_ptr =3DnewTemperature::fromCelsius(-273.15);
>> autozeroF_ptr =3DnewTemperature::fromFahrenheight(=E2=88=92459.67);
>> |
>>
>> Please don't hold this against me but it does have some similarities to
>> Objective-C's init methods or other languages where the argument names
>> are used to select the call.
>>
>>
> What about a pair of user defined literals
>
> Temperature operator""_K(long double);
> Temperature operator""_C(long double);
>
>
> Then we can just do
>
> auto temp =3D 273.15_K;
>
>
>     Bo Persson
>
>
> --
> 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/is
> ocpp.org/d/msgid/std-proposals/o5bein%2476p%241%40blaine.gmane.org.
>

--=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/CAKiZDp3G3Sjnnf2am_65BHiaFH%2B2NyhTbrkVkbf62p3bQ=
iCZVg%40mail.gmail.com.

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

<div dir=3D"ltr"><div><div><div><div><div><div>When I do this, I write an e=
ssentially constexpr Temperature&lt;R&gt; where R is some empty tag class (=
Celsius, Fahrenheit, Kelvin) such that<br><br></div>auto k =3D 273_K; // Te=
mperature&lt;Kelvin&gt;<br></div>Temperature&lt;Celsius&gt; c =3D k; // con=
verts from =C2=B0K to =C2=B0C<br><br></div>I find this reduces the amount o=
f conversions to write (I use a neutral unit, in this case Celsius, and I o=
ffer pre-tag to_neutral/ from_neutral constexpr conversions through per-tag=
 traits). I find this has some =C2=ABplus=C2=BBes :<br><br></div><ul><li>un=
its are explicit</li><li>lots of conversions can be done at compile-time</l=
i><li>a Temperature&lt;R&gt; =C2=ABknows=C2=BB what its measurement unit is=
, which can make I/O nicer</li></ul></div></div>Client code ends up being q=
uite nice; such things as =C2=ABfromCelsius()=C2=BB feel as an unsafe inter=
face to me, making the user do things the type system could do by itself. T=
here&#39;s a way to get a fast and safe interface with C++11 code as is.<br=
><div><br><div><div><div><br><div><div><div><br></div></div></div></div></d=
iv></div></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">2017-01-13 15:50 GMT-05:00 Bo Persson <span dir=3D"ltr">&lt;<a href=3D"=
mailto:bop@gmb.dk" target=3D"_blank">bop@gmb.dk</a>&gt;</span>:<br><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">On 2017-01-1=
2 14:07, <a href=3D"mailto:stefan.pantos@torstonetech.com" target=3D"_blank=
">stefan.pantos@torstonetech.com</a> wrote:<br>
</div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5">
I find my self regularly creating static factory functions on classes to<br=
>
better describe how something is being constructed or to avoid having<br>
flags passed which may have some invalid permutations. Now some times<br>
this is because of poor design(Lazy/efficient) but it does make me<br>
wonder if constructers with names different to their class would be helpful=
..<br>
<br>
Take this contrived example:<br>
|<br>
classTemperature<br>
{<br>
=C2=A0 =C2=A0public:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Temperature(floatk);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Temperature(floatc,boolcelsius<wbr>OrFahrenheit=
);//An abomination<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 floatinKelvin()const;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 floatinCelsius()const;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 floatinFahrenheit()const;<br>
=C2=A0 =C2=A0private:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0floatkelvin;<br>
};<br>
<br>
autozero =3DTemperature(0);<br>
autozeroC =3DTemperature(=E2=88=92273.15,true);<br>
autozeroF =3DTemperature(=E2=88=92459.67,false);<br>
<br>
classTemperature<br>
{<br>
=C2=A0 =C2=A0public:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 structF{};<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 structC{};<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 structK{};<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Temperature(floatk,K);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Temperature(floatc,C);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Temperature(floatf,F);<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 floatinKelvin()const;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 floatinCelsius()const;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 floatinFahrenheit()const;<br>
=C2=A0 =C2=A0private:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0floatkelvin;<br>
};<br>
<br>
<br>
autozero =3DTemperature(0,Temperature::K(<wbr>));<br>
autozeroC =3DTemperature(-273.15,Temperatu<wbr>re::C());<br>
autozeroF =3DTemperature(=E2=88=92459.67,Temperatu<wbr>re::F());<br>
<br>
classTemperature<br>
{<br>
=C2=A0 =C2=A0public:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 staticTemperaturefromKelvin(fl<wbr>oatk);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 staticTemperaturefromCelsius(f<wbr>loatc);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 staticTemperaturefromFahrenhei<wbr>ght(floatf);=
<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 floatinKelvin()const;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 floatinCelsius()const;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 floatinFahrenheit()const;<br>
=C2=A0 =C2=A0private:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0floatkelvin;<br>
};<br>
<br>
<br>
autozero =3DTemperature::fromKelvin(0);<br>
autozeroC =3DTemperature::fromCelsius(-273<wbr>.15);<br></div></div>
autozeroF =3DTemperature::fromFahrenheight<wbr>(=E2=88=92459.67);<span clas=
s=3D""><br>
<br>
|<br>
<br>
<br>
First. I think most people wouldn&#39;t like the first.<br>
<br>
Second. Helpful for meta programming and I quite like it in general but<br>
this becomes more complex the more arguments involved. (wish I came up<br>
with a better example now.).<br>
<br>
Third. You cannot construct the temperature on the heap. But is as clear<br=
>
as the second.<br>
<br>
Would it be nice to do something like:<br>
|<br>
classTemperature<br>
{<br>
=C2=A0 =C2=A0public:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 constructor fromKelvin(floatk);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 constructor fromCelsius(floatc);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 constructor fromFahrenheight(floatf);<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 floatinKelvin()const;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 floatinCelsius()const;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 floatinFahrenheit()const;<br>
=C2=A0 =C2=A0private:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0floatkelvin;<br>
};<br>
<br>
<br>
autozero_ptr =3DnewTemperature::fromKelvin(0)<wbr>;<br>
autozeroC_ptr =3DnewTemperature::fromCelsius(-<wbr>273.15);<br></span>
autozeroF_ptr =3DnewTemperature::fromFahrenhei<wbr>ght(=E2=88=92459.67);<sp=
an class=3D""><br>
|<br>
<br>
Please don&#39;t hold this against me but it does have some similarities to=
<br>
Objective-C&#39;s init methods or other languages where the argument names<=
br>
are used to select the call.<br>
<br>
</span></blockquote>
<br>
What about a pair of user defined literals<br>
<br>
Temperature operator&quot;&quot;_K(long double);<br>
Temperature operator&quot;&quot;_C(long double);<br>
<br>
<br>
Then we can just do<br>
<br>
auto temp =3D 273.15_K;<br>
<br>
<br>
=C2=A0 =C2=A0 Bo Persson<span class=3D""><br>
<br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isoc<wbr>pp.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/o5bein%2476p%241%40blaine.gmane.org" =
rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/is<wbr>ocp=
p.org/d/msgid/std-proposals<wbr>/o5bein%2476p%241%40blaine.<wbr>gmane.org</=
a>.<br>
</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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKiZDp3G3Sjnnf2am_65BHiaFH%2B2NyhTbr=
kVkbf62p3bQiCZVg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp3G3Sjnnf=
2am_65BHiaFH%2B2NyhTbrkVkbf62p3bQiCZVg%40mail.gmail.com</a>.<br />

--94eb2c1236fe02e8ee0546005295--

.

------=_Part_675_692175346.1484342683512
Content-Type: multipart/alternative;
 boundary="----=_Part_676_662703515.1484342683512"

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



On Friday, January 13, 2017 at 4:14:35 PM UTC-5, Patrice Roy wrote:
>
> When I do this, I write an essentially constexpr Temperature<R> where R i=
s=20
> some empty tag class (Celsius, Fahrenheit, Kelvin) such that
>
> auto k =3D 273_K; // Temperature<Kelvin>
> Temperature<Celsius> c =3D k; // converts from =C2=B0K to =C2=B0C
>
> I find this reduces the amount of conversions to write (I use a neutral=
=20
> unit, in this case Celsius, and I offer pre-tag to_neutral/ from_neutral=
=20
> constexpr conversions through per-tag traits). I find this has some=20
> =C2=ABplus=C2=BBes :
>
>
>    - units are explicit
>    - lots of conversions can be done at compile-time
>    - a Temperature<R> =C2=ABknows=C2=BB what its measurement unit is, whi=
ch can=20
>    make I/O nicer
>
> Client code ends up being quite nice; such things as =C2=ABfromCelsius()=
=C2=BB feel=20
> as an unsafe interface to me, making the user do things the type system=
=20
> could do by itself. There's a way to get a fast and safe interface with=
=20
> C++11 code as is.
>

Such code also has a tendency to be viral. I can't merely take a=20
`Temperature`; I have to express that I want a temperature in some=20
particular unit. I don't care what units you provide the temperature in;=20
that's the whole point of having such a type. But when I do my math, I'm=20
going to get the temperature in a particular unit.

Why should the unit I intend to use internally be part of my function's=20
interface?

I have an Angle type. I like the fact that you can add `Angle`s together,=
=20
or multiply an `Angle` by a scalar. I like the fact that, if you want to=20
get that value as a number, you need to ask for a specific unit. And I like=
=20
the fact that the unit is *not* part of the type. Because the function to=
=20
compute a rotation matrix doesn't care if you pass degrees or radians; it=
=20
simply takes an `Angle`.

--=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/82ffdece-8651-49cc-b41a-39e203416181%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Friday, January 13, 2017 at 4:14:35 PM UTC-5, P=
atrice Roy 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><div><div><div><div><div>When I do this, I write an essentially co=
nstexpr Temperature&lt;R&gt; where R is some empty tag class (Celsius, Fahr=
enheit, Kelvin) such that<br><br></div>auto k =3D 273_K; // Temperature&lt;=
Kelvin&gt;<br></div>Temperature&lt;Celsius&gt; c =3D k; // converts from =
=C2=B0K to =C2=B0C<br><br></div>I find this reduces the amount of conversio=
ns to write (I use a neutral unit, in this case Celsius, and I offer pre-ta=
g to_neutral/ from_neutral constexpr conversions through per-tag traits). I=
 find this has some =C2=ABplus=C2=BBes :<br><br></div><ul><li>units are exp=
licit</li><li>lots of conversions can be done at compile-time</li><li>a Tem=
perature&lt;R&gt; =C2=ABknows=C2=BB what its measurement unit is, which can=
 make I/O nicer</li></ul></div></div>Client code ends up being quite nice; =
such things as =C2=ABfromCelsius()=C2=BB feel as an unsafe interface to me,=
 making the user do things the type system could do by itself. There&#39;s =
a way to get a fast and safe interface with C++11 code as is.</div></blockq=
uote><div><br>Such code also has a tendency to be viral. I can&#39;t merely=
 take a `Temperature`; I have to express that I want a temperature in some =
particular unit. I don&#39;t care what units you provide the temperature in=
; that&#39;s the whole point of having such a type. But when I do my math, =
I&#39;m going to get the temperature in a particular unit.<br><br>Why shoul=
d the unit I intend to use internally be part of my function&#39;s interfac=
e?<br><br>I have an Angle type. I like the fact that you can add `Angle`s t=
ogether, or multiply an `Angle` by a scalar. I like the fact that, if you w=
ant to get that value as a number, you need to ask for a specific unit. And=
 I like the fact that the unit is <i>not</i> part of the type. Because the =
function to compute a rotation matrix doesn&#39;t care if you pass degrees =
or radians; it simply takes an `Angle`.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/82ffdece-8651-49cc-b41a-39e203416181%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/82ffdece-8651-49cc-b41a-39e203416181=
%40isocpp.org</a>.<br />

------=_Part_676_662703515.1484342683512--

------=_Part_675_692175346.1484342683512--

.

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

Really named constructors isn't specifically the case where your values=20
have units which can help specify the constructor, although it can be=20
helpful. Here is some more discussion:
https://isocpp.org/wiki/faq/ctors#named-ctor-idiom

(as Nicol pointed out static member functions work well for this already.)

Another example might be:
class Config
{
    public:
      static Config fromString(const string& xml);
      static Config fromFile(const string& filename);
};

One aim would be to make code more readable and maintainable by default.=20
Obviously everyone should name their variables sensibly but we know that it=
=20
is one of the hardest tasks in computing and you cannot rely upon it. What=
=20
made sense to one person doesn't necessarily make sense to another person=
=20
in future.

Config myconfig(f);  //Is f a string with the content of the file or a path=
=20
to the file?
auto myconfig =3D Config::fromString(f);//Much more clear, to me. I even ha=
ve=20
a good idea of what type f is.

How about this example (ok you could design this differently, maybe using=
=20
polymorphism)?
class  Config
{
   public:
      static Config lazyFromFile(const string& filename)
      {
          Config result(filename, true);  // Do I know what true means=20
here? You can make a guess but you cannot be certain.
      }

      static Config fromFile(const string& filename)
      {
          Config result(filename, false);  // Do I know what false means=20
here? You can make a guess but you cannot be certain.
      }      //...
   private:
      Config(const string& filename_, bool loadLazily =3D false) : loaded(!
loadLazily), filename(filename_)
      {
            if (!loadLazily)
            {
               data =3D loadDate(filename);
            }
      }

      bool loaded;
      string filename;
      map<string, string> data;
};

// Would this be better?
class  Config
{
   public:
      constructor lazyFromFile(const string& filename_) : loaded(false),=20
filename(filename_)
      {}


      constructor fromFile(const string& filename_) :=20
Config::lazyFromFile(filename_)
      {
           data =3D loadDate(filename);
           loaded =3D true;
      }
//...
   private:

      bool loaded;
      string filename;
      map<string, string> data;
};

It could also be helpful in the case of refactoring as you can simply=20
change the name of the constructor you are refactoring and you know that it=
=20
won't compile in instance you haven't changed. In an ideal world everyone=
=20
would have access to suitably powerful refactoring tools but that isn't=20
always the case.


On Friday, 13 January 2017 21:14:35 UTC, Patrice Roy wrote:
>
> When I do this, I write an essentially constexpr Temperature<R> where R i=
s=20
> some empty tag class (Celsius, Fahrenheit, Kelvin) such that
>
> auto k =3D 273_K; // Temperature<Kelvin>
> Temperature<Celsius> c =3D k; // converts from =C2=B0K to =C2=B0C
>
> I find this reduces the amount of conversions to write (I use a neutral=
=20
> unit, in this case Celsius, and I offer pre-tag to_neutral/ from_neutral=
=20
> constexpr conversions through per-tag traits). I find this has some=20
> =C2=ABplus=C2=BBes :
>
>
>    - units are explicit
>    - lots of conversions can be done at compile-time
>    - a Temperature<R> =C2=ABknows=C2=BB what its measurement unit is, whi=
ch can=20
>    make I/O nicer
>
> Client code ends up being quite nice; such things as =C2=ABfromCelsius()=
=C2=BB feel=20
> as an unsafe interface to me, making the user do things the type system=
=20
> could do by itself. There's a way to get a fast and safe interface with=
=20
> C++11 code as is.
>
>
>
>
> 2017-01-13 15:50 GMT-05:00 Bo Persson <b...@gmb.dk <javascript:>>:
>
>> On 2017-01-12 14:07, stefan...@torstonetech.com <javascript:> wrote:
>>
>>> I find my self regularly creating static factory functions on classes t=
o
>>> better describe how something is being constructed or to avoid having
>>> flags passed which may have some invalid permutations. Now some times
>>> this is because of poor design(Lazy/efficient) but it does make me
>>> wonder if constructers with names different to their class would be=20
>>> helpful.
>>>
>>> Take this contrived example:
>>> |
>>> classTemperature
>>> {
>>>    public:
>>>         Temperature(floatk);
>>>         Temperature(floatc,boolcelsiusOrFahrenheit);//An abomination
>>>
>>>         floatinKelvin()const;
>>>         floatinCelsius()const;
>>>         floatinFahrenheit()const;
>>>    private:
>>>        floatkelvin;
>>> };
>>>
>>> autozero =3DTemperature(0);
>>> autozeroC =3DTemperature(=E2=88=92273.15,true);
>>> autozeroF =3DTemperature(=E2=88=92459.67,false);
>>>
>>> classTemperature
>>> {
>>>    public:
>>>         structF{};
>>>         structC{};
>>>         structK{};
>>>
>>>         Temperature(floatk,K);
>>>         Temperature(floatc,C);
>>>         Temperature(floatf,F);
>>>
>>>         floatinKelvin()const;
>>>         floatinCelsius()const;
>>>         floatinFahrenheit()const;
>>>    private:
>>>        floatkelvin;
>>> };
>>>
>>>
>>> autozero =3DTemperature(0,Temperature::K());
>>> autozeroC =3DTemperature(-273.15,Temperature::C());
>>> autozeroF =3DTemperature(=E2=88=92459.67,Temperature::F());
>>>
>>> classTemperature
>>> {
>>>    public:
>>>         staticTemperaturefromKelvin(floatk);
>>>         staticTemperaturefromCelsius(floatc);
>>>         staticTemperaturefromFahrenheight(floatf);
>>>
>>>         floatinKelvin()const;
>>>         floatinCelsius()const;
>>>         floatinFahrenheit()const;
>>>    private:
>>>        floatkelvin;
>>> };
>>>
>>>
>>> autozero =3DTemperature::fromKelvin(0);
>>> autozeroC =3DTemperature::fromCelsius(-273.15);
>>> autozeroF =3DTemperature::fromFahrenheight(=E2=88=92459.67);
>>>
>>> |
>>>
>>>
>>> First. I think most people wouldn't like the first.
>>>
>>> Second. Helpful for meta programming and I quite like it in general but
>>> this becomes more complex the more arguments involved. (wish I came up
>>> with a better example now.).
>>>
>>> Third. You cannot construct the temperature on the heap. But is as clea=
r
>>> as the second.
>>>
>>> Would it be nice to do something like:
>>> |
>>> classTemperature
>>> {
>>>    public:
>>>         constructor fromKelvin(floatk);
>>>         constructor fromCelsius(floatc);
>>>         constructor fromFahrenheight(floatf);
>>>
>>>         floatinKelvin()const;
>>>         floatinCelsius()const;
>>>         floatinFahrenheit()const;
>>>    private:
>>>        floatkelvin;
>>> };
>>>
>>>
>>> autozero_ptr =3DnewTemperature::fromKelvin(0);
>>> autozeroC_ptr =3DnewTemperature::fromCelsius(-273.15);
>>> autozeroF_ptr =3DnewTemperature::fromFahrenheight(=E2=88=92459.67);
>>> |
>>>
>>> Please don't hold this against me but it does have some similarities to
>>> Objective-C's init methods or other languages where the argument names
>>> are used to select the call.
>>>
>>>
>> What about a pair of user defined literals
>>
>> Temperature operator""_K(long double);
>> Temperature operator""_C(long double);
>>
>>
>> Then we can just do
>>
>> auto temp =3D 273.15_K;
>>
>>
>>     Bo Persson
>>
>>
>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> 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=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/o5bein%2476=
p%241%40blaine.gmane.org
>> .
>>
>
>
--=20
The contents (including attachments) of this email are strictly=20
confidential, intended for the addressee(s) only and may be legally=20
privileged.  If you are not the intended recipient, please contact the=20
sender immediately and delete all copies of this email without distributing=
=20
it further in any way.  Torstone Technology Limited, its affiliates and=20
staff do not accept any liability for the contents of the message, and the=
=20
sending of this message is not intended to form a contract with the=20
recipient.  Torstone Technology Limited is registered in England and Wales=
=20
with company number 07490275 and registered office at 8 Lloyd's Avenue,=20
London EC3N 3EL, United Kingdom.

--=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/4ad0c3ea-0e03-4bf9-a1d5-6425fd362317%40isocpp.or=
g.

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

<div dir=3D"ltr"><div style=3D"font-family: arial, sans-serif;">Really name=
d constructors isn&#39;t specifically the case where your values have units=
 which can help specify the constructor, although it can be helpful. Here i=
s some more discussion:</div><div style=3D"font-family: arial, sans-serif;"=
><a href=3D"https://isocpp.org/wiki/faq/ctors#named-ctor-idiom" target=3D"_=
blank" data-saferedirecturl=3D"https://www.google.com/url?hl=3Den-GB&amp;q=
=3Dhttps://isocpp.org/wiki/faq/ctors%23named-ctor-idiom&amp;source=3Dgmail&=
amp;ust=3D1484617280074000&amp;usg=3DAFQjCNG2PE1IYrRmTLu9RkPvKcyUwrg8EQ" st=
yle=3D"color: rgb(17, 85, 204);">https://isocpp.org/wiki/faq/<wbr>ctors#nam=
ed-ctor-idiom</a></div><div style=3D"font-family: arial, sans-serif;"><br><=
/div><div style=3D"font-family: arial, sans-serif;">(as Nicol pointed out s=
tatic member functions work well for this already.)</div><div style=3D"font=
-family: arial, sans-serif;"><br></div><div style=3D"font-family: arial, sa=
ns-serif;">Another example might be:</div><div style=3D"font-family: arial,=
 sans-serif;"><div class=3D"prettyprint" style=3D"background-color: rgb(250=
, 250, 250); border: 1px solid rgb(187, 187, 187); word-wrap: break-word;">=
<code class=3D"prettyprint"><div class=3D"subprettyprint"><font color=3D"#6=
60066"><span style=3D"color: #008;" class=3D"styled-by-prettify">class</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #606;" class=3D"styled-by-prettify">Config</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #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"col=
or: #008;" class=3D"styled-by-prettify">public</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">static</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" =
class=3D"styled-by-prettify">Config</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> fromString</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">const</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">string</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&=
amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> xml</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =
=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">sta=
tic</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #606;" class=3D"styled-by-prettify">Config</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> fromFile</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">const</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">string</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">&amp;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> filename</span><span style=3D"color: #660;" 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></span></font></div></code></div><br>One aim would be to make code mo=
re readable and maintainable by default. Obviously everyone should name the=
ir variables sensibly but we know that it is one of the hardest tasks in co=
mputing and you cannot rely upon it. What made sense to one person doesn&#3=
9;t necessarily make sense to another person in future.</div><div style=3D"=
font-family: arial, sans-serif;"><br></div><div style=3D"font-family: arial=
, sans-serif;"><div class=3D"prettyprint" style=3D"background-color: rgb(25=
0, 250, 250); border: 1px solid rgb(187, 187, 187); word-wrap: break-word;"=
><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"c=
olor: #606;" class=3D"styled-by-prettify">Config</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> myconfig</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">f</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> =C2=A0</span><span style=3D"color: #800;" class=3D"styled-by-pr=
ettify">//Is f a string with the content of the file or a path to the file?=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> myconfig </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=
: #606;" class=3D"styled-by-prettify">Config</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">fromString</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">f</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">);</span><span style=3D"color: #800;" class=3D"styled-by-prettify">=
//Much more clear, to me. I even have a good idea of what type f is.</span>=
<font color=3D"#666600"></font></div></code></div><div style=3D"font-family=
: arial, sans-serif;"><br></div>How about this example (ok you could design=
 this differently, maybe using polymorphism)?</div><div style=3D"font-famil=
y: arial, sans-serif;"><div class=3D"prettyprint" style=3D"background-color=
: rgb(250, 250, 250); border: 1px solid rgb(187, 187, 187); word-wrap: brea=
k-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">class</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> =C2=A0</span><span style=3D=
"color: #606;" class=3D"styled-by-prettify">Config</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br>=C2=A0 =C2=A0</span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">public</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">static</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D=
"styled-by-prettify">Config</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> lazyFromFile</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">const</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">str=
ing</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> filename</s=
pan><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 style=3D"color: #660;" class=3D"styled-by-prettify">{</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #606;" class=3D"style=
d-by-prettify">Config</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> result</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">f=
ilename</span><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: #008;" class=3D"styled-by-prettify">true</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> =C2=A0</span><span style=3D"color:=
 #800;" class=3D"styled-by-prettify">// Do I know what true means here? You=
 can make a guess but you cannot be certain.</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br></span><div style=3D"color: rgb=
(34, 34, 34); font-family: arial, sans-serif; background-color: rgb(255, 25=
5, 255);"><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></s=
pan></div><span style=3D"color: #000;" class=3D"styled-by-prettify">=C2=A0 =
=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">static</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Config</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> fromFile</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span =
style=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">string</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">&amp;</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> filename</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><spa=
n style=3D"color: #606;" class=3D"styled-by-prettify">Config</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> result</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">filename</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">false</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> =C2=A0</span><span style=3D"color: #800;" class=3D"styled-by-prettify=
">// Do I know what false means here? You can make a guess but you cannot b=
e certain.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> =C2=A0 =C2=A0 =C2=A0</span><span style=3D"color: #800;" class=3D"sty=
led-by-prettify">//...</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br>=C2=A0 =C2=A0</span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">private</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">Config</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">const</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">str=
ing</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> filename_</=
span><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: #008;" class=3D"styled-by-prettify">bool</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> loadLazily </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">false</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: #660;" class=3D"styled-by-pret=
tify">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> lo=
aded</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(!</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">loadLazily</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">),</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> filename</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">filename_</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>if</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">(!</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">loadLazily</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 </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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0data </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> loadDate</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">file</span><font color=3D"#666600"><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">name</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">);</span></font><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">bool</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> loaded</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 =C2=A0 </span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">string</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> filename</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br>=C2=A0 =C2=A0 =C2=A0 map</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">&lt;</span><font color=3D"#000000"><span style=3D"=
color: #008;" class=3D"styled-by-prettify">string</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">string</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> data</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">;</span></font><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><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: #800;" class=3D"styled-by-prettify">// Would thi=
s be better?</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">clas=
s</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =C2=A0</=
span><span style=3D"color: #606;" class=3D"styled-by-prettify">Config</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>=C2=A0 =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 =C2=A0 =C2=A0 </span><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">constructor</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">lazyFromFile</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">const</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">string</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&amp;</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> filename_</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">) : loaded(false), filename(filename_)</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span=
 style=3D"color: rgb(102, 102, 0); font-family: arial, sans-serif;">}</span=
></div><div class=3D"subprettyprint"><div style=3D"color: rgb(34, 34, 34); =
font-family: arial, sans-serif; background-color: rgb(255, 255, 255);"><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=
=A0=C2=A0</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
span style=3D"color: rgb(0, 0, 136);">constructor</span>=C2=A0</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">fromFile</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">const</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">string</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&amp;</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> filename_</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">) : Config::lazyFromFile(filename_)</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </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: #000;" class=3D"styled-by-prettify">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0data =3D loadDate(filename);<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0loaded =3D true;<br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">}<br></span><span style=3D"color: =
#800;" class=3D"styled-by-prettify">//...</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0</span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">private</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">bool</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> loaded</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><span class=3D"styled-by-prettify"><br>=C2=A0 =
=C2=A0 =C2=A0=C2=A0</span><span class=3D"styled-by-prettify" style=3D"color=
: rgb(0, 0, 136);">string</span><span class=3D"styled-by-prettify">=C2=A0fi=
lename</span><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 10=
2, 0);">;</span><br>=C2=A0 =C2=A0 =C2=A0 map</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">&lt;</span><font color=3D"#000000"><span =
style=3D"color: #008;" class=3D"styled-by-prettify">string</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: #008;"=
 class=3D"styled-by-prettify">string</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> data</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">;</span></font><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">};</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br></span></div></code></div><br>It could also be helpful in the case of re=
factoring as you can simply change the name of the constructor you are refa=
ctoring and you know that it won&#39;t compile in instance you haven&#39;t =
changed. In an ideal world everyone would have access to suitably powerful =
refactoring tools but that isn&#39;t always the case.</div><div style=3D"fo=
nt-family: arial, sans-serif;"><br></div><br>On Friday, 13 January 2017 21:=
14:35 UTC, Patrice Roy  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><div><div><div><div><div>When I do this, I write an e=
ssentially constexpr Temperature&lt;R&gt; where R is some empty tag class (=
Celsius, Fahrenheit, Kelvin) such that<br><br></div>auto k =3D 273_K; // Te=
mperature&lt;Kelvin&gt;<br></div>Temperature&lt;Celsius&gt; c =3D k; // con=
verts from =C2=B0K to =C2=B0C<br><br></div>I find this reduces the amount o=
f conversions to write (I use a neutral unit, in this case Celsius, and I o=
ffer pre-tag to_neutral/ from_neutral constexpr conversions through per-tag=
 traits). I find this has some =C2=ABplus=C2=BBes :<br><br></div><ul><li>un=
its are explicit</li><li>lots of conversions can be done at compile-time</l=
i><li>a Temperature&lt;R&gt; =C2=ABknows=C2=BB what its measurement unit is=
, which can make I/O nicer</li></ul></div></div>Client code ends up being q=
uite nice; such things as =C2=ABfromCelsius()=C2=BB feel as an unsafe inter=
face to me, making the user do things the type system could do by itself. T=
here&#39;s a way to get a fast and safe interface with C++11 code as is.<br=
><div><br><div><div><div><br><div><div><div><br></div></div></div></div></d=
iv></div></div></div><div><br><div class=3D"gmail_quote">2017-01-13 15:50 G=
MT-05:00 Bo Persson <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D=
"_blank" gdf-obfuscated-mailto=3D"_h0PEjHxBgAJ" rel=3D"nofollow" onmousedow=
n=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=
=3D&#39;javascript:&#39;;return true;">b...@gmb.dk</a>&gt;</span>:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div><div>On 2017-01-12 14:07, <a href=3D"javascr=
ipt:" target=3D"_blank" gdf-obfuscated-mailto=3D"_h0PEjHxBgAJ" rel=3D"nofol=
low" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=
=3D"this.href=3D&#39;javascript:&#39;;return true;">stefan...@torstonetech.=
com</a> wrote:<br>
</div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div><div>
I find my self regularly creating static factory functions on classes to<br=
>
better describe how something is being constructed or to avoid having<br>
flags passed which may have some invalid permutations. Now some times<br>
this is because of poor design(Lazy/efficient) but it does make me<br>
wonder if constructers with names different to their class would be helpful=
..<br>
<br>
Take this contrived example:<br>
|<br>
classTemperature<br>
{<br>
=C2=A0 =C2=A0public:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Temperature(floatk);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Temperature(floatc,<wbr>boolcelsiusOrFahrenheit=
);//An abomination<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 floatinKelvin()const;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 floatinCelsius()const;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 floatinFahrenheit()const;<br>
=C2=A0 =C2=A0private:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0floatkelvin;<br>
};<br>
<br>
autozero =3DTemperature(0);<br>
autozeroC =3DTemperature(=E2=88=92273.15,true);<br>
autozeroF =3DTemperature(=E2=88=92459.67,false);<br>
<br>
classTemperature<br>
{<br>
=C2=A0 =C2=A0public:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 structF{};<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 structC{};<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 structK{};<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Temperature(floatk,K);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Temperature(floatc,C);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Temperature(floatf,F);<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 floatinKelvin()const;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 floatinCelsius()const;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 floatinFahrenheit()const;<br>
=C2=A0 =C2=A0private:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0floatkelvin;<br>
};<br>
<br>
<br>
autozero =3DTemperature(0,Temperature::K(<wbr>));<br>
autozeroC =3DTemperature(-273.15,<wbr>Temperature::C());<br>
autozeroF =3DTemperature(=E2=88=92459.67,<wbr>Temperature::F());<br>
<br>
classTemperature<br>
{<br>
=C2=A0 =C2=A0public:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 staticTemperaturefromKelvin(<wbr>floatk);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 staticTemperaturefromCelsius(<wbr>floatc);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 staticTemperaturefromFahrenhei<wbr>ght(floatf);=
<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 floatinKelvin()const;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 floatinCelsius()const;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 floatinFahrenheit()const;<br>
=C2=A0 =C2=A0private:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0floatkelvin;<br>
};<br>
<br>
<br>
autozero =3DTemperature::fromKelvin(0);<br>
autozeroC =3DTemperature::fromCelsius(-<wbr>273.15);<br></div></div>
autozeroF =3DTemperature::<wbr>fromFahrenheight(=E2=88=92459.67);<span><br>
<br>
|<br>
<br>
<br>
First. I think most people wouldn&#39;t like the first.<br>
<br>
Second. Helpful for meta programming and I quite like it in general but<br>
this becomes more complex the more arguments involved. (wish I came up<br>
with a better example now.).<br>
<br>
Third. You cannot construct the temperature on the heap. But is as clear<br=
>
as the second.<br>
<br>
Would it be nice to do something like:<br>
|<br>
classTemperature<br>
{<br>
=C2=A0 =C2=A0public:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 constructor fromKelvin(floatk);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 constructor fromCelsius(floatc);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 constructor fromFahrenheight(floatf);<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 floatinKelvin()const;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 floatinCelsius()const;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 floatinFahrenheit()const;<br>
=C2=A0 =C2=A0private:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0floatkelvin;<br>
};<br>
<br>
<br>
autozero_ptr =3DnewTemperature::fromKelvin(0)<wbr>;<br>
autozeroC_ptr =3DnewTemperature::fromCelsius(-<wbr>273.15);<br></span>
autozeroF_ptr =3DnewTemperature::<wbr>fromFahrenheight(=E2=88=92459.67);<sp=
an><br>
|<br>
<br>
Please don&#39;t hold this against me but it does have some similarities to=
<br>
Objective-C&#39;s init methods or other languages where the argument names<=
br>
are used to select the call.<br>
<br>
</span></blockquote>
<br>
What about a pair of user defined literals<br>
<br>
Temperature operator&quot;&quot;_K(long double);<br>
Temperature operator&quot;&quot;_C(long double);<br>
<br>
<br>
Then we can just do<br>
<br>
auto temp =3D 273.15_K;<br>
<br>
<br>
=C2=A0 =C2=A0 Bo Persson<span><br>
<br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
_h0PEjHxBgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;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"_h0PEjHxBgAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@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/o5bein%2476p%241%40blaine.gmane.org" =
rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;https://=
groups.google.com/a/isocpp.org/d/msgid/std-proposals/o5bein%2476p%241%40bla=
ine.gmane.org&#39;;return true;" onclick=3D"this.href=3D&#39;https://groups=
..google.com/a/isocpp.org/d/msgid/std-proposals/o5bein%2476p%241%40blaine.gm=
ane.org&#39;;return true;">https://groups.google.com/a/<wbr>isocpp.org/d/ms=
gid/std-<wbr>proposals/o5bein%2476p%241%<wbr>40blaine.gmane.org</a>.<br>
</blockquote></div><br></div>
</blockquote></div>
<br>
<font face=3D"Arial, Helvetica, sans-serif"><span style=3D"font-size:1.3em"=
>The contents
(including attachments) of this email are strictly confidential, intended f=
or
the addressee(s) only and may be legally privileged.=C2=A0 If you are not t=
he intended
recipient, please contact the sender immediately and delete all copies of t=
his
email without distributing it further in any way.=C2=A0 Torstone Technology
Limited, its affiliates and staff do not accept any liability for the conte=
nts
of the message, and the sending of this message is not intended to form a
contract with the recipient. =C2=A0Torstone Technology Limited is registere=
d in England and Wales with company number 07490275 and registered office a=
t 8 Lloyd&#39;s Avenue, London EC3N 3EL, United Kingdom.</span></font>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4ad0c3ea-0e03-4bf9-a1d5-6425fd362317%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4ad0c3ea-0e03-4bf9-a1d5-6425fd362317=
%40isocpp.org</a>.<br />

------=_Part_1127_636178283.1484560228326--

.

------=_Part_1247_336044815.1484581010124
Content-Type: multipart/alternative;
 boundary="----=_Part_1248_1220787415.1484581010124"

------=_Part_1248_1220787415.1484581010124
Content-Type: text/plain; charset=UTF-8

On Monday, January 16, 2017 at 4:50:28 AM UTC-5, stefan...@torstonetech.com
wrote:
>
> Really named constructors isn't specifically the case where your values
> have units which can help specify the constructor, although it can be
> helpful. Here is some more discussion:
> https://isocpp.org/wiki/faq/ctors#named-ctor-idiom
>
> (as Nicol pointed out static member functions work well for this already.)
>
> Another example might be:
> class Config
> {
>     public:
>       static Config fromString(const string& xml);
>       static Config fromFile(const string& filename);
> };
>
> One aim would be to make code more readable and maintainable by default.
> Obviously everyone should name their variables sensibly but we know that it
> is one of the hardest tasks in computing and you cannot rely upon it. What
> made sense to one person doesn't necessarily make sense to another person
> in future.
>
> Config myconfig(f);  //Is f a string with the content of the file or a
> path to the file?
> auto myconfig = Config::fromString(f);//Much more clear, to me. I even
> have a good idea of what type f is.
>
>
Or you could use `std::filesystem::path` for the "from-file" version.
Admittedly, that's simply a poorly-chosen example, but you'd be surprised
how many constructors can be differentiated just by judicious use of proper
types. It's one of the reasons why C++ needs strong aliases so badly: so
that we can give a generic type meaning without making the use of that type
difficult.


> How about this example (ok you could design this differently, maybe using
> polymorphism)?
>

Easily differentiated with an enum:

enum class ConfigLoad
{
    lazy;
    standard;
};

Config c(someString, ConfigLoad::lazy);

And, more to the point, we still get to do this:

std::any a(in_place_type<Config>, someString, ConfigLoad::lazy);

To do that with your named constructors, you'd have to invent a whole new
indirect initialization mechanism, as others have suggested. Which also
means that any user who creates a type with indirect initialization needs
to know how to build this new mechanism *in addition* to the old one.

Finding ways to live with a single constructor namespace is ultimately
preferable to using named constructors. Even if it leads you to doing
something like this:

Config c(Config::FromString, someString);

I prefer this syntax over named constructors as a language feature or
static members as named constructors. This way works indirectly, while
neither of those features can do so with existing library stuff.

--
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/cb6f76b8-e098-4aea-ac69-8d7317cca1f0%40isocpp.org.

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

<div dir=3D"ltr">On Monday, January 16, 2017 at 4:50:28 AM UTC-5, stefan...=
@torstonetech.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr"><div style=3D"font-family:arial,sans-serif">Really named constru=
ctors isn&#39;t specifically the case where your values have units which ca=
n help specify the constructor, although it can be helpful. Here is some mo=
re discussion:</div><div style=3D"font-family:arial,sans-serif"><a href=3D"=
https://isocpp.org/wiki/faq/ctors#named-ctor-idiom" style=3D"color:rgb(17,8=
5,204)" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;=
https://www.google.com/url?q\x3dhttps%3A%2F%2Fisocpp.org%2Fwiki%2Ffaq%2Fcto=
rs%23named-ctor-idiom\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF2M-kGWHdp3Vl=
OwJLm1UMfkxNQYA&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.=
google.com/url?q\x3dhttps%3A%2F%2Fisocpp.org%2Fwiki%2Ffaq%2Fctors%23named-c=
tor-idiom\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF2M-kGWHdp3VlOwJLm1UMfkxN=
QYA&#39;;return true;">https://isocpp.org/wiki/faq/<wbr>ctors#named-ctor-id=
iom</a></div><div style=3D"font-family:arial,sans-serif"><br></div><div sty=
le=3D"font-family:arial,sans-serif">(as Nicol pointed out static member fun=
ctions work well for this already.)</div><div style=3D"font-family:arial,sa=
ns-serif"><br></div><div style=3D"font-family:arial,sans-serif">Another exa=
mple might be:</div><div style=3D"font-family:arial,sans-serif"><div style=
=3D"background-color:rgb(250,250,250);border:1px solid rgb(187,187,187);wor=
d-wrap:break-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">Config</span><span style=3D"color:#000"><br></span><span style=3D"colo=
r:#660">{</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span s=
tyle=3D"color:#008">public</span><span style=3D"color:#660">:</span><span s=
tyle=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#0=
08">static</span><span style=3D"color:#000"> </span><span style=3D"color:#6=
06">Config</span><span style=3D"color:#000"> fromString</span><span style=
=3D"color:#660">(</span><span style=3D"color:#008">const</span><span style=
=3D"color:#000"> </span><span style=3D"color:#008">string</span><span style=
=3D"color:#660">&amp;</span><span style=3D"color:#000"> xml</span><span sty=
le=3D"color:#660">);</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=
=A0 </span><span style=3D"color:#008">static</span><span style=3D"color:#00=
0"> </span><span style=3D"color:#606">Config</span><span style=3D"color:#00=
0"> fromFile</span><span style=3D"color:#660">(</span><span style=3D"color:=
#008">const</span><span style=3D"color:#000"> </span><span style=3D"color:#=
008">string</span><span style=3D"color:#660">&amp;</span><span style=3D"col=
or:#000"> filename</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><br>One aim would be to ma=
ke code more readable and maintainable by default. Obviously everyone shoul=
d name their variables sensibly but we know that it is one of the hardest t=
asks in computing and you cannot rely upon it. What made sense to one perso=
n doesn&#39;t necessarily make sense to another person in future.</div><div=
 style=3D"font-family:arial,sans-serif"><br></div><div style=3D"font-family=
:arial,sans-serif"><div style=3D"background-color:rgb(250,250,250);border:1=
px solid rgb(187,187,187);word-wrap:break-word"><code><div><span style=3D"c=
olor:#606">Config</span><span style=3D"color:#000"> myconfig</span><span st=
yle=3D"color:#660">(</span><span style=3D"color:#000">f</span><span style=
=3D"color:#660">);</span><span style=3D"color:#000"> =C2=A0</span><span sty=
le=3D"color:#800">//Is f a string with the content of the file or a path to=
 the file?</span><span style=3D"color:#000"><br></span><span style=3D"color=
:#008">auto</span><span style=3D"color:#000"> myconfig </span><span style=
=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><span style=3D=
"color:#606">Config</span><span style=3D"color:#660">::</span><span style=
=3D"color:#000">fromString</span><span style=3D"color:#660">(</span><span s=
tyle=3D"color:#000">f</span><span style=3D"color:#660">);</span><span style=
=3D"color:#800">//Much more clear, to me. I even have a good idea of what t=
ype f is.</span><font color=3D"#666600"></font></div></code></div><div styl=
e=3D"font-family:arial,sans-serif"><br></div></div></div></blockquote><div>=
<br>Or you could use `std::filesystem::path` for the &quot;from-file&quot; =
version. Admittedly, that&#39;s simply a poorly-chosen example, but you&#39=
;d be surprised how many constructors can be differentiated just by judicio=
us use of proper types. It&#39;s one of the reasons why C++ needs strong al=
iases so badly: so that we can give a generic type meaning without making t=
he use of that type difficult.<br>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div dir=3D"ltr"><div style=3D"font-family:arial,sans-serif=
"><div style=3D"font-family:arial,sans-serif"></div>How about this example =
(ok you could design this differently, maybe using polymorphism)?</div></di=
v></blockquote><div><br>Easily differentiated with an enum:<br><br><div sty=
le=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187=
); border-style: solid; border-width: 1px; overflow-wrap: break-word;" clas=
s=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint"=
><span style=3D"color: #008;" class=3D"styled-by-prettify">enum</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">class</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;"=
 class=3D"styled-by-prettify">ConfigLoad</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"style=
d-by-prettify"><br>=C2=A0 =C2=A0 lazy</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br>=C2=A0 =C2=A0 standard</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"s=
tyled-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-p=
rettify">Config</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> c</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">someString</=
span><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: #606;" class=3D"styled-by-prettify">ConfigLoad</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">lazy</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">);</span></div></code></div><br>And, more =
to the point, we still get to do this:<br><br><div style=3D"background-colo=
r: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: soli=
d; border-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><co=
de class=3D"prettyprint"><div class=3D"subprettyprint"><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">any a</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">in_place_type</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">&lt;</span><span style=3D"color: #606;" class=3D"styled-by-pre=
ttify">Config</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">&gt;,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> s=
omeString</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #606;" class=3D"styled-by-prettify">ConfigLoad</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">lazy</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">);</span></div></code></div><br>T=
o do that with your named constructors, you&#39;d have to invent a whole ne=
w indirect initialization mechanism, as others have suggested. Which also m=
eans that any user who creates a type with indirect initialization needs to=
 know how to build this new mechanism <i>in addition</i> to the old one.<br=
><br>Finding ways to live with a single constructor namespace is ultimately=
 preferable to using named constructors. Even if it leads you to doing some=
thing like this:<br><br><div style=3D"background-color: rgb(250, 250, 250);=
 border-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; =
overflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyprin=
t"><div class=3D"subprettyprint"><span style=3D"color: #606;" class=3D"styl=
ed-by-prettify">Config</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> c</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">(</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Confi=
g</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span>=
<span style=3D"color: #606;" class=3D"styled-by-prettify">FromString</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> someString</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">);</span></div></code></d=
iv><br>I prefer this syntax over named constructors as a language feature o=
r static members as named constructors. This way works indirectly, while ne=
ither of those features can do so with existing library stuff.<br></div></d=
iv>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/cb6f76b8-e098-4aea-ac69-8d7317cca1f0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cb6f76b8-e098-4aea-ac69-8d7317cca1f0=
%40isocpp.org</a>.<br />

------=_Part_1248_1220787415.1484581010124--

------=_Part_1247_336044815.1484581010124--

.

On 2017-01-12 14:07, stefan.pantos@torstonetech.com wrote:
> I find my self regularly creating static factory functions on classes to
> better describe how something is being constructed or to avoid having
> flags passed which may have some invalid permutations. Now some times
> this is because of poor design(Lazy/efficient) but it does make me
> wonder if constructers with names different to their class would be helpf=
ul.
>
> Take this contrived example:
> |
> classTemperature
> {
>    public:
>         Temperature(floatk);
>         Temperature(floatc,boolcelsiusOrFahrenheit);//An abomination
>
>         floatinKelvin()const;
>         floatinCelsius()const;
>         floatinFahrenheit()const;
>    private:
>        floatkelvin;
> };
>
> autozero =3DTemperature(0);
> autozeroC =3DTemperature(=E2=88=92273.15,true);
> autozeroF =3DTemperature(=E2=88=92459.67,false);
>
> classTemperature
> {
>    public:
>         structF{};
>         structC{};
>         structK{};
>
>         Temperature(floatk,K);
>         Temperature(floatc,C);
>         Temperature(floatf,F);
>
>         floatinKelvin()const;
>         floatinCelsius()const;
>         floatinFahrenheit()const;
>    private:
>        floatkelvin;
> };
>
>
> autozero =3DTemperature(0,Temperature::K());
> autozeroC =3DTemperature(-273.15,Temperature::C());
> autozeroF =3DTemperature(=E2=88=92459.67,Temperature::F());
>
> classTemperature
> {
>    public:
>         staticTemperaturefromKelvin(floatk);
>         staticTemperaturefromCelsius(floatc);
>         staticTemperaturefromFahrenheight(floatf);
>
>         floatinKelvin()const;
>         floatinCelsius()const;
>         floatinFahrenheit()const;
>    private:
>        floatkelvin;
> };
>
>
> autozero =3DTemperature::fromKelvin(0);
> autozeroC =3DTemperature::fromCelsius(-273.15);
> autozeroF =3DTemperature::fromFahrenheight(=E2=88=92459.67);
>
> |
>
>
> First. I think most people wouldn't like the first.
>
> Second. Helpful for meta programming and I quite like it in general but
> this becomes more complex the more arguments involved. (wish I came up
> with a better example now.).
>
> Third. You cannot construct the temperature on the heap. But is as clear
> as the second.
>
> Would it be nice to do something like:
> |
> classTemperature
> {
>    public:
>         constructor fromKelvin(floatk);
>         constructor fromCelsius(floatc);
>         constructor fromFahrenheight(floatf);
>
>         floatinKelvin()const;
>         floatinCelsius()const;
>         floatinFahrenheit()const;
>    private:
>        floatkelvin;
> };
>
>
> autozero_ptr =3DnewTemperature::fromKelvin(0);
> autozeroC_ptr =3DnewTemperature::fromCelsius(-273.15);
> autozeroF_ptr =3DnewTemperature::fromFahrenheight(=E2=88=92459.67);
> |
>
> Please don't hold this against me but it does have some similarities to
> Objective-C's init methods or other languages where the argument names
> are used to select the call.
>

What about a pair of user defined literals

Temperature operator""_K(long double);
Temperature operator""_C(long double);


Then we can just do

auto temp =3D 273.15_K;


     Bo Persson


--=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/o5bein%2476p%241%40blaine.gmane.org.

.