------=_Part_37811_681826996.1527593293611
Content-Type: multipart/alternative;
 boundary="----=_Part_37812_1960377468.1527593293611"

------=_Part_37812_1960377468.1527593293611
Content-Type: text/plain; charset="UTF-8"

Hello,
I'm looking for direction on whether this idea is worth pursing as a
language feature.

The problem:
I want to change the error handling mechanism we currently have in our code
base from returning error codes and passing out params into a better,
modern one. Currently the code looks like this:
#define OUT
error_t fill_res(result_t* OUT res);
result_t obj;
error_t err = fill_res(&obj);
//handle error
I want to use the shiny `std::expected` or some similar available library
that forces handling the error via a `[[nodiscard]]` warning or something
similar:
std::expected<result_t, error_t> return_res() {
    result_t res;
    //same code as fill_res
    return res;
}
auto [obj, err] = return_res();
//handle error

The problem is unless NRVO is performed (along with an optimized
`std::expected`), this costs an extra move/copy, which is unacceptable when
this is almost every function in the code base (this becomes a major
slowdown and an increase in code size - more assembly instructions per
function). Now in this simple situation, I believe every compiler performs
this optimization so the issue is more theoretical then practical.

In this example, the way we structure my code -  the error handling
mechanism, is determined by whether or not the compiler performs NRVO, and
that really really should not happen - that's exactly what the standard is
for - something to rely on when structuring the code.

The committee is already in the process of standardizing ``std::expected` or
some similar error handling mechanism, and this should be a concern when
transforming old code to use this new mechanism.

The solution:
Have some weak guarantee for performing NRVO to make at least this example
not cause a move.

In this thread I'm looking for directions on both other use cases for
partially guaranteed NRVO, as I am not sure this example alone requires a
language change. Also, I am looking for directions as to how this might be
articulated in the standard, as I am not a language lawyer.

I am willing to write a proposal if this feature is deemed worthy.

Previous work:
The only previous work I could find (in this forum and old mailings) is C++
17's Guaranteed copy elision described in
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0135r0.html
In this paper, the author, Richard Smith (who I know is active in this
forum) did mention NRVO and said it will not be pursued due to technical
difficulty to reach  a simple guarantee. I wonder if this point was
discussed and investigated while reviewing this proposal?

--
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/707d3b51-fff7-4ce1-a2df-1e859ef4671f%40isocpp.org.

------=_Part_37812_1960377468.1527593293611
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hello, <br></div><div>I&#39;m looking for direction o=
n whether this idea is worth pursing as a language feature.</div><div><br><=
/div><div>The problem:</div><div>I want to change the error handling mechan=
ism we currently have in our code base from returning error codes and passi=
ng out params into a better, modern one. Currently the code looks like this=
:<br></div><div><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: #800;" class=3D"styled-by-pr=
ettify">#define</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> OUT<br>error_t fill_res</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">result_t</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">*</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
OUT res</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>result_=
t obj</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>error_t er=
r </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> fill_res</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">(&amp;</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">obj</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></span><span style=3D"color: #8=
00;" class=3D"styled-by-prettify">//handle error</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br></span></div></code></div>I want =
to use the shiny <code>`std::expected`</code> or some similar available lib=
rary that forces handling the error via a <code>`[[nodiscard]]`</code> warn=
ing or something similar:</div><div><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: #000;"=
 class=3D"styled-by-prettify">std</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">expected</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">result_t</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify"><code class=
=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">=
error_t</span><span style=3D"color: #660;" class=3D"styled-by-prettify"></s=
pan></code>&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> return_res</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 re=
sult_t res</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: #800;" class=3D"styled-by-prettify"=
>//same code as fill_res</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"><br>=C2=A0=C2=A0=C2=A0 return res;<br></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></span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">[</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"></span><span style=3D"color: #660;" class=3D"styled-by-prettify"></span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">obj</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">, err]</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> return_res</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">();</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br></span><span style=3D"color: #800;" class=3D"s=
tyled-by-prettify">//handle error</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span></div></code></div><br></div><div>The pr=
oblem is unless NRVO is performed (along with an optimized <code>`std::expe=
cted`</code>), this costs an extra move/copy, which is unacceptable when th=
is is almost every function in the code base (this becomes a major slowdown=
 and an increase in code size - more assembly instructions per function). N=
ow in this simple situation, I believe every compiler performs this optimiz=
ation so the issue is more theoretical then practical.</div><div><br></div>=
<div>In this example, the way we structure my code -=C2=A0 the error handli=
ng mechanism, is determined by whether or not the compiler performs NRVO, a=
nd that really really should not happen - that&#39;s exactly what the stand=
ard is for - something to rely on when structuring the code.</div><div><br>=
</div><div>The committee is already in the process of standardizing `<code>=
`std::expected` </code>or some similar error handling mechanism, and this s=
hould be a concern when transforming old code to use this new mechanism.</d=
iv><div><br></div><div>The solution: <br></div><div>Have some weak guarante=
e for performing NRVO to make at least this example not cause a move.</div>=
<div><br></div><div>In this thread I&#39;m looking for directions on both o=
ther use cases for partially guaranteed NRVO, as I am not sure this example=
 alone requires a language change. Also, I am looking for directions as to =
how this might be articulated in the standard, as I am not a language lawye=
r.</div><div><br></div><div>I am willing to write a proposal if this featur=
e is deemed worthy.<br></div><div><br></div><div>Previous work:<br></div><d=
iv>The only previous work I could find (in this forum and old mailings) is =
C++ 17&#39;s Guaranteed copy elision described in <a href=3D"http://www.ope=
n-std.org/jtc1/sc22/wg21/docs/papers/2015/p0135r0.html">http://www.open-std=
..org/jtc1/sc22/wg21/docs/papers/2015/p0135r0.html</a></div><div>In this pap=
er, the author, Richard Smith (who I know is active in this forum) did ment=
ion NRVO and said it will not be pursued due to technical difficulty to rea=
ch=C2=A0 a simple guarantee. I wonder if this point was discussed and inves=
tigated while reviewing this proposal?<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/707d3b51-fff7-4ce1-a2df-1e859ef4671f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/707d3b51-fff7-4ce1-a2df-1e859ef4671f=
%40isocpp.org</a>.<br />

------=_Part_37812_1960377468.1527593293611--

------=_Part_37811_681826996.1527593293611--

.

------=_Part_22925_1982452777.1527595263439
Content-Type: multipart/alternative;
 boundary="----=_Part_22926_1256159199.1527595263440"

------=_Part_22926_1256159199.1527595263440
Content-Type: text/plain; charset="UTF-8"

IIRC NRVO is "ensured" if the returned variable is the first one declared
in the function, as in your example.

Is this the case in your code base as well? Does it fail?
Can the problem be the code generated for the structured bindings? This is,
the std::expected is created inplace, but then the result_t is copied into
obj.


