Topic: Default-constructed function return value
Author: Kenshi Takayama <kenshi84@gmail.com>
Date: Tue, 4 Mar 2014 12:44:20 -0800 (PST)
Raw View
------=_Part_5535_20552485.1393965860563
Content-Type: text/plain; charset=UTF-8
I'm new to this group and not sure if this was discussed before, but I
wonder if it's a good idea to allow the following code:
struct X {
X(){}
X(int){}
};
X f() {
// ...
if (something_happened) {
return; // It'd be nice if I could simply write this way
// return X(); // which is equivalent to this.
}
return X(some_interesting_result);
}
It'd be useful especially when X is actually very complex (possibly with
lots of template parameters) and hard to type.
Thanks,
Kenshi
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_5535_20552485.1393965860563
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I'm new to this group and not sure if this was discussed b=
efore, but I wonder if it's a good idea to allow the following code:<div><d=
iv><br><div><div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, =
187, 187); word-wrap: break-word; background-color: rgb(250, 250, 250);"><c=
ode class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><div class=3D"subprettyprint"><div c=
lass=3D"subprettyprint">struct X {</div><div class=3D"subprettyprint"> =
; X(){}</div><div class=3D"subprettyprint"> X(int){}</d=
iv><div class=3D"subprettyprint">};</div><div class=3D"subprettyprint">X f(=
) {</div><div class=3D"subprettyprint"> // ...</div><div class=
=3D"subprettyprint"> if (something_happened) {</div><div class=
=3D"subprettyprint"> return;  =
; // It'd be nice if I could simply write this way</di=
v><div class=3D"subprettyprint"> // return X(); =
// which is equivalent to this.</div><div class=3D"subp=
rettyprint"> }</div><div class=3D"subprettyprint">  =
; return X(some_interesting_result);</div><div class=3D"subprettyprint">}<s=
pan style=3D"font-family: Arial, Helvetica, sans-serif; font-size: 13px;">&=
nbsp; </span></div></div></span></div></code></div><div><div><br></di=
v></div><div>It'd be useful especially when X is actually very complex (pos=
sibly with lots of template parameters) and hard to type.</div></div><div><=
br></div></div><div>Thanks,</div><div>Kenshi</div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_5535_20552485.1393965860563--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 04 Mar 2014 12:49:53 -0800
Raw View
Em ter 04 mar 2014, =E0s 12:44:20, Kenshi Takayama escreveu:
> X f() {
> // ...
> if (something_happened) {
> return; // It'd be nice if I could simply write this =
way
> // return X(); // which is equivalent to this.
> }
> return X(some_interesting_result);
> } =20
>=20
> It'd be useful especially when X is actually very complex (possibly with=
=20
> lots of template parameters) and hard to type.
return {};
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Tue, 04 Mar 2014 15:51:16 -0500
Raw View
On 2014-03-04 15:44, Kenshi Takayama wrote:
> I'm new to this group and not sure if this was discussed before, but I
> wonder if it's a good idea to allow the following code:
>
> struct X {
> X(){}
> X(int){}
> };
> X f() {
> // ...
> if (something_happened) {
> return; // It'd be nice if I could simply write this way
> // return X(); // which is equivalent to this.
> }
> return X(some_interesting_result);
> }
>
> It'd be useful especially when X is actually very complex (possibly with
> lots of template parameters) and hard to type.
Why not write 'return {}'? You can do that in C++11... or do you have an
example where that doesn't work?
--
Matthew
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Alex B <devalexb@gmail.com>
Date: Tue, 4 Mar 2014 12:51:41 -0800 (PST)
Raw View
------=_Part_243_15100201.1393966301455
Content-Type: text/plain; charset=UTF-8
We aleardy have this in C++11:
X f() {
if (test)
return {};
return {int_value};
}
On Tuesday, March 4, 2014 3:44:20 PM UTC-5, Kenshi Takayama wrote:
> I'm new to this group and not sure if this was discussed before, but I
> wonder if it's a good idea to allow the following code:
>
> struct X {
> X(){}
> X(int){}
> };
> X f() {
> // ...
> if (something_happened) {
> return; // It'd be nice if I could simply write this
> way
> // return X(); // which is equivalent to this.
> }
> return X(some_interesting_result);
> }
>
> It'd be useful especially when X is actually very complex (possibly with
> lots of template parameters) and hard to type.
>
> Thanks,
> Kenshi
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_243_15100201.1393966301455
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>We aleardy have this in C++11:</div><div> </div>=
<div style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; =
background-color: rgb(250, 250, 250);" class=3D"prettyprint"><code class=3D=
"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: rgb(0, 0,=
0);" class=3D"styled-by-prettify">X f</span><span style=3D"color: rgb(102,=
102, 0);" class=3D"styled-by-prettify">()</span><span style=3D"color: rgb(=
0, 0, 0);" class=3D"styled-by-prettify"> </span><span style=3D"color: rgb(1=
02, 102, 0);" class=3D"styled-by-prettify">{</span><span style=3D"color: rg=
b(0, 0, 0);" class=3D"styled-by-prettify"><br> </span><span sty=
le=3D"color: rgb(0, 0, 136);" class=3D"styled-by-prettify">if</span><span s=
tyle=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">(</span><span=
style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify">test</span><sp=
an style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">)</span>=
<span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"><br> =
; </span><span style=3D"color: rgb(0, 0, 136);" class=3D"styl=
ed-by-prettify">return</span><span style=3D"color: rgb(0, 0, 0);" class=3D"=
styled-by-prettify"> </span><span style=3D"color: rgb(102, 102, 0);" class=
=3D"styled-by-prettify">{};</span><span style=3D"color: rgb(0, 0, 0);" clas=
s=3D"styled-by-prettify"><br> </span><span style=3D"color: rgb(=
0, 0, 136);" class=3D"styled-by-prettify">return</span><span style=3D"color=
: rgb(0, 0, 0);" class=3D"styled-by-prettify"> </span><span style=3D"color:=
rgb(102, 102, 0);" class=3D"styled-by-prettify">{</span><span style=3D"col=
or: rgb(0, 0, 0);" class=3D"styled-by-prettify">int_value</span><span style=
=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">};</span><span s=
tyle=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"><br></span><span=
style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">}</span></=
div></code></div><div><br><br>On Tuesday, March 4, 2014 3:44:20 PM UTC-5, K=
enshi Takayama wrote:</div><blockquote style=3D"margin: 0px 0px 0px 0.8ex; =
padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width=
: 1px; border-left-style: solid;" class=3D"gmail_quote"><div dir=3D"ltr">I'=
m new to this group and not sure if this was discussed before, but I wonder=
if it's a good idea to allow the following code:<div><div><br><div><div st=
yle=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; backgro=
und-color: rgb(250, 250, 250);"><code><div><span style=3D"color: rgb(0, 0, =
0);"><div><div>struct X {</div><div> X(){}</div><div> &n=
bsp; X(int){}</div><div>};</div><div>X f() {</div><div> // ...=
</div><div> if (something_happened) {</div><div> =
return; // It'd be =
nice if I could simply write this way</div><div> =
// return X(); // which is equivalent to this.</div><d=
iv> }</div><div> return X(some_interesting_result=
);</div><div>}<span style=3D"font-family: Arial,Helvetica,sans-serif; font-=
size: 13px;"> </span></div></div></span></div></code></div><div=
><div><br></div></div><div>It'd be useful especially when X is actually ver=
y complex (possibly with lots of template parameters) and hard to type.</di=
v></div><div><br></div></div><div>Thanks,</div><div>Kenshi</div></div></div=
></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_243_15100201.1393966301455--
.
Author: Kenshi Takayama <kenshi84@gmail.com>
Date: Tue, 4 Mar 2014 12:51:55 -0800 (PST)
Raw View
------=_Part_862_9698850.1393966315676
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Thanks!
2014=E5=B9=B43=E6=9C=884=E6=97=A5=E7=81=AB=E6=9B=9C=E6=97=A5 21=E6=99=8249=
=E5=88=8653=E7=A7=92 UTC+1 Thiago Macieira:
>
> Em ter 04 mar 2014, =C3=A0s 12:44:20, Kenshi Takayama escreveu:=20
> > X f() {=20
> > // ...=20
> > if (something_happened) {=20
> > return; // It'd be nice if I could simply write thi=
s=20
> way=20
> > // return X(); // which is equivalent to this.=20
> > }=20
> > return X(some_interesting_result);=20
> > } =20
> >=20
> > It'd be useful especially when X is actually very complex (possibly wit=
h=20
> > lots of template parameters) and hard to type.=20
>
> return {};=20
>
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
> Software Architect - Intel Open Source Technology Center=20
> PGP/GPG: 0x6EF45358; fingerprint:=20
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358=20
>
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_862_9698850.1393966315676
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Thanks!<br><br>2014=E5=B9=B43=E6=9C=884=E6=97=A5=E7=81=AB=
=E6=9B=9C=E6=97=A5 21=E6=99=8249=E5=88=8653=E7=A7=92 UTC+1 Thiago Macieira:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;">Em ter 04 mar 2014, =C3=A0s 12=
:44:20, Kenshi Takayama escreveu:
<br>> X f() {
<br>> // ...
<br>> if (something_happened) {
<br>> return; &n=
bsp; // It'd be nice if I could simply write this way
<br>> // return X(); // which is equivalent to this.
<br>> }
<br>> return X(some_interesting_result);
<br>> } =20
<br>>=20
<br>> It'd be useful especially when X is actually very complex (possibl=
y with=20
<br>> lots of template parameters) and hard to type.
<br>
<br>return {};
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%=
3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNEswDUBNCNanbu7euhq=
Ln_62FW8ag';return true;" onclick=3D"this.href=3D'http://www.google.com/url=
?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNEswDUBNC=
Nanbu7euhqLn_62FW8ag';return true;">macieira.info</a> - thiago (AT) <a href=
=3D"http://kde.org" target=3D"_blank" onmousedown=3D"this.href=3D'http://ww=
w.google.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75AFQj=
CNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'http:=
//www.google.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75=
AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;">kde.org</a>
<br> Software Architect - Intel Open Source Technology Center
<br> PGP/GPG: 0x6EF45358; fingerprint:
<br> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4=
5358
<br>
<br></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_862_9698850.1393966315676--
.
Author: xavi <gratal@gmail.com>
Date: Tue, 4 Mar 2014 22:20:34 +0100
Raw View
--001a1134f2b8855f2d04f3ce79dc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
return {}
or
return {int_value}
don't work if the corresponding constructor has been marked as explicit.
Why anyone would want to mark the default constructor as explicit I don't
know (though the standard allows it), but for the case of constructors with
one parameter it would be useful if "return {...}" was an exception and
allowed the use of constructors marked as explicit, since doing "return
{1};" in a function which returns a class object is already rather explicit=
..
On a similar note, does anyone know which part of the standard accounts for
the following:
struct A {
A() {}
A(const A&)=3Ddelete;
};
A b() { return {}; } //this seems to be ok
A c() { return A(); } //not ok... A is non-copiable
I would expect the copy to happen in both cases or in neither, but not only
in the second one.
Thanks!
2014-03-04 21:51 GMT+01:00 Kenshi Takayama <kenshi84@gmail.com>:
> Thanks!
>
> 2014=E5=B9=B43=E6=9C=884=E6=97=A5=E7=81=AB=E6=9B=9C=E6=97=A5 21=E6=99=824=
9=E5=88=8653=E7=A7=92 UTC+1 Thiago Macieira:
>
>> Em ter 04 mar 2014, =C3=A0s 12:44:20, Kenshi Takayama escreveu:
>> > X f() {
>> > // ...
>> > if (something_happened) {
>> > return; // It'd be nice if I could simply write
>> this way
>> > // return X(); // which is equivalent to this.
>> > }
>> > return X(some_interesting_result);
>> > }
>> >
>> > It'd be useful especially when X is actually very complex (possibly
>> with
>> > lots of template parameters) and hard to type.
>>
>> return {};
>>
>> --
>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>> Software Architect - Intel Open Source Technology Center
>> PGP/GPG: 0x6EF45358; fingerprint:
>> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
>>
>> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a1134f2b8855f2d04f3ce79dc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">return {}=C2=A0<div>or=C2=A0</div><div>return {int_value}<=
/div><div>=C2=A0<div>don't work if the corresponding constructor has be=
en marked as explicit. Why anyone would want to mark the default constructo=
r as explicit I don't know (though the standard allows it), but for the=
case of constructors with one parameter it would be useful if "return=
{...}" was an exception and allowed the use of constructors marked as=
explicit, since doing "return {1};" in a function which returns =
a class object is already rather explicit.</div>
<div><br></div><div>On a similar note, does anyone know which part of the s=
tandard accounts for the following:</div><div><br></div><div>struct A {</di=
v><div>=C2=A0 =C2=A0A() {}</div><div>=C2=A0 =C2=A0A(const A&)=3Ddelete;=
</div><div>};</div>
<div><br></div><div>A b() { =C2=A0 return {}; =C2=A0 } //this seems to be o=
k</div><div>A c() { =C2=A0 return A(); } //not ok... A is non-copiable</div=
><div><br></div><div>I would expect the copy to happen in both cases or in =
neither, but not only in the second one.</div>
<div><br></div><div>Thanks!</div><div><div><br></div></div></div></div><div=
class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2014-03-04 21:51 =
GMT+01:00 Kenshi Takayama <span dir=3D"ltr"><<a href=3D"mailto:kenshi84@=
gmail.com" target=3D"_blank">kenshi84@gmail.com</a>></span>:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Thanks!<br><br>2014=E5=B9=
=B43=E6=9C=884=E6=97=A5=E7=81=AB=E6=9B=9C=E6=97=A5 21=E6=99=8249=E5=88=8653=
=E7=A7=92 UTC+1 Thiago Macieira:<div><div class=3D"h5"><blockquote class=3D=
"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex">
Em ter 04 mar 2014, =C3=A0s 12:44:20, Kenshi Takayama escreveu:
<br>> X f() {
<br>> =C2=A0 =C2=A0 // ...
<br>> =C2=A0 =C2=A0 if (something_happened) {
<br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 return; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 // It'd be nice if I could simply write this way
<br>> // return X(); =C2=A0 =C2=A0 =C2=A0// which is equivalent to this.
<br>> =C2=A0 =C2=A0 }
<br>> =C2=A0 =C2=A0 return X(some_interesting_result);
<br>> } =C2=A0=20
<br>>=20
<br>> It'd be useful especially when X is actually very complex (pos=
sibly with=20
<br>> lots of template parameters) and hard to type.
<br>
<br>return {};
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" targ=
et=3D"_blank">kde.org</a>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:
<br>=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C =C2=A0966C 33F5 F005 6EF4=
5358
<br>
<br></blockquote></div></div></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a1134f2b8855f2d04f3ce79dc--
.
Author: Zhihao Yuan <zy@miator.net>
Date: Tue, 4 Mar 2014 17:35:58 -0500
Raw View
On Tue, Mar 4, 2014 at 4:20 PM, xavi <gratal@gmail.com> wrote:
> don't work if the corresponding constructor has been marked as explicit. Why
> anyone would want to mark the default constructor as explicit I don't know
> (though the standard allows it),
Because default ctor may have arguments:
http://cplusplus.github.io/LWG/lwg-defects.html#2193
Fixed in C++14.
> but for the case of constructors with one
> parameter it would be useful if "return {...}" was an exception and allowed
> the use of constructors marked as explicit, since doing "return {1};" in a
> function which returns a class object is already rather explicit.
Explicit conversion is a horrible name for "construct from". Two types
gain no relationship on type system (subset, overlap, etc.) just because
one is constructible from one to the other. And such an information
should be local to the the code using the construction, in one statement.
> On a similar note, does anyone know which part of the standard accounts for
> the following:
>
> struct A {
> A() {}
> A(const A&)=delete;
> };
>
> A b() { return {}; } //this seems to be ok
> A c() { return A(); } //not ok... A is non-copiable
>
> I would expect the copy to happen in both cases or in neither, but not only
> in the second one.
The difference is as same as that in
A a = {};
A a = A(); // nope
braced-init-list syntax is not a type in type system,
so it's reasonable to not asking for copy ctor, but the
semantics of the traditional C++ syntax (return A(); in your
case) is well known and had better not be changed.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: xavi <gratal@gmail.com>
Date: Tue, 4 Mar 2014 23:53:34 +0100
Raw View
--001a113a9c0219c31104f3cfc68d
Content-Type: text/plain; charset=ISO-8859-1
2014-03-04 23:35 GMT+01:00 Zhihao Yuan <zy@miator.net>:
> On Tue, Mar 4, 2014 at 4:20 PM, xavi <gratal@gmail.com> wrote:
> > don't work if the corresponding constructor has been marked as explicit.
> Why
> > anyone would want to mark the default constructor as explicit I don't
> know
> > (though the standard allows it),
>
> Because default ctor may have arguments:
>
> http://cplusplus.github.io/LWG/lwg-defects.html#2193
>
> Fixed in C++14.
>
> > but for the case of constructors with one
> > parameter it would be useful if "return {...}" was an exception and
> allowed
> > the use of constructors marked as explicit, since doing "return {1};" in
> a
> > function which returns a class object is already rather explicit.
>
> Explicit conversion is a horrible name for "construct from". Two types
> gain no relationship on type system (subset, overlap, etc.) just because
> one is constructible from one to the other. And such an information
> should be local to the the code using the construction, in one statement.
>
Exactly my point. What I want when I say return {3} is not an explicit
conversion, it's to construct the object that I'm going to return, with a
well-known type, from 3. The same way that when I say return return {3,7} I
don't want an explicit conversion, I just want to construct from 3 and 7.
So I believe return {3} as a way to construct from 3 shouldn't be forbidden
just because the constructor was marked as explicit to avoid accidental
implicit conversions somewhere else.
>
> > On a similar note, does anyone know which part of the standard accounts
> for
> > the following:
> >
> > struct A {
> > A() {}
> > A(const A&)=delete;
> > };
> >
> > A b() { return {}; } //this seems to be ok
> > A c() { return A(); } //not ok... A is non-copiable
> >
> > I would expect the copy to happen in both cases or in neither, but not
> only
> > in the second one.
>
> The difference is as same as that in
>
> A a = {};
> A a = A(); // nope
>
> braced-init-list syntax is not a type in type system,
> so it's reasonable to not asking for copy ctor, but the
> semantics of the traditional C++ syntax (return A(); in your
> case) is well known and had better not be changed.
>
This makes the previous return {3} problem much more limiting. If I have a
non-copiable type with three constructors A(), explicit A(int), A(int,int),
where the only reason the middle one is different is to avoid accidental
implicit conversions (which are not possible with the other two), why
should I be able to return objects constructed with only two of the three
constructors?
>
> --
> Zhihao Yuan, ID lichray
> The best way to predict the future is to invent it.
> ___________________________________________________
> 4BSD -- http://4bsd.biz/
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a113a9c0219c31104f3cfc68d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">2014-03-04 23:35 GMT+01:00 Zhihao Yuan <span dir=3D"ltr"><<a hre=
f=3D"mailto:zy@miator.net" target=3D"_blank">zy@miator.net</a>></span>:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex">
<div class=3D"">On Tue, Mar 4, 2014 at 4:20 PM, xavi <<a href=3D"mailto:=
gratal@gmail.com">gratal@gmail.com</a>> wrote:<br>
> don't work if the corresponding constructor has been marked as exp=
licit. Why<br>
> anyone would want to mark the default constructor as explicit I don=
9;t know<br>
> (though the standard allows it),<br>
<br>
</div>Because default ctor may have arguments:<br>
<br>
=A0 <a href=3D"http://cplusplus.github.io/LWG/lwg-defects.html#2193" target=
=3D"_blank">http://cplusplus.github.io/LWG/lwg-defects.html#2193</a><br>
<br>
Fixed in C++14.<br>
<div class=3D""><br>
> but for the case of constructors with one<br>
> parameter it would be useful if "return {...}" was an except=
ion and allowed<br>
> the use of constructors marked as explicit, since doing "return {=
1};" in a<br>
> function which returns a class object is already rather explicit.<br>
<br>
</div>Explicit conversion is a horrible name for "construct from"=
.. =A0Two types<br>
gain no relationship on type system (subset, overlap, etc.) just because<br=
>
one is constructible from one to the other. =A0And such an information<br>
should be local to the the code using the construction, in one statement.<b=
r></blockquote><div><br></div><div>Exactly my point. What I want when I say=
return {3} is not an explicit conversion, it's to construct the object=
that I'm going to return, with a well-known type, from 3. The same way=
that when I say return return {3,7} I don't want an explicit conversio=
n, I just want to construct from 3 and 7. So I believe return {3} as a way =
to construct from 3 shouldn't be forbidden just because the constructor=
was marked as explicit to avoid accidental implicit conversions somewhere =
else.</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div class=3D""><br>
> On a similar note, does anyone know which part of the standard account=
s for<br>
> the following:<br>
><br>
> struct A {<br>
> =A0 =A0A() {}<br>
> =A0 =A0A(const A&)=3Ddelete;<br>
> };<br>
><br>
> A b() { =A0 return {}; =A0 } //this seems to be ok<br>
> A c() { =A0 return A(); } //not ok... A is non-copiable<br>
><br>
> I would expect the copy to happen in both cases or in neither, but not=
only<br>
> in the second one.<br>
<br>
</div>The difference is as same as that in<br>
<br>
=A0 A a =3D {};<br>
=A0 A a =3D A(); =A0// nope<br>
<br>
braced-init-list syntax is not a type in type system,<br>
so it's reasonable to not asking for copy ctor, but the<br>
semantics of the traditional C++ syntax (return A(); in your<br>
case) is well known and had better not be changed.<br></blockquote><div><br=
></div><div>This makes the previous return {3} problem much more limiting. =
If I have a non-copiable type with three constructors A(), explicit A(int),=
A(int,int), where the only reason the middle one is different is to avoid =
accidental implicit conversions (which are not possible with the other two)=
, why should I be able to return objects constructed with only two of the t=
hree constructors?</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Zhihao Yuan, ID lichray<br>
The best way to predict the future is to invent it.<br>
___________________________________________________<br>
4BSD -- <a href=3D"http://4bsd.biz/" target=3D"_blank">http://4bsd.biz/</a>=
<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a113a9c0219c31104f3cfc68d--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Tue, 04 Mar 2014 18:08:54 -0500
Raw View
On 2014-03-04 17:35, Zhihao Yuan wrote:
> On Tue, Mar 4, 2014 at 4:20 PM, xavi <gratal@gmail.com> wrote:
>> ['return {}'] don't work if the corresponding constructor has been
>> marked as explicit. [...] for the case of constructors with one
>> parameter it would be useful if "return {...}" was an exception and
>> allowed the use of constructors marked as explicit, since doing
>> "return {1};" in a function which returns a class object is already
>> rather explicit.
>
> Explicit conversion is a horrible name for "construct from". Two types
> gain no relationship on type system (subset, overlap, etc.) just because
> one is constructible from one to the other. And such an information
> should be local to the the code using the construction, in one statement.
Okay, I don't understand what you just said.
To put it differently, what is the difference between:
Type foo(...)
{
...
return {...};
}
....and:
Type foo(...)
{
...
return Type{...};
}
....? (assuming all of the '...' are the same, of course)
I was under the impression that the permitted eliding of the class name
(in e.g. parameter passing also) was just that: an *eliding*. Not
completely different code. Am I mistaken?
--
Matthew
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Zhihao Yuan <zy@miator.net>
Date: Tue, 4 Mar 2014 18:11:24 -0500
Raw View
On Tue, Mar 4, 2014 at 5:53 PM, xavi <gratal@gmail.com> wrote:
>> Explicit conversion is a horrible name for "construct from". Two types
>> gain no relationship on type system (subset, overlap, etc.) just because
>> one is constructible from one to the other. And such an information
>> should be local to the the code using the construction, in one statement.
>
>
> Exactly my point. What I want when I say return {3} is not an explicit
> conversion, it's to construct the object that I'm going to return, with a
> well-known type, from 3. The same way that when I say return return {3,7} I
> don't want an explicit conversion, I just want to construct from 3 and 7. So
> I believe return {3} as a way to construct from 3 shouldn't be forbidden
> just because the constructor was marked as explicit to avoid accidental
> implicit conversions somewhere else.
The return type is unique and known, but it's not local (enough) IMO.
For example:
return { strchr(s, c) };
where the return type is unique_ptr, you want the compiler to be
silent?
>> braced-init-list syntax is not a type in type system,
>> so it's reasonable to not asking for copy ctor, but the
>> semantics of the traditional C++ syntax (return A(); in your
>> case) is well known and had better not be changed.
>
>
> This makes the previous return {3} problem much more limiting. If I have a
> non-copiable type with three constructors A(), explicit A(int), A(int,int),
> where the only reason the middle one is different is to avoid accidental
> implicit conversions (which are not possible with the other two), why should
> I be able to return objects constructed with only two of the three
> constructors?
There might be good reasons. For example, you may have
struct Point
{
Point(): Point(0) {}
explicit Point(int n): x(n), y(n) {}
Point(int x, int y): x(x), y(y) {}
int x, y;
};
So {3} is not a Point on type system, but {3, 4} has some
relationship with Point(3, 4) -- they have the same data
representation.
We actually already found issues like this in STL:
http://cplusplus.github.io/LWG/lwg-active.html#2307
Forget about the title. We just did not have enough time
to discuss this in Issaquah, but we definitely want this
solved in C++17.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Zhihao Yuan <zy@miator.net>
Date: Tue, 4 Mar 2014 18:36:47 -0500
Raw View
On Tue, Mar 4, 2014 at 6:08 PM, Matthew Woehlke
<mw_triad@users.sourceforge.net> wrote:
> To put it differently, what is the difference between:
>
> Type foo(...)
> {
> ...
> return {...};
> }
>
> ...and:
>
> Type foo(...)
> {
> ...
> return Type{...};
> }
>
> ...? (assuming all of the '...' are the same, of course)
>
> I was under the impression that the permitted eliding of the class name (in
> e.g. parameter passing also) was just that: an *eliding*. Not completely
> different code. Am I mistaken?
In current C++, one asks for copy ctor one does not.
My point is that I prefer Type to be local to the statement
when no implicit conversion (implies partial-order relationship,
I hope) is available.
f({...}) //1
and
f(Type{...}) //2
is obvious since //1 Type is neither local nor unique. For
return {...};
Type is unique and arguably local, and I think it's good
to keep Type as local as possible (when no implicit blah
blah blah). Again, imagine code like this:
unique_ptr<char> f(...)
{
if (...)
return { strchr(s, c) };
else
return { new char[...] };
}
which is horrible.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Tue, 04 Mar 2014 18:55:20 -0500
Raw View
On 2014-03-04 18:36, Zhihao Yuan wrote:
> Again, imagine code like this:
>
> unique_ptr<char> f(...)
> {
> if (...)
> return { strchr(s, c) };
> else
> return { new char[...] };
> }
>
> which is horrible.
*You* know it is horrible, and *I* know it is horrible, but how is the
compiler supposed to know? Both of those invoke a ctor taking a char*.
How is the compiler supposed to know that one is freshly allocated
memory and the other points to the interior of some other memory block?
What exactly are you expecting the compiler to know that would prevent
the above from being well formed?
--
Matthew
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Zhihao Yuan <zy@miator.net>
Date: Tue, 4 Mar 2014 19:12:32 -0500
Raw View
On Tue, Mar 4, 2014 at 6:55 PM, Matthew Woehlke
<mw_triad@users.sourceforge.net> wrote:
> On 2014-03-04 18:36, Zhihao Yuan wrote:
>>
>> Again, imagine code like this:
>>
>> unique_ptr<char> f(...)
>> {
>> if (...)
>> return { strchr(s, c) };
>> else
>> return { new char[...] };
>> }
>>
>> which is horrible.
>
>
> *You* know it is horrible, and *I* know it is horrible, but how is the
> compiler supposed to know? Both of those invoke a ctor taking a char*. How
> is the compiler supposed to know that one is freshly allocated memory and
> the other points to the interior of some other memory block? What exactly
> are you expecting the compiler to know that would prevent the above from
> being well formed?
Program is writtrn for people to read, and I believe that
requiring Type right on the left of {...} helps code review.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: David Krauss <potswa@gmail.com>
Date: Wed, 5 Mar 2014 08:40:35 +0800
Raw View
--Apple-Mail=_CD699EB4-A2BF-4E9E-8EF7-61FA3AE026A9
Content-Type: text/plain; charset=ISO-8859-1
On Mar 5, 2014, at 4:51 AM, Matthew Woehlke <mw_triad@users.sourceforge.net> wrote:
> Why not write 'return {}'? You can do that in C++11... or do you have an example where that doesn't work?
It doesn't work with an explicit default constructor :(
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--Apple-Mail=_CD699EB4-A2BF-4E9E-8EF7-61FA3AE026A9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Mar 5=
, 2014, at 4:51 AM, Matthew Woehlke <<a href=3D"mailto:mw_triad@users.so=
urceforge.net">mw_triad@users.sourceforge.net</a>> wrote:</div><br class=
=3D"Apple-interchange-newline"><blockquote type=3D"cite">Why not write 'ret=
urn {}'? You can do that in C++11... or do you have an example where that d=
oesn't work?<br></blockquote><div><br></div><div>It doesn’t work with=
an <font face=3D"Courier">explicit</font> default constructor :(</div></di=
v><br></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_CD699EB4-A2BF-4E9E-8EF7-61FA3AE026A9--
.
Author: David Krauss <potswa@gmail.com>
Date: Wed, 5 Mar 2014 08:48:08 +0800
Raw View
--Apple-Mail=_BA87104C-2212-4C19-BCE4-1E2E153DB036
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On Mar 5, 2014, at 5:20 AM, xavi <gratal@gmail.com> wrote:
> return {}=20
> or=20
> return {int_value}
> =20
> don't work if the corresponding constructor has been marked as explicit. =
Why anyone would want to mark the default constructor as explicit I don't k=
now (though the standard allows it)
It happens accidentally when you define the default constructor by providin=
g a default argument. The explicit specifier in such a case is intended to =
prevent it from being a conversion constructor when the argument *is* speci=
fied. This is the source of a current defect in all standard containers, e.=
g.
explicit vector(const Allocator& =3D Allocator());
> , but for the case of constructors with one parameter it would be useful =
if "return {...}" was an exception and allowed the use of constructors mark=
ed as explicit, since doing "return {1};" in a function which returns a cla=
ss object is already rather explicit.
That's an interesting idea... never occurred to me... maybe post a new thre=
ad and see what folks think?
> On a similar note, does anyone know which part of the standard accounts f=
or the following:
>=20
> struct A {
> A() {}
> A(const A&)=3Ddelete;
> };
>=20
> A b() { return {}; } //this seems to be ok
> A c() { return A(); } //not ok... A is non-copiable
>=20
> I would expect the copy to happen in both cases or in neither, but not on=
ly in the second one.
The initializer initializes the return value object by copy-initialization.=
The first line expands to A return_value =3D {};. This is copy-list-initia=
lization, which despite the name is exactly like direct-list-initialization=
except that explicit constructors are prohibited. The second one expands t=
o A return_value =3D A();. This is copy-initialization from a temporary, wh=
ich does require a copy/move constructor. (Actually, in this case, you're u=
sing the implicitly-deleted move constructor.)
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_BA87104C-2212-4C19-BCE4-1E2E153DB036
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Mar 5=
, 2014, at 5:20 AM, xavi <<a href=3D"mailto:gratal@gmail.com">gratal@gma=
il.com</a>> wrote:</div><br class=3D"Apple-interchange-newline"><blockqu=
ote type=3D"cite"><div dir=3D"ltr">return {} <div>or </div><div>r=
eturn {int_value}</div><div> <div>don't work if the corresponding cons=
tructor has been marked as explicit. Why anyone would want to mark the defa=
ult constructor as explicit I don't know (though the standard allows it)</d=
iv></div></div></blockquote><div><br></div><div>It happens accidentally whe=
n you define the default constructor by providing a default argument. The e=
xplicit specifier in such a case is intended to prevent it from being a con=
version constructor when the argument *is* specified. This is the source of=
a current defect in all standard containers, e.g.</div><div><br></div><div=
><font face=3D"Courier">explicit vector(const Allocator& =3D Allocator(=
));</font><br></div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div><di=
v>, but for the case of constructors with one parameter it would be useful =
if "return {...}" was an exception and allowed the use of constructors mark=
ed as explicit, since doing "return {1};" in a function which returns a cla=
ss object is already rather explicit.</div></div></div></blockquote><div><b=
r></div><div>That’s an interesting idea… never occurred to me&=
hellip; maybe post a new thread and see what folks think?</div><br><blockqu=
ote type=3D"cite"><div dir=3D"ltr">
<div>On a similar note, does anyone know which part of the standard account=
s for the following:</div><div><br></div><div>struct A {</div><div> &=
nbsp;A() {}</div><div> A(const A&)=3Ddelete;</div><div>};</=
div>
<div><br></div><div>A b() { return {}; } //this seems to be o=
k</div><div>A c() { return A(); } //not ok... A is non-copiable</div=
><div><br></div><div>I would expect the copy to happen in both cases or in =
neither, but not only in the second one.</div></div></blockquote><div><br><=
/div><div>The initializer initializes the return value object by copy-initi=
alization. The first line expands to <font face=3D"Courier">A return_value =
=3D {};</font>. This is <i>copy-list-initialization</i>, which despite the =
name is exactly like direct-list-initialization except that explicit constr=
uctors are prohibited. The second one expands to <span style=3D"font-f=
amily: Courier;">A return_value =3D A();</span>. This is <i>copy-initializa=
tion</i> from a temporary, which does require a copy/move constructor. (Act=
ually, in this case, you’re using the implicitly-deleted move constru=
ctor.)</div></div><br></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_BA87104C-2212-4C19-BCE4-1E2E153DB036--
.
Author: xavi <gratal@gmail.com>
Date: Wed, 5 Mar 2014 02:28:06 +0100
Raw View
--001a11c14c20c2d9fd04f3d1ee01
Content-Type: text/plain; charset=ISO-8859-1
2014-03-05 1:12 GMT+01:00 Zhihao Yuan <zy@miator.net>:
> On Tue, Mar 4, 2014 at 6:55 PM, Matthew Woehlke
> <mw_triad@users.sourceforge.net> wrote:
> > On 2014-03-04 18:36, Zhihao Yuan wrote:
> >>
> >> Again, imagine code like this:
> >>
> >> unique_ptr<char> f(...)
> >> {
> >> if (...)
> >> return { strchr(s, c) };
> >> else
> >> return { new char[...] };
> >> }
> >>
> >> which is horrible.
> >
> >
> > *You* know it is horrible, and *I* know it is horrible, but how is the
> > compiler supposed to know? Both of those invoke a ctor taking a char*.
> How
> > is the compiler supposed to know that one is freshly allocated memory and
> > the other points to the interior of some other memory block? What exactly
> > are you expecting the compiler to know that would prevent the above from
> > being well formed?
>
> Program is writtrn for people to read, and I believe that
> requiring Type right on the left of {...} helps code review.
>
> And this same argument could be made against auto and type deduction in
templates, but flooding code with type repetition doesn't help readability
at all.
When you write return {1,2}, you don't want to return two numbers, you want
to return whatever return type the function have, constructed with (1,2).
In the same way, when you write return {strchr(s,c)}, you don't want to
return strchr(s,c), you want to return the return type constructed with
this pointer, otherwise you would just write "return strchr(s,c)". Someone
who writes return {strchr(s,c)} is just as likely to write return
unique_ptr<char>(strchr(s,c)), which will always work and is just as wrong.
Explicit constructors should be allowed in this context, the {} clearly
expresses the intent.
> --
> Zhihao Yuan, ID lichray
> The best way to predict the future is to invent it.
> ___________________________________________________
> 4BSD -- http://4bsd.biz/
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11c14c20c2d9fd04f3d1ee01
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">2014-03-05 1:12 GMT+01:00 Zhihao Yuan <span dir=3D"ltr"><<a href=
=3D"mailto:zy@miator.net" target=3D"_blank">zy@miator.net</a>></span>:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">
<div class=3D"">On Tue, Mar 4, 2014 at 6:55 PM, Matthew Woehlke<br>
<<a href=3D"mailto:mw_triad@users.sourceforge.net">mw_triad@users.source=
forge.net</a>> wrote:<br>
> On 2014-03-04 18:36, Zhihao Yuan wrote:<br>
>><br>
>> Again, imagine code like this:<br>
>><br>
>> =A0 =A0unique_ptr<char> f(...)<br>
>> =A0 =A0{<br>
>> =A0 =A0 =A0if (...)<br>
>> =A0 =A0 =A0 =A0return { strchr(s, c) };<br>
>> =A0 =A0 =A0else<br>
>> =A0 =A0 =A0 =A0return { new char[...] };<br>
>> =A0 =A0}<br>
>><br>
>> which is horrible.<br>
><br>
><br>
> *You* know it is horrible, and *I* know it is horrible, but how is the=
<br>
> compiler supposed to know? Both of those invoke a ctor taking a char*.=
How<br>
> is the compiler supposed to know that one is freshly allocated memory =
and<br>
> the other points to the interior of some other memory block? What exac=
tly<br>
> are you expecting the compiler to know that would prevent the above fr=
om<br>
> being well formed?<br>
<br>
</div>Program is writtrn for people to read, and I believe that<br>
requiring Type right on the left of {...} helps code review.<br>
<div class=3D"im HOEnZb"><br></div></blockquote><div>And this same argument=
could be made against auto and type deduction in templates, but flooding c=
ode with type repetition doesn't help readability at all.</div><div>
<br></div><div>When you write return {1,2}, you don't want to return tw=
o numbers, you want to return whatever return type the function have, const=
ructed with (1,2). In the same way, when you write return {strchr(s,c)}, yo=
u don't want to return strchr(s,c), you want to return the return type =
constructed with this pointer, otherwise you would just write "return =
strchr(s,c)". Someone who writes return {strchr(s,c)} is just as likel=
y to write return unique_ptr<char>(strchr(s,c)), which will always wo=
rk and is just as wrong.</div>
<div><br></div><div>Explicit constructors should be allowed in this context=
, the {} clearly expresses the intent.</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im HOEnZb">
--<br>
Zhihao Yuan, ID lichray<br>
The best way to predict the future is to invent it.<br>
___________________________________________________<br>
4BSD -- <a href=3D"http://4bsd.biz/" target=3D"_blank">http://4bsd.biz/</a>=
<br>
<br>
</div><div class=3D"HOEnZb"><div class=3D"h5">--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c14c20c2d9fd04f3d1ee01--
.
Author: Zhihao Yuan <zy@miator.net>
Date: Wed, 5 Mar 2014 10:56:50 -0500
Raw View
On Tue, Mar 4, 2014 at 8:28 PM, xavi <gratal@gmail.com> wrote:
> 2014-03-05 1:12 GMT+01:00 Zhihao Yuan <zy@miator.net>:
>
>> Program is writtrn for people to read, and I believe that
>> requiring Type right on the left of {...} helps code review.
>>
> And this same argument could be made against auto and type deduction in
> templates, but flooding code with type repetition doesn't help readability
> at all.
{...} can involve conversions, auto type deduction cannot, which causes
no problem. I've repeated many times, "when implicit conversion is not
available", you need to specify the type.
> Someone who
> writes return {strchr(s,c)} is just as likely to write return
> unique_ptr<char>(strchr(s,c)), which will always work and is just as wrong.
But you, as a code reader, can find the problem right within this line.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Marc <marc.glisse@gmail.com>
Date: Thu, 6 Mar 2014 13:12:44 -0800 (PST)
Raw View
------=_Part_847_13510750.1394140364789
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Le mardi 4 mars 2014 23:53:34 UTC+1, Xavi Gratal a =C3=A9crit :
>
>
> Exactly my point. What I want when I say return {3} is not an explicit=20
> conversion, it's to construct the object that I'm going to return, with a=
=20
> well-known type, from 3. The same way that when I say return return {3,7}=
I=20
> don't want an explicit conversion, I just want to construct from 3 and 7.=
=20
> So I believe return {3} as a way to construct from 3 shouldn't be forbidd=
en=20
> just because the constructor was marked as explicit to avoid accidental=
=20
> implicit conversions somewhere else.
>
I agree with you that return is already explicit enough and we shouldn't=20
have to repeat the return type, but that idea was already discussed in the=
=20
committee and we lost. Interestingly, the arguments were mostly stylistic:=
=20
"it makes it clearer", when the committee usually insists that it won't=20
standardize things based on coding style.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_847_13510750.1394140364789
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Le mardi 4 mars 2014 23:53:34 UTC+1, Xavi Gratal a =C3=A9c=
rit :<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br=
><div><div class=3D"gmail_quote"><div>Exactly my point. What I want when I =
say return {3} is not an explicit conversion, it's to construct the object =
that I'm going to return, with a well-known type, from 3. The same way that=
when I say return return {3,7} I don't want an explicit conversion, I just=
want to construct from 3 and 7. So I believe return {3} as a way to constr=
uct from 3 shouldn't be forbidden just because the constructor was marked a=
s explicit to avoid accidental implicit conversions somewhere else.</div></=
div></div></div></blockquote><div><br>I agree with you that return is alrea=
dy explicit enough and we shouldn't have to repeat the return type, but tha=
t idea was already discussed in the committee and we lost. Interestingly, t=
he arguments were mostly stylistic: "it makes it clearer", when the committ=
ee usually insists that it won't standardize things based on coding style.<=
br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_847_13510750.1394140364789--
.
Author: David Krauss <potswa@gmail.com>
Date: Thu, 6 Mar 2014 21:07:55 -0800 (PST)
Raw View
------=_Part_342_29633068.1394168875968
Content-Type: text/plain; charset=UTF-8
On Friday, March 7, 2014 5:12:44 AM UTC+8, Marc wrote:
>
> I agree with you that return is already explicit enough and we shouldn't
> have to repeat the return type, but that idea was already discussed in the
> committee and we lost. Interestingly, the arguments were mostly stylistic:
> "it makes it clearer", when the committee usually insists that it won't
> standardize things based on coding style.
>
Can you provide a reference? Were they really arguing that the current
status quo is better style, or just that there shouldn't be an exception
for return statements versus other copy-initialization contexts?
Adding a special case for return statements could be seen as style
legislation. Even if it provides for extra freedom, it would require more
style-related standardese.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_342_29633068.1394168875968
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>On Friday, March 7, 2014 5:12:44 AM UTC+8, Marc wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">I agree with =
you that return is already explicit enough and we shouldn't have to repeat =
the return type, but that idea was already discussed in the committee and w=
e lost. Interestingly, the arguments were mostly stylistic: "it makes it cl=
earer", when the committee usually insists that it won't standardize things=
based on coding style.<br></div></blockquote><div><br>Can you provide a re=
ference? Were they really arguing that the current status quo is better sty=
le, or just that there shouldn't be an exception for return statements vers=
us other copy-initialization contexts?<br><br>Adding a special case for ret=
urn statements could be seen as style legislation. Even if it provides for =
extra freedom, it would require more style-related standardese.<br> </=
div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_342_29633068.1394168875968--
.