On Tuesday, May 29, 2018 at 2:28:13 PM UTC+3, Omer Rosler wrote:
>
> Hello,
> I'm looking for direction on whether this idea is worth pursing as a
> language feature.
>
> The problem:
> I want to change the error handling mechanism we currently have in our
> code base from returning error codes and passing out params into a better,
> modern one. Currently the code looks like this:
> #define OUT
> error_t fill_res(result_t* OUT res);
> result_t obj;
> error_t err = fill_res(&obj);
> //handle error
> I want to use the shiny `std::expected` or some similar available library
> that forces handling the error via a `[[nodiscard]]` warning or something
> similar:
> std::expected<result_t, error_t> return_res() {
>     result_t res;
>     //same code as fill_res
>     return res;
> }
> auto [obj, err] = return_res();
> //handle error
>
> The problem is unless NRVO is performed (along with an optimized
> `std::expected`), this costs an extra move/copy, which is unacceptable
> when this is almost every function in the code base (this becomes a major
> slowdown and an increase in code size - more assembly instructions per
> function). Now in this simple situation, I believe every compiler performs
> this optimization so the issue is more theoretical then practical.
>
> In this example, the way we structure my code -  the error handling
> mechanism, is determined by whether or not the compiler performs NRVO, and
> that really really should not happen - that's exactly what the standard is
> for - something to rely on when structuring the code.
>
> The committee is already in the process of standardizing ``std::expected` or
> some similar error handling mechanism, and this should be a concern when
> transforming old code to use this new mechanism.
>
> The solution:
> Have some weak guarantee for performing NRVO to make at least this example
> not cause a move.
>
> In this thread I'm looking for directions on both other use cases for
> partially guaranteed NRVO, as I am not sure this example alone requires a
> language change. Also, I am looking for directions as to how this might be
> articulated in the standard, as I am not a language lawyer.
>
> I am willing to write a proposal if this feature is deemed worthy.
>
> Previous work:
> The only previous work I could find (in this forum and old mailings) is
> C++ 17's Guaranteed copy elision described in
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0135r0.html
> In this paper, the author, Richard Smith (who I know is active in this
> forum) did mention NRVO and said it will not be pursued due to technical
> difficulty to reach  a simple guarantee. I wonder if this point was
> discussed and investigated while reviewing this proposal?
>

--
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/43ff8918-1164-4f91-89bd-7567c2ba4c80%40isocpp.org.

------=_Part_22926_1256159199.1527595263440
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>IIRC NRVO is &quot;ensured&quot; if the returned vari=
able is the first one declared in the function, as in your example.</div><d=
iv><br></div><div>Is this the case in your code base as well? Does it fail?=
=C2=A0</div><div>Can the problem be the code generated for the structured b=
indings? This is, the std::expected is created inplace, but then the=C2=A0<=
span style=3D"background-color: transparent; border-bottom-color: rgb(102, =
102, 0); border-bottom-style: none; border-bottom-width: 0px; border-image-=
outset: 0; border-image-repeat: stretch; border-image-slice: 100%; border-i=
mage-source: none; border-image-width: 1; border-left-color: rgb(102, 102, =
0); border-left-style: none; border-left-width: 0px; border-right-color: rg=
b(102, 102, 0); border-right-style: none; border-right-width: 0px; border-t=
op-color: rgb(102, 102, 0); border-top-style: none; border-top-width: 0px; =
color: rgb(102, 102, 0); font-family: &amp;quot;Arial&amp;quot;,&amp;quot;H=
elvetica&amp;quot;,sans-serif; font-size: 13px; font-style: normal; font-va=
riant: normal; font-weight: 400; letter-spacing: normal; margin-bottom: 0px=
; margin-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; padding=
-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text=
-align: left; text-decoration: none; text-indent: 0px; text-transform: none=
; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;">=
</span><span style=3D"background-color: transparent; border-bottom-color: r=
gb(0, 0, 0); border-bottom-style: none; border-bottom-width: 0px; border-im=
age-outset: 0; border-image-repeat: stretch; border-image-slice: 100%; bord=
er-image-source: none; border-image-width: 1; border-left-color: rgb(0, 0, =
0); border-left-style: none; border-left-width: 0px; border-right-color: rg=
b(0, 0, 0); border-right-style: none; border-right-width: 0px; border-top-c=
olor: rgb(0, 0, 0); border-top-style: none; border-top-width: 0px; color: r=
gb(0, 0, 0); font-family: &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp=
;quot;,sans-serif; font-size: 13px; font-style: normal; font-variant: norma=
l; font-weight: 400; letter-spacing: normal; margin-bottom: 0px; margin-lef=
t: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; padding-bottom: 0px=
; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left=
; text-decoration: none; text-indent: 0px; text-transform: none; -webkit-te=
xt-stroke-width: 0px; white-space: normal; word-spacing: 0px;">result_t is =
copied into obj.</span><span style=3D"background-color: transparent; border=
-bottom-color: rgb(102, 102, 0); border-bottom-style: none; border-bottom-w=
idth: 0px; border-image-outset: 0; border-image-repeat: stretch; border-ima=
ge-slice: 100%; border-image-source: none; border-image-width: 1; border-le=
ft-color: rgb(102, 102, 0); border-left-style: none; border-left-width: 0px=
; border-right-color: rgb(102, 102, 0); border-right-style: none; border-ri=
ght-width: 0px; border-top-color: rgb(102, 102, 0); border-top-style: none;=
 border-top-width: 0px; color: rgb(102, 102, 0); font-family: &amp;quot;Ari=
al&amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-size: 13px; fon=
t-style: normal; font-variant: normal; font-weight: 400; letter-spacing: no=
rmal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: =
0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; padding-right: 0px=
; padding-top: 0px; text-align: left; text-decoration: none; text-indent: 0=
px; text-transform: none; -webkit-text-stroke-width: 0px; white-space: norm=
al; word-spacing: 0px;"></span></div><div><b></b><i></i><u></u><sub></sub><=
sup></sup><strike></strike><br></div><br>On Tuesday, May 29, 2018 at 2:28:1=
3 PM UTC+3, Omer Rosler 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>Hello, <br></div><div>I&#39;m looking for direction o=
n whether this idea is worth pursing as a language feature.</div><div><br><=
/div><div>The problem:</div><div>I want to change the error handling mechan=
ism we currently have in our code base from returning error codes and passi=
ng out params into a better, modern one. Currently the code looks like this=
:<br></div><div><div style=3D"background-color:rgb(250,250,250);border-colo=
r:rgb(187,187,187);border-style:solid;border-width:1px"><code><div><span st=
yle=3D"color:#800">#define</span><span style=3D"color:#000"> OUT<br>error_t=
 fill_res</span><span style=3D"color:#660">(</span><span style=3D"color:#00=
0">result_t</span><span style=3D"color:#660">*</span><span style=3D"color:#=
000"> OUT res</span><span style=3D"color:#660">);</span><span style=3D"colo=
r:#000"><br>result_t obj</span><span style=3D"color:#660">;</span><span sty=
le=3D"color:#000"><br>error_t err </span><span style=3D"color:#660">=3D</sp=
an><span style=3D"color:#000"> fill_res</span><span style=3D"color:#660">(&=
amp;</span><span style=3D"color:#000">obj</span><span style=3D"color:#660">=
);</span><span style=3D"color:#000"><br></span><span style=3D"color:#800">/=
/handle error</span><span style=3D"color:#000"><br></span></div></code></di=
v>I want to use the shiny <code>`std::expected`</code> or some similar avai=
lable library that forces handling the error via a <code>`[[nodiscard]]`</c=
ode> warning or something similar:</div><div><div style=3D"background-color=
:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-w=
idth:1px"><code><div><span style=3D"color:#000">std</span><span style=3D"co=
lor:#660">::</span><span style=3D"color:#000">expected</span><span style=3D=
"color:#660">&lt;</span><span style=3D"color:#000">result_t</span><span sty=
le=3D"color:#660">,</span><span style=3D"color:#000"> </span><span style=3D=
"color:#660"><code><span style=3D"color:#000">error_t</span><span style=3D"=
color:#660"></span></code>&gt;</span><span style=3D"color:#000"> return_res=
</span><span style=3D"color:#660">()</span><span style=3D"color:#000"> </sp=
an><span style=3D"color:#660">{</span><span style=3D"color:#000"><br>=C2=A0=
 =C2=A0 result_t res</span><span style=3D"color:#660">;</span><span style=
=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#800">//same =
code as fill_res</span><span style=3D"color:#000"><br>=C2=A0=C2=A0=C2=A0 re=
turn res;<br></span><span style=3D"color:#660">}</span><span style=3D"color=
:#000"><br></span><span style=3D"color:#008">auto</span><span style=3D"colo=
r:#000"> </span><span style=3D"color:#660">[</span><span style=3D"color:#00=
0"></span><span style=3D"color:#660"></span><span style=3D"color:#000">obj<=
/span><span style=3D"color:#660">, err]</span><span style=3D"color:#000"> <=
/span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> retu=
rn_res</span><span style=3D"color:#660">();</span><span style=3D"color:#000=
"><br></span><span style=3D"color:#800">//handle error</span><span style=3D=
"color:#000"><br></span></div></code></div><br></div><div>The problem is un=
less NRVO is performed (along with an optimized <code>`std::expected`</code=
>), this costs an extra move/copy, which is unacceptable when this is almos=
t every function in the code base (this becomes a major slowdown and an inc=
rease in code size - more assembly instructions per function). Now in this =
simple situation, I believe every compiler performs this optimization so th=
e issue is more theoretical then practical.</div><div><br></div><div>In thi=
s example, the way we structure my code -=C2=A0 the error handling mechanis=
m, is determined by whether or not the compiler performs NRVO, and that rea=
lly really should not happen - that&#39;s exactly what the standard is for =
- something to rely on when structuring the code.</div><div><br></div><div>=
The committee is already in the process of standardizing `<code>`std::expec=
ted` </code>or some similar error handling mechanism, and this should be a =
concern when transforming old code to use this new mechanism.</div><div><br=
></div><div>The solution: <br></div><div>Have some weak guarantee for perfo=
rming NRVO to make at least this example not cause a move.</div><div><br></=
div><div>In this thread I&#39;m looking for directions on both other use ca=
ses for partially guaranteed NRVO, as I am not sure this example alone requ=
ires a language change. Also, I am looking for directions as to how this mi=
ght be articulated in the standard, as I am not a language lawyer.</div><di=
v><br></div><div>I am willing to write a proposal if this feature is deemed=
 worthy.<br></div><div><br></div><div>Previous work:<br></div><div>The only=
 previous work I could find (in this forum and old mailings) is C++ 17&#39;=
s Guaranteed copy elision described in <a onmousedown=3D"this.href=3D&#39;h=
ttp://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2=
Fwg21%2Fdocs%2Fpapers%2F2015%2Fp0135r0.html\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNH-chCvEyN34SVD7oE5qD-G2jg-8A&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjt=
c1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fp0135r0.html\x26sa\x3dD\x26sntz\x=
3d1\x26usg\x3dAFQjCNH-chCvEyN34SVD7oE5qD-G2jg-8A&#39;;return true;" href=3D=
"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0135r0.html" targ=
et=3D"_blank" rel=3D"nofollow">http://www.open-std.org/jtc1/<wbr>sc22/wg21/=
docs/papers/2015/<wbr>p0135r0.html</a></div><div>In this paper, the author,=
 Richard Smith (who I know is active in this forum) did mention NRVO and sa=
id it will not be pursued due to technical difficulty to reach=C2=A0 a simp=
le guarantee. I wonder if this point was discussed and investigated while r=
eviewing this proposal?<br></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/43ff8918-1164-4f91-89bd-7567c2ba4c80%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/43ff8918-1164-4f91-89bd-7567c2ba4c80=
%40isocpp.org</a>.<br />

------=_Part_22926_1256159199.1527595263440--

------=_Part_22925_1982452777.1527595263439--

.

------=_Part_11226_714570543.1527595591255
Content-Type: multipart/alternative;
 boundary="----=_Part_11227_2079942.1527595591255"

------=_Part_11227_2079942.1527595591255
Content-Type: text/plain; charset="UTF-8"

In this case it is only permitted by the standard and not required (as
`res` is not a prvalue but an lvalue, guaranteed copy elision does not
apply)

On Tuesday, May 29, 2018 at 3:01:03 PM UTC+3, mihailn...@gmail.com wrote:
>
> IIRC NRVO is "ensured" if the returned variable is the first one declared
> in the function, as in your example.
>
> Is this the case in your code base as well? Does it fail?
> Can the problem be the code generated for the structured bindings? This
> is, the std::expected is created inplace, but then the result_t is copied
> into obj.
>
>
> On Tuesday, May 29, 2018 at 2:28:13 PM UTC+3, Omer Rosler wrote:
>>
>> Hello,
>> I'm looking for direction on whether this idea is worth pursing as a
>> language feature.
>>
>> The problem:
>> I want to change the error handling mechanism we currently have in our
>> code base from returning error codes and passing out params into a better,
>> modern one. Currently the code looks like this:
>> #define OUT
>> error_t fill_res(result_t* OUT res);
>> result_t obj;
>> error_t err = fill_res(&obj);
>> //handle error
>> I want to use the shiny `std::expected` or some similar available
>> library that forces handling the error via a `[[nodiscard]]` warning or
>> something similar:
>> std::expected<result_t, error_t> return_res() {
>>     result_t res;
>>     //same code as fill_res
>>     return res;
>> }
>> auto [obj, err] = return_res();
>> //handle error
>>
>> The problem is unless NRVO is performed (along with an optimized
>> `std::expected`), this costs an extra move/copy, which is unacceptable
>> when this is almost every function in the code base (this becomes a major
>> slowdown and an increase in code size - more assembly instructions per
>> function). Now in this simple situation, I believe every compiler performs
>> this optimization so the issue is more theoretical then practical.
>>
>> In this example, the way we structure my code -  the error handling
>> mechanism, is determined by whether or not the compiler performs NRVO, and
>> that really really should not happen - that's exactly what the standard is
>> for - something to rely on when structuring the code.
>>
>> The committee is already in the process of standardizing ``std::expected`
>> or some similar error handling mechanism, and this should be a concern
>> when transforming old code to use this new mechanism.
>>
>> The solution:
>> Have some weak guarantee for performing NRVO to make at least this
>> example not cause a move.
>>
>> In this thread I'm looking for directions on both other use cases for
>> partially guaranteed NRVO, as I am not sure this example alone requires a
>> language change. Also, I am looking for directions as to how this might be
>> articulated in the standard, as I am not a language lawyer.
>>
>> I am willing to write a proposal if this feature is deemed worthy.
>>
>> Previous work:
>> The only previous work I could find (in this forum and old mailings) is
>> C++ 17's Guaranteed copy elision described in
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0135r0.html
>> In this paper, the author, Richard Smith (who I know is active in this
>> forum) did mention NRVO and said it will not be pursued due to technical
>> difficulty to reach  a simple guarantee. I wonder if this point was
>> discussed and investigated while reviewing this proposal?
>>
>

--
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/67e9654e-1937-4d6b-b2a9-cae8773693b4%40isocpp.org.

------=_Part_11227_2079942.1527595591255
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">In this case it is only permitted by the standard and not =
required (as `res` is not a prvalue but an lvalue, guaranteed copy elision =
does not apply)<br><br>On Tuesday, May 29, 2018 at 3:01:03 PM UTC+3, mihail=
n...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div>IIRC NRVO is &quot;ensured&quot; if the returned variable is =
the first one declared in the function, as in your example.</div><div><br><=
/div><div>Is this the case in your code base as well? Does it fail?=C2=A0</=
div><div>Can the problem be the code generated for the structured bindings?=
 This is, the std::expected is created inplace, but then the=C2=A0<span></s=
pan><span>result_t is copied into obj.</span><span></span></div><div><b></b=
><i></i><u></u><sub></sub><sup></sup><strike></strike><br></div><br>On Tues=
day, May 29, 2018 at 2:28:13 PM UTC+3, Omer Rosler wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div>Hello, <br></div><div>I&#39;m =
looking for direction on whether this idea is worth pursing as a language f=
eature.</div><div><br></div><div>The problem:</div><div>I want to change th=
e error handling mechanism we currently have in our code base from returnin=
g error codes and passing out params into a better, modern one. Currently t=
he code looks like this:<br></div><div><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:#800">#define</span><span style=3D"colo=
r:#000"> OUT<br>error_t fill_res</span><span style=3D"color:#660">(</span><=
span style=3D"color:#000">result_t</span><span style=3D"color:#660">*</span=
><span style=3D"color:#000"> OUT res</span><span style=3D"color:#660">);</s=
pan><span style=3D"color:#000"><br>result_t obj</span><span style=3D"color:=
#660">;</span><span style=3D"color:#000"><br>error_t err </span><span style=
=3D"color:#660">=3D</span><span style=3D"color:#000"> fill_res</span><span =
style=3D"color:#660">(&amp;</span><span style=3D"color:#000">obj</span><spa=
n style=3D"color:#660">);</span><span style=3D"color:#000"><br></span><span=
 style=3D"color:#800">//handle error</span><span style=3D"color:#000"><br><=
/span></div></code></div>I want to use the shiny <code>`std::expected`</cod=
e> or some similar available library that forces handling the error via a <=
code>`[[nodiscard]]`</code> warning or something similar:</div><div><div st=
yle=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);bord=
er-style:solid;border-width:1px"><code><div><span style=3D"color:#000">std<=
/span><span style=3D"color:#660">::</span><span style=3D"color:#000">expect=
ed</span><span style=3D"color:#660">&lt;</span><span style=3D"color:#000">r=
esult_t</span><span style=3D"color:#660">,</span><span style=3D"color:#000"=
> </span><span style=3D"color:#660"><code><span style=3D"color:#000">error_=
t</span><span style=3D"color:#660"></span></code>&gt;</span><span style=3D"=
color:#000"> return_res</span><span style=3D"color:#660">()</span><span sty=
le=3D"color:#000"> </span><span style=3D"color:#660">{</span><span style=3D=
"color:#000"><br>=C2=A0 =C2=A0 result_t res</span><span style=3D"color:#660=
">;</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=
=3D"color:#800">//same code as fill_res</span><span style=3D"color:#000"><b=
r>=C2=A0=C2=A0=C2=A0 return res;<br></span><span style=3D"color:#660">}</sp=
an><span style=3D"color:#000"><br></span><span style=3D"color:#008">auto</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#660">[</span><=
span style=3D"color:#000"></span><span style=3D"color:#660"></span><span st=
yle=3D"color:#000">obj</span><span style=3D"color:#660">, err]</span><span =
style=3D"color:#000"> </span><span style=3D"color:#660">=3D</span><span sty=
le=3D"color:#000"> return_res</span><span style=3D"color:#660">();</span><s=
pan style=3D"color:#000"><br></span><span style=3D"color:#800">//handle err=
or</span><span style=3D"color:#000"><br></span></div></code></div><br></div=
><div>The problem is unless NRVO is performed (along with an optimized <cod=
e>`std::expected`</code>), this costs an extra move/copy, which is unaccept=
able when this is almost every function in the code base (this becomes a ma=
jor slowdown and an increase in code size - more assembly instructions per =
function). Now in this simple situation, I believe every compiler performs =
this optimization so the issue is more theoretical then practical.</div><di=
v><br></div><div>In this example, the way we structure my code -=C2=A0 the =
error handling mechanism, is determined by whether or not the compiler perf=
orms NRVO, and that really really should not happen - that&#39;s exactly wh=
at the standard is for - something to rely on when structuring the code.</d=
iv><div><br></div><div>The committee is already in the process of standardi=
zing `<code>`std::expected` </code>or some similar error handling mechanism=
, and this should be a concern when transforming old code to use this new m=
echanism.</div><div><br></div><div>The solution: <br></div><div>Have some w=
eak guarantee for performing NRVO to make at least this example not cause a=
 move.</div><div><br></div><div>In this thread I&#39;m looking for directio=
ns on both other use cases for partially guaranteed NRVO, as I am not sure =
this example alone requires a language change. Also, I am looking for direc=
tions as to how this might be articulated in the standard, as I am not a la=
nguage lawyer.</div><div><br></div><div>I am willing to write a proposal if=
 this feature is deemed worthy.<br></div><div><br></div><div>Previous work:=
<br></div><div>The only previous work I could find (in this forum and old m=
ailings) is C++ 17&#39;s Guaranteed copy elision described in <a href=3D"ht=
tp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0135r0.html" rel=3D"=
nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;http://www.goog=
le.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2=
Fpapers%2F2015%2Fp0135r0.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH-chC=
vEyN34SVD7oE5qD-G2jg-8A&#39;;return true;" onclick=3D"this.href=3D&#39;http=
://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg=
21%2Fdocs%2Fpapers%2F2015%2Fp0135r0.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3d=
AFQjCNH-chCvEyN34SVD7oE5qD-G2jg-8A&#39;;return true;">http://www.open-std.o=
rg/jtc1/<wbr>sc22/wg21/docs/papers/2015/<wbr>p0135r0.html</a></div><div>In =
this paper, the author, Richard Smith (who I know is active in this forum) =
did mention NRVO and said it will not be pursued due to technical difficult=
y to reach=C2=A0 a simple guarantee. I wonder if this point was discussed a=
nd investigated while reviewing this proposal?<br></div></div></blockquote>=
</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/67e9654e-1937-4d6b-b2a9-cae8773693b4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/67e9654e-1937-4d6b-b2a9-cae8773693b4=
%40isocpp.org</a>.<br />

------=_Part_11227_2079942.1527595591255--

------=_Part_11226_714570543.1527595591255--

.

------=_Part_37656_990425526.1527596115244
Content-Type: multipart/alternative;
 boundary="----=_Part_37657_1735038284.1527596115244"

------=_Part_37657_1735038284.1527596115244
Content-Type: text/plain; charset="UTF-8"



On Tuesday, May 29, 2018 at 3:06:31 PM UTC+3, Omer Rosler wrote:
>
> In this case it is only permitted by the standard and not required (as
> `res` is not a prvalue but an lvalue, guaranteed copy elision does not
> apply)
>

Yeah, but doesn't "all compilers" do it as long as it is the first
argument?
I am asking for myself actually, because I structure the code that way as
rule of thumb, but I haven't "tested it" as my code is not perf. critical.

--
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/c44fb013-da0e-4df9-93dd-f37e1aa86519%40isocpp.org.

------=_Part_37657_1735038284.1527596115244
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, May 29, 2018 at 3:06:31 PM UTC+3, Omer=
 Rosler wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
>In this case it is only permitted by the standard and not required (as `re=
s` is not a prvalue but an lvalue, guaranteed copy elision does not apply)<=
br></div></blockquote><div><br></div><div>Yeah, but doesn&#39;t &quot;all c=
ompilers&quot; do it as long as it is the first argument?=C2=A0</div><div>I=
 am asking for myself actually, because I structure the code that way as ru=
le of thumb, but I haven&#39;t &quot;tested it&quot; as my code is not perf=
.. critical.=C2=A0</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/c44fb013-da0e-4df9-93dd-f37e1aa86519%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c44fb013-da0e-4df9-93dd-f37e1aa86519=
%40isocpp.org</a>.<br />

------=_Part_37657_1735038284.1527596115244--

------=_Part_37656_990425526.1527596115244--

.

------=_Part_37707_1882317961.1527597330779
Content-Type: multipart/alternative;
 boundary="----=_Part_37708_746957596.1527597330780"

------=_Part_37708_746957596.1527597330780
Content-Type: text/plain; charset="UTF-8"

Indeed, that is why I wrote this issue is more theoretical than practical.
The point I'm making is that a major decision of how I structure my code
depends on the assumption of this optimization, so this turns into more
then a mere optimization, therefore the assumption of NRVO (in some cases)
should belong in the standard.

On Tuesday, May 29, 2018 at 3:15:15 PM UTC+3, mihailn...@gmail.com wrote:
>
>
>
> On Tuesday, May 29, 2018 at 3:06:31 PM UTC+3, Omer Rosler wrote:
>>
>> In this case it is only permitted by the standard and not required (as
>> `res` is not a prvalue but an lvalue, guaranteed copy elision does not
>> apply)
>>
>
> Yeah, but doesn't "all compilers" do it as long as it is the first
> argument?
> I am asking for myself actually, because I structure the code that way as
> rule of thumb, but I haven't "tested it" as my code is not perf. critical.
>

--
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/ebb679c3-79fe-4e1d-9892-12f001efff1b%40isocpp.org.

------=_Part_37708_746957596.1527597330780
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Indeed, that is why I wrote this issue is more theore=
tical than practical.</div>The
 point I&#39;m making is that a major decision of how I structure my code=
=20
depends on the assumption of this optimization, so this turns into more=20
then a mere optimization, therefore the assumption of NRVO (in some cases) =
should belong in the=20
standard.<br><br>On Tuesday, May 29, 2018 at 3:15:15 PM UTC+3, mihailn...@g=
mail.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=
"><br><br>On Tuesday, May 29, 2018 at 3:06:31 PM UTC+3, Omer Rosler 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">In this case it is =
only permitted by the standard and not required (as `res` is not a prvalue =
but an lvalue, guaranteed copy elision does not apply)<br></div></blockquot=
e><div><br></div><div>Yeah, but doesn&#39;t &quot;all compilers&quot; do it=
 as long as it is the first argument?=C2=A0</div><div>I am asking for mysel=
f actually, because I structure the code that way as rule of thumb, but I h=
aven&#39;t &quot;tested it&quot; as my code is not perf. critical.=C2=A0</d=
iv></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/ebb679c3-79fe-4e1d-9892-12f001efff1b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ebb679c3-79fe-4e1d-9892-12f001efff1b=
%40isocpp.org</a>.<br />

------=_Part_37708_746957596.1527597330780--

------=_Part_37707_1882317961.1527597330779--

.

------=_Part_38403_1572183424.1527600935840
Content-Type: multipart/alternative;
 boundary="----=_Part_38404_950471595.1527600935841"

------=_Part_38404_950471595.1527600935841
Content-Type: text/plain; charset="UTF-8"

It's important to recognize that what you're talking about is *not* NRVO.
Why?

Because what you're returning is a different type from the declared
variable. Your variable is a `result_t`; your return value is something
that *contains* a `result_t`.

Elision works by eliminating a copy/move between the same types, because it
is logically a no-op. But copy/move between different types is a conversion
operation, and it is not reasonable to expect such a thing to be a logical
no-op.

Not to mention, there's no way to really make this work. Elision works
because the storage for the return value object is provided by the caller.
As such, a function which performs elision can simply silently assign the
storage for a stack variable or temporary to the storage provided by the
caller.

In this case, the caller provided storage for an `expected`, which is
undoubtedly larger than the storage for a `result_t`. In order for the
compiler to properly "elide" this, it would have to silently construct that
`expected`, and do so in a way that it gets the parameters that will cause
it to construct a `result_t` internally. Then it would have to silently
fetch that address using `expected`'s interface and silently use that
address anywhere that you use the variable.

That's just not practical. Not unless `expected` is a magic type with an
interface that the compiler is explicitly written to understand and
manipulate.

For the `expected` case, just create an `expected` object internally and
let regular NRVO actually do its job. That is, do the job I mentioned
above. Or wait for Herb's lightweight exception proposal.

--
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/9131729d-99f2-45ec-bcff-02be73e27552%40isocpp.org.

------=_Part_38404_950471595.1527600935841
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>It&#39;s important to recognize that what you&#39;re =
talking about is <i>not</i> NRVO. Why?</div><div><br></div><div>Because wha=
t you&#39;re returning is a different type from the declared variable. Your=
 variable is a `result_t`; your return value is something that <i>contains<=
/i> a `result_t`.</div><div><br></div><div>Elision works by eliminating a c=
opy/move between the same types, because it is logically a no-op. But copy/=
move between different types is a conversion operation, and it is not reaso=
nable to expect such a thing to be a logical no-op.<br></div><div><br></div=
><div>Not to mention, there&#39;s no way to really make this work. Elision =
works because the storage for the return value object is provided by the ca=
ller. As such, a function which performs elision can simply silently assign=
 the storage for a stack variable or temporary to the storage provided by t=
he caller.</div><div><br></div><div>In this case, the caller provided stora=
ge for an `expected`, which is undoubtedly larger than the storage for a `r=
esult_t`. In order for the compiler to properly &quot;elide&quot; this, it =
would have to silently construct that `expected`, and do so in a way that i=
t gets the parameters that will cause it to construct a `result_t` internal=
ly. Then it would have to silently fetch that address using `expected`&#39;=
s interface and silently use that address anywhere that you use the variabl=
e.</div><div><br></div><div>That&#39;s just not practical. Not unless `expe=
cted` is a magic type with an interface that the compiler is explicitly wri=
tten to understand and manipulate.<br></div><div><br></div><div>For the `ex=
pected` case, just create an `expected` object internally and let regular N=
RVO actually do its job. That is, do the job I mentioned above. Or wait for=
 Herb&#39;s lightweight exception proposal.<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/9131729d-99f2-45ec-bcff-02be73e27552%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9131729d-99f2-45ec-bcff-02be73e27552=
%40isocpp.org</a>.<br />

------=_Part_38404_950471595.1527600935841--

------=_Part_38403_1572183424.1527600935840--

.

------=_Part_37602_1832269765.1527601469101
Content-Type: multipart/alternative;
 boundary="----=_Part_37603_1880714507.1527601469101"

------=_Part_37603_1880714507.1527601469101
Content-Type: text/plain; charset="UTF-8"

Named RVO is essentially the ability to initialize the return value object
and use it as a stack variable, then return it later on. So if you're going
to enforce NRVO, that's probably what it should look like: instead of the
compiler going behind your back to create the return value object, you
declare a stack variable which *is* the return value object.

A while back, I started poking around a bit with an idea in this direction
<https://github.com/NicolBolas/Proposal-Ideas/blob/master/Named%20Return%20Value%20Variables.md>.
I didn't really take it very far; you're welcome to add to it if you like.

--
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/ce40b33c-925e-4bc2-9d23-b808d574c553%40isocpp.org.

------=_Part_37603_1880714507.1527601469101
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Named RVO is essentially the ability to initialize th=
e return value object and use it as a stack variable, then return it later =
on. So if you&#39;re going to enforce NRVO, that&#39;s probably what it sho=
uld look like: instead of the compiler going behind your back to create the=
 return value object, you declare a stack variable which <i>is</i> the retu=
rn value object.</div><div><br></div><div>A while back, I started poking ar=
ound a bit with <a href=3D"https://github.com/NicolBolas/Proposal-Ideas/blo=
b/master/Named%20Return%20Value%20Variables.md">an idea in this direction</=
a>. I didn&#39;t really take it very far; you&#39;re welcome to add to it i=
f you like.<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/ce40b33c-925e-4bc2-9d23-b808d574c553%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ce40b33c-925e-4bc2-9d23-b808d574c553=
%40isocpp.org</a>.<br />

------=_Part_37603_1880714507.1527601469101--

------=_Part_37602_1832269765.1527601469101--

.

--000000000000388368056d587c20
Content-Type: text/plain; charset="UTF-8"

Nicol,

the 'return' statement is already tag enough - but a [[nrvo]] tag
(straw-man proposal) on the variable *would* make it so that a compiler
could issue a warning (or error) if NRVO wasn't actually then used.

no?

On Tue, May 29, 2018 at 2:44 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> Named RVO is essentially the ability to initialize the return value object
> and use it as a stack variable, then return it later on. So if you're going
> to enforce NRVO, that's probably what it should look like: instead of the
> compiler going behind your back to create the return value object, you
> declare a stack variable which *is* the return value object.
>
> A while back, I started poking around a bit with an idea in this direction
> <https://github.com/NicolBolas/Proposal-Ideas/blob/master/Named%20Return%20Value%20Variables.md>.
> I didn't really take it very far; you're welcome to add to it if you like.
>
> --
> 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/ce40b33c-925e-4bc2-
> 9d23-b808d574c553%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ce40b33c-925e-4bc2-9d23-b808d574c553%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

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

--000000000000388368056d587c20
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Nicol,<div><br></div><div>the &#39;return&#39; statement i=
s already tag enough - but a [[nrvo]] tag (straw-man proposal) on the varia=
ble *would* make it so that a compiler could issue a warning (or error) if =
NRVO wasn&#39;t actually then used.</div><div><br></div><div>no?</div></div=
><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, May 29, =
2018 at 2:44 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"mailto:jmckes=
son@gmail.com" target=3D"_blank">jmckesson@gmail.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>Named RVO is essent=
ially the ability to initialize the return value object and use it as a sta=
ck variable, then return it later on. So if you&#39;re going to enforce NRV=
O, that&#39;s probably what it should look like: instead of the compiler go=
ing behind your back to create the return value object, you declare a stack=
 variable which <i>is</i> the return value object.</div><div><br></div><div=
>A while back, I started poking around a bit with <a href=3D"https://github=
..com/NicolBolas/Proposal-Ideas/blob/master/Named%20Return%20Value%20Variabl=
es.md" target=3D"_blank">an idea in this direction</a>. I didn&#39;t really=
 take it very far; you&#39;re welcome to add to it if you like.<br></div></=
div><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ce40b33c-925e-4bc2-9d23-b808d574c553%=
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/ce40=
b33c-925e-4bc2-<wbr>9d23-b808d574c553%40isocpp.org</a><wbr>.<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/CAANG%3DkUbrN0LB3KcKJXbfVt7sP5Wc-wB4-=
52vPAeOzne83HD7g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkUbrN0L=
B3KcKJXbfVt7sP5Wc-wB4-52vPAeOzne83HD7g%40mail.gmail.com</a>.<br />

--000000000000388368056d587c20--

.

------=_Part_21626_73204309.1527604754075
Content-Type: multipart/alternative;
 boundary="----=_Part_21627_951703831.1527604754075"

------=_Part_21627_951703831.1527604754075
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tuesday, May 29, 2018 at 9:48:14 AM UTC-4, Ga=C5=A1per A=C5=BEman wrote:
>
> Nicol,
>
> the 'return' statement is already tag enough - but a [[nrvo]] tag=20
> (straw-man proposal) on the variable *would* make it so that a compiler=
=20
> could issue a warning (or error) if NRVO wasn't actually then used.
>
> no?
>

OK, so let's say you use this attribute and get a warning. And let's say=20
that this warning is actually detailed enough to tell you what to change to=
=20
fix it.

What happens if you switch to a different compiler that issues the warning=
=20
for the same variable in your "fixed" code? And what happens if the only=20
way to fix the new one breaks the old one?

I don't know of any simple guidelines that ensure NRVO across compilers.

Now, we could apply this attribute to a variable declaration and apply the=
=20
rules in my proposal to that. Except that everywhere it says "ill-formed"=
=20
or whatever, you would change that to "undefined behavior" or some such.=20
But really, that's ultimately a matter of how you spell it, not what it=20
means. It would also not allow you to use the convenient `return auto`=20
syntax.

And it would be yet another expansion of attributes-as-keywords. The fact=
=20
that this keeps happening ought to be as sign to someone that C++ needs to=
=20
make it easier to create new keywords.

--=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/be5e7800-01df-4007-9a29-82499589e09f%40isocpp.or=
g.

------=_Part_21627_951703831.1527604754075
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, May 29, 2018 at 9:48:14 AM UTC-4, Ga=C5=A1per =
A=C5=BEman 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">Nicol,<div><br></div><div>the &#39;return&#39; statement is already tag=
 enough - but a [[nrvo]] tag (straw-man proposal) on the variable *would* m=
ake it so that a compiler could issue a warning (or error) if NRVO wasn&#39=
;t actually then used.</div><div><br></div><div>no?</div></div></blockquote=
><div><br></div><div>OK, so let&#39;s say you use this attribute and get a =
warning. And let&#39;s say that this warning is actually detailed enough to=
 tell you what to change to fix it.</div><div><br></div><div>What happens i=
f you switch to a different compiler that issues the warning for the same v=
ariable in your &quot;fixed&quot; code? And what happens if the only way to=
 fix the new one breaks the old one?</div><div><br></div><div>I don&#39;t k=
now of any simple guidelines that ensure NRVO across compilers.</div><div><=
br></div><div>Now, we could apply this attribute to a variable declaration =
and apply the rules in my proposal to that. Except that everywhere it says =
&quot;ill-formed&quot; or whatever, you would change that to &quot;undefine=
d behavior&quot; or some such. But really, that&#39;s ultimately a matter o=
f how you spell it, not what it means. It would also not allow you to use t=
he convenient `return auto` syntax.</div><div><br></div><div>And it would b=
e yet another expansion of attributes-as-keywords. The fact that this keeps=
 happening ought to be as sign to someone that C++ needs to make it easier =
to create new keywords.</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/be5e7800-01df-4007-9a29-82499589e09f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/be5e7800-01df-4007-9a29-82499589e09f=
%40isocpp.org</a>.<br />

------=_Part_21627_951703831.1527604754075--

------=_Part_21626_73204309.1527604754075--

.

------=_Part_16168_1091301530.1527610018275
Content-Type: multipart/alternative;
 boundary="----=_Part_16169_170584003.1527610018275"

------=_Part_16169_170584003.1527610018275
Content-Type: text/plain; charset="UTF-8"

Well, you're right on this example, I have missed the fact that the
conversion is not covered in these rules.
This raises a problem, if we can't make this work - how does the committee
expect the community to use a non-zero-overhead (theoretically, or with a
bad optimizer) error handling mechanism?
`expected` is supposed to be a replacement for error codes + out params
(not a completely drop in replacement, but these mechanisms satisfy the
same needs) and this means it is not a zero-overhead one. Was this concern
discussed during LEWG review?

On Tuesday, May 29, 2018 at 4:35:36 PM UTC+3, Nicol Bolas wrote:
>
> It's important to recognize that what you're talking about is *not* NRVO.
> Why?
>
> Because what you're returning is a different type from the declared
> variable. Your variable is a `result_t`; your return value is something
> that *contains* a `result_t`.
>
> Elision works by eliminating a copy/move between the same types, because
> it is logically a no-op. But copy/move between different types is a
> conversion operation, and it is not reasonable to expect such a thing to be
> a logical no-op.
>
> Not to mention, there's no way to really make this work. Elision works
> because the storage for the return value object is provided by the caller.
> As such, a function which performs elision can simply silently assign the
> storage for a stack variable or temporary to the storage provided by the
> caller.
>
> In this case, the caller provided storage for an `expected`, which is
> undoubtedly larger than the storage for a `result_t`. In order for the
> compiler to properly "elide" this, it would have to silently construct that
> `expected`, and do so in a way that it gets the parameters that will cause
> it to construct a `result_t` internally. Then it would have to silently
> fetch that address using `expected`'s interface and silently use that
> address anywhere that you use the variable.
>
> That's just not practical. Not unless `expected` is a magic type with an
> interface that the compiler is explicitly written to understand and
> manipulate.
>
> For the `expected` case, just create an `expected` object internally and
> let regular NRVO actually do its job. That is, do the job I mentioned
> above. Or wait for Herb's lightweight exception proposal.
>

--
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/6a2649ec-c28d-452a-a10d-db821ee0ac0b%40isocpp.org.

------=_Part_16169_170584003.1527610018275
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Well, you&#39;re right on this example, I have missed=
 the fact that the conversion is not covered in these rules.</div><div>This=
 raises a problem, if we can&#39;t make this work - how does the committee =
expect the community to use a non-zero-overhead (theoretically, or with a b=
ad optimizer) error handling mechanism?</div><div>`expected` is supposed to=
 be a replacement for error codes + out params (not a completely drop in re=
placement, but these mechanisms satisfy the same needs) and this means it i=
s not a zero-overhead one. Was this concern discussed during LEWG review?<b=
r></div><br>On Tuesday, May 29, 2018 at 4:35:36 PM UTC+3, Nicol Bolas wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>It&#39;=
s important to recognize that what you&#39;re talking about is <i>not</i> N=
RVO. Why?</div><div><br></div><div>Because what you&#39;re returning is a d=
ifferent type from the declared variable. Your variable is a `result_t`; yo=
ur return value is something that <i>contains</i> a `result_t`.</div><div><=
br></div><div>Elision works by eliminating a copy/move between the same typ=
es, because it is logically a no-op. But copy/move between different types =
is a conversion operation, and it is not reasonable to expect such a thing =
to be a logical no-op.<br></div><div><br></div><div>Not to mention, there&#=
39;s no way to really make this work. Elision works because the storage for=
 the return value object is provided by the caller. As such, a function whi=
ch performs elision can simply silently assign the storage for a stack vari=
able or temporary to the storage provided by the caller.</div><div><br></di=
v><div>In this case, the caller provided storage for an `expected`, which i=
s undoubtedly larger than the storage for a `result_t`. In order for the co=
mpiler to properly &quot;elide&quot; this, it would have to silently constr=
uct that `expected`, and do so in a way that it gets the parameters that wi=
ll cause it to construct a `result_t` internally. Then it would have to sil=
ently fetch that address using `expected`&#39;s interface and silently use =
that address anywhere that you use the variable.</div><div><br></div><div>T=
hat&#39;s just not practical. Not unless `expected` is a magic type with an=
 interface that the compiler is explicitly written to understand and manipu=
late.<br></div><div><br></div><div>For the `expected` case, just create an =
`expected` object internally and let regular NRVO actually do its job. That=
 is, do the job I mentioned above. Or wait for Herb&#39;s lightweight excep=
tion proposal.<br></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/6a2649ec-c28d-452a-a10d-db821ee0ac0b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6a2649ec-c28d-452a-a10d-db821ee0ac0b=
%40isocpp.org</a>.<br />

------=_Part_16169_170584003.1527610018275--

------=_Part_16168_1091301530.1527610018275--

.

On Tuesday, 29 May 2018 07:35:30 CDT Omer Rosler wrote:
> Indeed, that is why I wrote this issue is more theoretical than practical.
> The point I'm making is that a major decision of how I structure my code
> depends on the assumption of this optimization, so this turns into more
> then a mere optimization, therefore the assumption of NRVO (in some cases)
> should belong in the standard.

It's an optimisation. So long as it's that, a compiler could behave
differently.

If you want to enforce, you need to make it a mandatory language feature.
Describe your request as such, please.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



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

.

------=_Part_39431_5691690.1527613040552
Content-Type: multipart/alternative;
 boundary="----=_Part_39432_441259371.1527613040553"

------=_Part_39432_441259371.1527613040553
Content-Type: text/plain; charset="UTF-8"

On Tuesday, May 29, 2018 at 12:06:58 PM UTC-4, Omer Rosler wrote:
>
> Well, you're right on this example, I have missed the fact that the
> conversion is not covered in these rules.
> This raises a problem, if we can't make this work - how does the committee
> expect the community to use a non-zero-overhead (theoretically, or with a
> bad optimizer) error handling mechanism?
> `expected` is supposed to be a replacement for error codes + out params
> (not a completely drop in replacement, but these mechanisms satisfy the
> same needs) and this means it is not a zero-overhead one. Was this concern
> discussed during LEWG review?
>

You could do the thing I suggested: create an `expected` on the stack that
holds the value in question, then extract the value from it and manipulate
that as needed.

It should also be noted that `expected` is not intended to be a
"zero-overhead" replacement for error codes+output parameters. It's well
understood that there can be particular use cases where return parameters
are more efficient than a value return.

It's intended to be 1) "good enough" for most cases (since the overhead of
copying 16 bytes or so is not a problem for most people's code), and 2) a
much better and more self-documenting interface.

--
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/9e1a5a0f-a735-466b-84a1-2c53401b7c0f%40isocpp.org.

------=_Part_39432_441259371.1527613040553
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, May 29, 2018 at 12:06:58 PM UTC-4, Omer Rosler=
 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>W=
ell, you&#39;re right on this example, I have missed the fact that the conv=
ersion is not covered in these rules.</div><div>This raises a problem, if w=
e can&#39;t make this work - how does the committee expect the community to=
 use a non-zero-overhead (theoretically, or with a bad optimizer) error han=
dling mechanism?</div><div>`expected` is supposed to be a replacement for e=
rror codes + out params (not a completely drop in replacement, but these me=
chanisms satisfy the same needs) and this means it is not a zero-overhead o=
ne. Was this concern discussed during LEWG review?<br></div></div></blockqu=
ote><div><br></div><div>You could do the thing I suggested: create an `expe=
cted` on the stack that holds the value in question, then extract the value=
 from it and manipulate that as needed.<br></div><div><br></div><div>It sho=
uld also be noted that `expected` is not intended to be a &quot;zero-overhe=
ad&quot; replacement for error codes+output parameters. It&#39;s well under=
stood that there can be particular use cases where return parameters are mo=
re efficient than a value return.</div><div><br></div><div></div><div>It&#3=
9;s intended to be 1) &quot;good enough&quot; for most cases (since the ove=
rhead of copying 16 bytes or so is not a problem for most people&#39;s code=
), and 2) a much better and more self-documenting interface.</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/9e1a5a0f-a735-466b-84a1-2c53401b7c0f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9e1a5a0f-a735-466b-84a1-2c53401b7c0f=
%40isocpp.org</a>.<br />

------=_Part_39432_441259371.1527613040553--

------=_Part_39431_5691690.1527613040552--

.

--000000000000bb88f5056d5bd6ce
Content-Type: text/plain; charset="UTF-8"

> The problem:
> I want to change the error handling mechanism we currently have in our
code base from returning error codes and passing out params into a better,
modern one.

We already have a modern, efficient mechanism for describing functions that
are expected to return values but may occasionally fail.

It's called exceptions.

Note that if you wish to avoid the perceived overhead of a virtual
interface, you can define your own non-virtual project-wide exception base
class. There is no hard and fast requirement to use std::exception,
std::runtime_error et al.


On Tue, 29 May 2018 at 18:57, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Tuesday, May 29, 2018 at 12:06:58 PM UTC-4, Omer Rosler wrote:
>>
>> Well, you're right on this example, I have missed the fact that the
>> conversion is not covered in these rules.
>> This raises a problem, if we can't make this work - how does the
>> committee expect the community to use a non-zero-overhead (theoretically,
>> or with a bad optimizer) error handling mechanism?
>> `expected` is supposed to be a replacement for error codes + out params
>> (not a completely drop in replacement, but these mechanisms satisfy the
>> same needs) and this means it is not a zero-overhead one. Was this concern
>> discussed during LEWG review?
>>
>
> You could do the thing I suggested: create an `expected` on the stack that
> holds the value in question, then extract the value from it and manipulate
> that as needed.
>
> It should also be noted that `expected` is not intended to be a
> "zero-overhead" replacement for error codes+output parameters. It's well
> understood that there can be particular use cases where return parameters
> are more efficient than a value return.
>
> It's intended to be 1) "good enough" for most cases (since the overhead of
> copying 16 bytes or so is not a problem for most people's code), and 2) a
> much better and more self-documenting interface.
>
> --
> 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/9e1a5a0f-a735-466b-84a1-2c53401b7c0f%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9e1a5a0f-a735-466b-84a1-2c53401b7c0f%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

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

--000000000000bb88f5056d5bd6ce
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt; The problem:<div style=3D"color:rgb(34,34,34);font-fa=
mily:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:nor=
mal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-ali=
gn:start;text-indent:0px;text-transform:none;white-space:normal;word-spacin=
g:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-=
decoration-color:initial">&gt; I want to change the error handling mechanis=
m we currently have in our code base from returning error codes and passing=
 out params into a better, modern one.</div><div><br></div><div>We already =
have a modern, efficient mechanism for describing functions that are expect=
ed to return values but may occasionally fail.</div><div><br></div>It&#39;s=
 called exceptions.<div><br></div><div>Note that if you wish to avoid the p=
erceived overhead of a virtual interface, you can define your own non-virtu=
al project-wide exception base class. There is no hard and fast requirement=
 to use std::exception, std::runtime_error et al.</div><div><br><br><div cl=
ass=3D"gmail_quote"><div dir=3D"ltr">On Tue, 29 May 2018 at 18:57, Nicol Bo=
las &lt;<a href=3D"mailto:jmckesson@gmail.com">jmckesson@gmail.com</a>&gt; =
wrote:<br></div><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 Tuesday,=
 May 29, 2018 at 12:06:58 PM UTC-4, Omer Rosler 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>Well, you&#39;re right on this exa=
mple, I have missed the fact that the conversion is not covered in these ru=
les.</div><div>This raises a problem, if we can&#39;t make this work - how =
does the committee expect the community to use a non-zero-overhead (theoret=
ically, or with a bad optimizer) error handling mechanism?</div><div>`expec=
ted` is supposed to be a replacement for error codes + out params (not a co=
mpletely drop in replacement, but these mechanisms satisfy the same needs) =
and this means it is not a zero-overhead one. Was this concern discussed du=
ring LEWG review?<br></div></div></blockquote><div><br></div><div>You could=
 do the thing I suggested: create an `expected` on the stack that holds the=
 value in question, then extract the value from it and manipulate that as n=
eeded.<br></div><div><br></div><div>It should also be noted that `expected`=
 is not intended to be a &quot;zero-overhead&quot; replacement for error co=
des+output parameters. It&#39;s well understood that there can be particula=
r use cases where return parameters are more efficient than a value return.=
</div><div><br></div><div></div><div>It&#39;s intended to be 1) &quot;good =
enough&quot; for most cases (since the overhead of copying 16 bytes or so i=
s not a problem for most people&#39;s code), and 2) a much better and more =
self-documenting interface.</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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9e1a5a0f-a735-466b-84a1-2c53401b7c0f%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9e1a5a0f-a735-=
466b-84a1-2c53401b7c0f%40isocpp.org</a>.<br>
</blockquote></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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/CALvx3hb6ijb0-vw%2BwHF2YKzuFGkzw44YY1=
5sTzoFG4jsbSWizg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hb6ijb0-v=
w%2BwHF2YKzuFGkzw44YY15sTzoFG4jsbSWizg%40mail.gmail.com</a>.<br />

--000000000000bb88f5056d5bd6ce--

.

------=_Part_40084_1801775480.1527619590487
Content-Type: multipart/alternative;
 boundary="----=_Part_40085_1233067605.1527619590487"

------=_Part_40085_1233067605.1527619590487
Content-Type: text/plain; charset="UTF-8"



On Tuesday, May 29, 2018 at 1:48:17 PM UTC-4, Richard Hodges wrote:
>
> > The problem:
> > I want to change the error handling mechanism we currently have in our
> code base from returning error codes and passing out params into a better,
> modern one.
>
> We already have a modern, efficient mechanism for describing functions
> that are expected to return values but may occasionally fail.
>
> It's called exceptions.
>

Modern? Maybe. Efficient? Herb Sutter (and basically all of SG14 plus
others) beg to differ. If it were efficient,we wouldn't be trying to
improve it's efficiency <http://wg21.link/P0709>.

I don't begrudge anyone who's trying to avoid the costs of the current
exception mechanism.

--
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/1bc5175a-ab92-425d-b159-083654ac7748%40isocpp.org.

------=_Part_40085_1233067605.1527619590487
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, May 29, 2018 at 1:48:17 PM UTC-4, Rich=
ard Hodges 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">&gt; The problem:<div style=3D"color:rgb(34,34,34);font-family:sans-ser=
if;font-size:13px;font-style:normal;font-weight:400;letter-spacing:normal;t=
ext-align:start;text-indent:0px;text-transform:none;white-space:normal;word=
-spacing:0px;background-color:rgb(255,255,255)">&gt; I want to change the e=
rror handling mechanism we currently have in our code base from returning e=
rror codes and passing out params into a better, modern one.</div><div><br>=
</div><div>We already have a modern, efficient mechanism for describing fun=
ctions that are expected to return values but may occasionally fail.</div><=
div><br></div>It&#39;s called exceptions.</div></blockquote><div><br></div>=
<div>Modern? Maybe. Efficient? Herb Sutter (and basically all of SG14 plus =
others) beg to differ. If it were efficient,<a href=3D"http://wg21.link/P07=
09">we wouldn&#39;t be trying to improve it&#39;s efficiency</a>.</div><div=
><br></div><div>I don&#39;t begrudge anyone who&#39;s trying to avoid the c=
osts of the current exception mechanism.<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/1bc5175a-ab92-425d-b159-083654ac7748%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1bc5175a-ab92-425d-b159-083654ac7748=
%40isocpp.org</a>.<br />

------=_Part_40085_1233067605.1527619590487--

------=_Part_40084_1801775480.1527619590487--

.

------=_Part_578_1971768744.1527619897099
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I don't think you understand the point I made:
An optimization is not something you can assume and structure your entire c=
ode around.
When that doesn't happen, and your code is based upon this assumption, this=
 is either bad design, or a solid assumption that is already a defacto stan=
dard (RVO being a prime example here - people returned large structs by val=
ue under this assumption long before C++17).
If the use case is strong enough, and it is the latter option than it shoul=
d belong in the standard.

Before I write a proposal I want to understand if there are more use cases =
for some guarantees of NRVO, that is why I posted this thread.

--=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/63e1fa8a-fb85-47e6-b425-0dfd640ac520%40isocpp.or=
g.

------=_Part_578_1971768744.1527619897099--

.

------=_Part_39917_464051515.1527620295414
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tuesday, May 29, 2018 at 7:48:29 PM UTC+3, Thiago Macieira wrote:
> On Tuesday, 29 May 2018 07:35:30 CDT Omer Rosler wrote:
> > Indeed, that is why I wrote this issue is more theoretical than practic=
al.
> > The point I'm making is that a major decision of how I structure my cod=
e
> > depends on the assumption of this optimization, so this turns into more
> > then a mere optimization, therefore the assumption of NRVO (in some cas=
es)
> > should belong in the standard.
>=20
> It's an optimisation. So long as it's that, a compiler could behave=20
> differently.
>=20
> If you want to enforce, you need to make it a mandatory language feature.=
=20
> Describe your request as such, please.
>=20
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center

I don't think you understand the point I made:
An optimization is not something you can assume and structure your entire c=
ode around.
When that doesn't happen, and your code is based upon this assumption, this=
 is either bad design, or a solid assumption that is already a defacto stan=
dard (RVO being a prime example here - people returned large structs by val=
ue under this assumption long before C++17).
If the use case is strong enough, and it is the latter option than it shoul=
d belong in the standard.
Before I write a proposal I want to understand if there are more use cases =
for some guarantees of NRVO, that is why I posted this thread.

--=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/8aeb2e38-57fd-458e-b931-38313bf342c2%40isocpp.or=
g.

------=_Part_39917_464051515.1527620295414--

.

------=_Part_39543_1672188931.1527620532297
Content-Type: text/plain; charset="UTF-8"

On Tuesday, May 29, 2018 at 8:48:17 PM UTC+3, Richard Hodges wrote:
> > The problem:
> > I want to change the error handling mechanism we currently have in our code base from returning error codes and passing out params into a better, modern one.
>
>
> We already have a modern, efficient mechanism for describing functions that are expected to return values but may occasionally fail.
>
> It's called exceptions.
>
>
> Note that if you wish to avoid the perceived overhead of a virtual interface, you can define your own non-virtual project-wide exception base class. There is no hard and fast requirement to use std::exception, std::runtime_error et al.
>
>
>
>
> On Tue, 29 May 2018 at 18:57, Nicol Bolas <jmck...@gmail.com> wrote:
>
> On Tuesday, May 29, 2018 at 12:06:58 PM UTC-4, Omer Rosler wrote:
>
> Well, you're right on this example, I have missed the fact that the conversion is not covered in these rules.
> This raises a problem, if we can't make this work - how does the committee expect the community to use a non-zero-overhead (theoretically, or with a bad optimizer) error handling mechanism?
> `expected` is supposed to be a replacement for error codes + out params (not a completely drop in replacement, but these mechanisms satisfy the same needs) and this means it is not a zero-overhead one. Was this concern discussed during LEWG review?
>
>
>
> You could do the thing I suggested: create an `expected` on the stack that holds the value in question, then extract the value from it and manipulate that as needed.
>
>
>
> It should also be noted that `expected` is not intended to be a "zero-overhead" replacement for error codes+output parameters. It's well understood that there can be particular use cases where return parameters are more efficient than a value return.
>
>
>
> It's intended to be 1) "good enough" for most cases (since the overhead of copying 16 bytes or so is not a problem for most people's code), and 2) a much better and more self-documenting interface.
>
>
>
>
>
> --
>
> You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
>
> To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
>
> To post to this group, send email to std-pr...@isocpp.org.
>
> To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9e1a5a0f-a735-466b-84a1-2c53401b7c0f%40isocpp.org.

Richard, I don't want this to derail into another exception vs error codes discussion as it is off topic.

--
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/329d927d-81f2-49da-a9fd-9749638bd789%40isocpp.org.

------=_Part_39543_1672188931.1527620532297--

.

------=_Part_40108_1955756707.1527621245274
Content-Type: text/plain; charset="UTF-8"

On Tuesday, May 29, 2018 at 7:57:20 PM UTC+3, Nicol Bolas wrote:
> On Tuesday, May 29, 2018 at 12:06:58 PM UTC-4, Omer Rosler wrote:
>
> Well, you're right on this example, I have missed the fact that the conversion is not covered in these rules.
> This raises a problem, if we can't make this work - how does the committee expect the community to use a non-zero-overhead (theoretically, or with a bad optimizer) error handling mechanism?
> `expected` is supposed to be a replacement for error codes + out params (not a completely drop in replacement, but these mechanisms satisfy the same needs) and this means it is not a zero-overhead one. Was this concern discussed during LEWG review?
>
>
>
> You could do the thing I suggested: create an `expected` on the stack that holds the value in question, then extract the value from it and manipulate that as needed.
>
>
>
> It should also be noted that `expected` is not intended to be a "zero-overhead" replacement for error codes+output parameters. It's well understood that there can be particular use cases where return parameters are more efficient than a value return.
>
>
>
> It's intended to be 1) "good enough" for most cases (since the overhead of copying 16 bytes or so is not a problem for most people's code), and 2) a much better and more self-documenting interface.

Indeed, I could do as you suggest and it would be better on the guarantee side.
As for your "zero overhead" point:
The use case I see for expected is:
1. Put it in a return type of a function
2. Implement the function by returning T or E with the conversion implicit (or explicit - i.e you never create the expected object inside the function)
3. When calling the function, immediately (well at least until it goes out of scope) decompose the expected object.

If this is the use case, with giving some guarantees on the language side this can definetly be zero overhead (practically it is, just measure any expected implementation out there with any compiler)

I hope this was discussed before, because to me it seems within reach to have such a gurantee.

--
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/04320571-ea49-4a4d-b0a2-7275f036f4c5%40isocpp.org.

------=_Part_40108_1955756707.1527621245274--

.

------=_Part_9380_1517878407.1527622399528
Content-Type: multipart/alternative;
 boundary="----=_Part_9381_251603028.1527622399528"

------=_Part_9381_251603028.1527622399528
Content-Type: text/plain; charset="UTF-8"

On Tuesday, May 29, 2018 at 3:14:05 PM UTC-4, Omer Rosler wrote:
>
> On Tuesday, May 29, 2018 at 7:57:20 PM UTC+3, Nicol Bolas wrote:
> > On Tuesday, May 29, 2018 at 12:06:58 PM UTC-4, Omer Rosler wrote:
> >
> > Well, you're right on this example, I have missed the fact that the
> conversion is not covered in these rules.
> > This raises a problem, if we can't make this work - how does the
> committee expect the community to use a non-zero-overhead (theoretically,
> or with a bad optimizer) error handling mechanism?
> > `expected` is supposed to be a replacement for error codes + out params
> (not a completely drop in replacement, but these mechanisms satisfy the
> same needs) and this means it is not a zero-overhead one. Was this concern
> discussed during LEWG review?
> >
> >
> >
> > You could do the thing I suggested: create an `expected` on the stack
> that holds the value in question, then extract the value from it and
> manipulate that as needed.
> >
> >
> >
> > It should also be noted that `expected` is not intended to be a
> "zero-overhead" replacement for error codes+output parameters. It's well
> understood that there can be particular use cases where return parameters
> are more efficient than a value return.
> >
> >
> >
> > It's intended to be 1) "good enough" for most cases (since the overhead
> of copying 16 bytes or so is not a problem for most people's code), and 2)
> a much better and more self-documenting interface.
>
> Indeed, I could do as you suggest and it would be better on the guarantee
> side.
>

It wouldn't be "better"; it would be *possible*.


> As for your "zero overhead" point:
> The use case I see for expected is:
>

`expected` can be used however you can find a use for it. It's not designed
for *just* that.

1. Put it in a return type of a function
> 2. Implement the function by returning T or E with the conversion implicit
> (or explicit - i.e you never create the expected object inside the function)
> 3. When calling the function, immediately (well at least until it goes out
> of scope) decompose the expected object.
>
> If this is the use case, with giving some guarantees on the language side
> this can definetly be zero overhead
>

No, it can't. If `T` is not trivially copyable, the compiler *must* visibly
call that copy constructor when that conversion, *period*. There are no
back doors, no wiggle room, the standard says it very clearly that it *will
be called*.

The compiler can play more fast-and-loose with trivially copyable types,
but even there, there can be no guarantees that the compiler won't do a
memcpy. Especially since implementations of `expected` tend to be pretty
obtuse.

As previously stated, return value elision works by constructing the object
in place, within the return value storage itself. `expected<T, E>`
*contains* a `T` or an `E`, but it is not either object. Therefore, the
compiler cannot decide to take a stack variable of type `T` and stick it in
the return value object's storage. Nor can the compiler manifest the
existence of an `expected<T, E>` *around* such a `T`.

Again, not unless `expected` were a magic, compiler-created type that is
allowed to break the rules of C++.


> (practically it is, just measure any expected implementation out there
> with any compiler)
>
> I hope this was discussed before, because to me it seems within reach to
> have such a gurantee.
>
>

--
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/d1632de8-b7fe-4164-a57c-68510367c73b%40isocpp.org.

------=_Part_9381_251603028.1527622399528
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, May 29, 2018 at 3:14:05 PM UTC-4, Omer Rosler =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Tuesday, May 29, 2018=
 at 7:57:20 PM UTC+3, Nicol Bolas wrote:<br>&gt; On Tuesday, May 29, 2018 a=
t 12:06:58 PM UTC-4, Omer Rosler wrote:<br>&gt; <br>&gt; Well, you&#39;re r=
ight on this example, I have missed the fact that the conversion is not cov=
ered in these rules.<br>&gt; This raises a problem, if we can&#39;t make th=
is work - how does the committee expect the community to use a non-zero-ove=
rhead (theoretically, or with a bad optimizer) error handling mechanism?<br=
>&gt; `expected` is supposed to be a replacement for error codes + out para=
ms (not a completely drop in replacement, but these mechanisms satisfy the =
same needs) and this means it is not a zero-overhead one. Was this concern =
discussed during LEWG review?<br>&gt; <br>&gt; <br>&gt; <br>&gt; You could =
do the thing I suggested: create an `expected` on the stack that holds the =
value in question, then extract the value from it and manipulate that as ne=
eded.<br>&gt; <br>&gt; <br>&gt; <br>&gt; It should also be noted that `expe=
cted` is not intended to be a &quot;zero-overhead&quot; replacement for err=
or codes+output parameters. It&#39;s well understood that there can be part=
icular use cases where return parameters are more efficient than a value re=
turn.<br>&gt; <br>&gt; <br>&gt; <br>&gt; It&#39;s intended to be 1) &quot;g=
ood enough&quot; for most cases (since the overhead of copying 16 bytes or =
so is not a problem for most people&#39;s code), and 2) a much better and m=
ore self-documenting interface.<p>Indeed, I could do as you suggest and it =
would be better on the guarantee side.<br></p></blockquote><div><br></div><=
div>It wouldn&#39;t be &quot;better&quot;; it would be <i>possible</i>.<br>=
</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p>As f=
or your &quot;zero overhead&quot; point:<br>The use case I see for expected=
 is: <br></p></blockquote><div><br></div><div>`expected` can be used howeve=
r you can find a use for it. It&#39;s not designed for <i>just</i> that.<br=
></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p>1. Pu=
t it in a return type of a function<br>2. Implement the function by returni=
ng T or E with the conversion implicit (or explicit - i.e you never create =
the expected object inside the function)<br>3. When calling the function, i=
mmediately (well at least until it goes out of scope) decompose the expecte=
d object.</p><p>If this is the use case, with giving some guarantees on the=
 language side this can definetly be zero overhead</p></blockquote><div><br=
></div><div>No, it can&#39;t. If `T` is not trivially copyable, the compile=
r <i>must</i> visibly call that copy constructor when that conversion, <i>p=
eriod</i>. There are no back doors, no wiggle room, the standard says it ve=
ry clearly that it <i>will be called</i>.</div><div><br></div><div>The comp=
iler can play more fast-and-loose with trivially copyable types, but even t=
here, there can be no guarantees that the compiler won&#39;t do a memcpy. E=
specially since implementations of `expected` tend to be pretty obtuse.</di=
v><div><br></div><div>As previously stated, return value elision works by c=
onstructing the object in place, within the return value storage itself. `e=
xpected&lt;T, E&gt;` <i>contains</i> a `T` or an `E`, but it is not either =
object. Therefore, the compiler cannot decide to take a stack variable of t=
ype `T` and stick it in the return value object&#39;s storage. Nor can the =
compiler manifest the existence of an `expected&lt;T, E&gt;` <i>around</i> =
such a `T`.</div><div><br></div><div>Again, not unless `expected` were a ma=
gic, compiler-created type that is allowed to break the rules of C++.<br></=
div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p>(pract=
ically it is, just measure any expected implementation out there with any c=
ompiler)</p><p>I hope this was discussed before, because to me it seems wit=
hin reach to have such a gurantee.</p><p></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/d1632de8-b7fe-4164-a57c-68510367c73b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d1632de8-b7fe-4164-a57c-68510367c73b=
%40isocpp.org</a>.<br />

------=_Part_9381_251603028.1527622399528--

------=_Part_9380_1517878407.1527622399528--

.

On Tuesday, 29 May 2018 11:58:15 PDT Omer Rosler wrote:
> I don't think you understand the point I made:
> An optimization is not something you can assume and structure your entire
> code around.

I think I did. My point is that you should describe your request without
saying "optimisation".

We made the copy constructor elision mandatory, where it used to be an
optimisation. Because of that, it's no longer an optimisation.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



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

.