------=_Part_2121_1757406450.1434790111877
Content-Type: multipart/alternative;
 boundary="----=_Part_2122_240124312.1434790111877"

------=_Part_2122_240124312.1434790111877
Content-Type: text/plain; charset=UTF-8

I have a question regarding the scope_exit part of the proposal in N4189,
or more specifically the make_scope_exit function template implementation.
The proposal shows that factory function as having the following
implementation (I don't know if it is meant to be official or just for
illustration purposes):

template <typename EF>
auto make_scope_exit(EF &&exit_function) noexcept {
    return
scope_exit<std::remove_reference_t<EF>>(std::forward<EF>(exit_function));
}

While this works, I am wondering if using std::decay would be a better
choice than std::remove_reference? While both would yield a suitable type
to pass as a template parameter to the scope_exit template class,
std::decay would allow code like this:

void freeFunc()
{
    std::cout << "freeFunc called" << std::endl;
}

void main(int argc, char** argv)
{
    auto onExit = std::make_scope_exit(freeFunc);
    // ...
}

Using std::remove_reference, you would have to be more explicit and take
the address of freeFunc like so:

    auto onExit = std::make_scope_exit(&freeFunc);

This makes free functions a bit less consistent compared to if we were
passing a lambda or function object where we would not have to take an
address and could pass the lambda or function object directly. In the folly
library where Andrei Alexandrescu's work with ScopeGuard seems to have
ended up finding its home, the implementation there also uses std::decay,
so I'm wondering if there is any reason to prefer remove_reference to decay
in this proposal?

FWIW, I came across this proposal at the tail end of writing a couple of
blog articles on this whole area. I started from a motivating example and
worked through from an initial implementation based on std::function
and ended up with a final implementation very similar to scope_exit. While
those blog articles were more aimed at an audience who are perhaps not as
well-versed in C++'s newer details as those frequenting this Google group,
they may be of interest for showing a motivating use case and for a
discussion of some of the various alternatives and features of the
implementation. I provide a link below for those interested, but my main
purposes here is to clarify the use of remove_if over decay.

http://crascit.com/2015/06/03/on-leaving-scope-part-2/

--
Craig Scott




--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">I have a question regarding the scope_exit part of the pro=
posal in N4189, or more specifically the make_scope_exit function template =
implementation. The proposal shows that factory function as having the foll=
owing implementation (I don't know if it is meant to be official or just fo=
r illustration purposes):<div><br></div><font face=3D"courier new, monospac=
e">template &lt;typename EF&gt;<br> auto make_scope_exit(EF &amp;&amp;exit_=
function) noexcept {<br>&nbsp; &nbsp; return scope_exit&lt;std::remove_refe=
rence_t&lt;EF&gt;&gt;(std::forward&lt;EF&gt;(exit_function));<br>}</font><d=
iv><br></div><div>While this works, I am wondering if using std::decay woul=
d be a better choice than std::remove_reference? While both would yield a s=
uitable type to pass as a template parameter to the scope_exit template cla=
ss, std::decay would allow code like this:</div><div><br></div><div><font f=
ace=3D"courier new, monospace">void freeFunc()</font></div><div><font face=
=3D"courier new, monospace">{</font></div><div><font face=3D"courier new, m=
onospace">&nbsp; &nbsp; std::cout &lt;&lt; "freeFunc called" &lt;&lt; std::=
endl;</font></div><div><font face=3D"courier new, monospace">}</font></div>=
<div><font face=3D"courier new, monospace"><br></font></div><div><font face=
=3D"courier new, monospace">void main(int argc, char** argv)</font></div><d=
iv><font face=3D"courier new, monospace">{</font></div><div><span style=3D"=
font-family: 'courier new', monospace;">&nbsp; &nbsp; auto onExit =3D std::=
make_scope_exit(freeFunc);</span><br></div><div><font face=3D"courier new, =
monospace">&nbsp; &nbsp; // ...</font></div><div><font face=3D"courier new,=
 monospace">}</font></div><div><br></div><div>Using std::remove_reference, =
you would have to be more explicit and take the address of freeFunc like so=
:</div><div><br></div><div><div><span style=3D"font-family: 'courier new', =
monospace;">&nbsp; &nbsp; auto onExit =3D std::make_scope_exit(&amp;freeFun=
c);</span><br></div></div><div><font face=3D"arial, sans-serif"><br></font>=
</div><div><font face=3D"arial, sans-serif">This makes free functions a bit=
 less consistent compared to if we were passing a lambda or function object=
 where we would not have to take an address and could pass the lambda or fu=
nction object directly. In the folly library where Andrei Alexandrescu's wo=
rk with ScopeGuard seems to have ended up finding its home, the implementat=
ion there also uses std::decay, so I'm wondering if there is any reason to =
prefer remove_reference to decay in this proposal?</font></div><div><font f=
ace=3D"arial, sans-serif"><br></font></div><div><font face=3D"arial, sans-s=
erif">FWIW, I came across this proposal at the tail end of writing a couple=
 of blog articles on this whole area. I started from a motivating example a=
nd worked through from an initial implementation based on std::function and=
&nbsp;ended up with a final implementation very similar to scope_exit. Whil=
e those blog articles were more aimed at an audience who are perhaps not as=
 well-versed in C++'s newer details as those frequenting this Google group,=
 they may be of interest for showing a motivating use case and for a discus=
sion of some of the various alternatives and features of the implementation=
.. I provide a link below for those interested, but my main purposes here is=
 to clarify the use of remove_if over decay.</font></div><div><font face=3D=
"arial, sans-serif"><br></font></div><div><a href=3D"http://crascit.com/201=
5/06/03/on-leaving-scope-part-2/">http://crascit.com/2015/06/03/on-leaving-=
scope-part-2/</a><font face=3D"arial, sans-serif"><br></font></div><div><fo=
nt face=3D"arial, sans-serif"><br></font></div><div><font face=3D"arial, sa=
ns-serif">--</font></div><div><font face=3D"arial, sans-serif">Craig Scott<=
/font></div><div><font face=3D"arial, sans-serif"><br></font></div><div><fo=
nt face=3D"arial, sans-serif"><br></font></div><div><br></div><div><br></di=
v></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2122_240124312.1434790111877--
------=_Part_2121_1757406450.1434790111877--

.

------=_Part_2145_1647826248.1434790252503
Content-Type: multipart/alternative;
 boundary="----=_Part_2146_1066638424.1434790252503"

------=_Part_2146_1066638424.1434790252503
Content-Type: text/plain; charset=UTF-8



On Saturday, June 20, 2015 at 6:48:32 PM UTC+10, Craig Scott wrote:
>
> ... but my main purposes here is to clarify the use of remove_if over
> decay.
>
>
Of course, I meant remove_reference/remove_reference_t, not remove_if. ;)

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><br><br>On Saturday, June 20, 2015 at 6:48:32 PM UTC+10, C=
raig Scott wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div>...<font face=3D"arial, sans-serif">&nbsp;but my main purposes her=
e is to clarify the use of remove_if over decay.</font></div><div><br></div=
></div></blockquote><div><br></div><div>Of course, I meant remove_reference=
/remove_reference_t, not remove_if. ;)&nbsp;</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2146_1066638424.1434790252503--
------=_Part_2145_1647826248.1434790252503--

.

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

Craig,

At this point I believe that N4189 is in the hands of the LWG.  FWIW, I
agree that std::decay would be better than std::remove_reference in this
case.  Thank you.

-Andrew Sandoval


On Sat, Jun 20, 2015 at 3:48 AM, Craig Scott <audiofanatic@gmail.com> wrote:

> I have a question regarding the scope_exit part of the proposal in N4189,
> or more specifically the make_scope_exit function template implementation.
> The proposal shows that factory function as having the following
> implementation (I don't know if it is meant to be official or just for
> illustration purposes):
>
> template <typename EF>
> auto make_scope_exit(EF &&exit_function) noexcept {
>     return
> scope_exit<std::remove_reference_t<EF>>(std::forward<EF>(exit_function));
> }
>
> While this works, I am wondering if using std::decay would be a better
> choice than std::remove_reference? While both would yield a suitable type
> to pass as a template parameter to the scope_exit template class,
> std::decay would allow code like this:
>
> void freeFunc()
> {
>     std::cout << "freeFunc called" << std::endl;
> }
>
> void main(int argc, char** argv)
> {
>     auto onExit = std::make_scope_exit(freeFunc);
>     // ...
> }
>
> Using std::remove_reference, you would have to be more explicit and take
> the address of freeFunc like so:
>
>     auto onExit = std::make_scope_exit(&freeFunc);
>
> This makes free functions a bit less consistent compared to if we were
> passing a lambda or function object where we would not have to take an
> address and could pass the lambda or function object directly. In the folly
> library where Andrei Alexandrescu's work with ScopeGuard seems to have
> ended up finding its home, the implementation there also uses std::decay,
> so I'm wondering if there is any reason to prefer remove_reference to decay
> in this proposal?
>
> FWIW, I came across this proposal at the tail end of writing a couple of
> blog articles on this whole area. I started from a motivating example and
> worked through from an initial implementation based on std::function
> and ended up with a final implementation very similar to scope_exit. While
> those blog articles were more aimed at an audience who are perhaps not as
> well-versed in C++'s newer details as those frequenting this Google group,
> they may be of interest for showing a motivating use case and for a
> discussion of some of the various alternatives and features of the
> implementation. I provide a link below for those interested, but my main
> purposes here is to clarify the use of remove_if over decay.
>
> http://crascit.com/2015/06/03/on-leaving-scope-part-2/
>
> --
> Craig Scott
>
>
>
>
>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>



--
*Andrew L. Sandoval*
sandoval@netwaysglobal.com

[image: qrcode] <http://mormon.org/me/72HW/>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div><div>Craig,<br><br></div>At this point I believe that=
 N4189 is in the hands of the LWG.=C2=A0 FWIW, I agree that std::decay woul=
d be better than std::remove_reference in this case.=C2=A0 Thank you.<br><b=
r></div>-Andrew Sandoval<br><br></div><div class=3D"gmail_extra"><br><div c=
lass=3D"gmail_quote">On Sat, Jun 20, 2015 at 3:48 AM, Craig Scott <span dir=
=3D"ltr">&lt;<a href=3D"mailto:audiofanatic@gmail.com" target=3D"_blank">au=
diofanatic@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr">I have a question regarding the scope_exit part of the p=
roposal in N4189, or more specifically the make_scope_exit function templat=
e implementation. The proposal shows that factory function as having the fo=
llowing implementation (I don&#39;t know if it is meant to be official or j=
ust for illustration purposes):<div><br></div><font face=3D"courier new, mo=
nospace">template &lt;typename EF&gt;<br> auto make_scope_exit(EF &amp;&amp=
;exit_function) noexcept {<br>=C2=A0 =C2=A0 return scope_exit&lt;std::remov=
e_reference_t&lt;EF&gt;&gt;(std::forward&lt;EF&gt;(exit_function));<br>}</f=
ont><div><br></div><div>While this works, I am wondering if using std::deca=
y would be a better choice than std::remove_reference? While both would yie=
ld a suitable type to pass as a template parameter to the scope_exit templa=
te class, std::decay would allow code like this:</div><div><br></div><div><=
font face=3D"courier new, monospace">void freeFunc()</font></div><div><font=
 face=3D"courier new, monospace">{</font></div><div><font face=3D"courier n=
ew, monospace">=C2=A0 =C2=A0 std::cout &lt;&lt; &quot;freeFunc called&quot;=
 &lt;&lt; std::endl;</font></div><div><font face=3D"courier new, monospace"=
>}</font></div><div><font face=3D"courier new, monospace"><br></font></div>=
<div><font face=3D"courier new, monospace">void main(int argc, char** argv)=
</font></div><div><font face=3D"courier new, monospace">{</font></div><div>=
<span style=3D"font-family:&#39;courier new&#39;,monospace">=C2=A0 =C2=A0 a=
uto onExit =3D std::make_scope_exit(freeFunc);</span><br></div><div><font f=
ace=3D"courier new, monospace">=C2=A0 =C2=A0 // ...</font></div><div><font =
face=3D"courier new, monospace">}</font></div><div><br></div><div>Using std=
::remove_reference, you would have to be more explicit and take the address=
 of freeFunc like so:</div><div><br></div><div><div><span style=3D"font-fam=
ily:&#39;courier new&#39;,monospace">=C2=A0 =C2=A0 auto onExit =3D std::mak=
e_scope_exit(&amp;freeFunc);</span><br></div></div><div><font face=3D"arial=
, sans-serif"><br></font></div><div><font face=3D"arial, sans-serif">This m=
akes free functions a bit less consistent compared to if we were passing a =
lambda or function object where we would not have to take an address and co=
uld pass the lambda or function object directly. In the folly library where=
 Andrei Alexandrescu&#39;s work with ScopeGuard seems to have ended up find=
ing its home, the implementation there also uses std::decay, so I&#39;m won=
dering if there is any reason to prefer remove_reference to decay in this p=
roposal?</font></div><div><font face=3D"arial, sans-serif"><br></font></div=
><div><font face=3D"arial, sans-serif">FWIW, I came across this proposal at=
 the tail end of writing a couple of blog articles on this whole area. I st=
arted from a motivating example and worked through from an initial implemen=
tation based on std::function and=C2=A0ended up with a final implementation=
 very similar to scope_exit. While those blog articles were more aimed at a=
n audience who are perhaps not as well-versed in C++&#39;s newer details as=
 those frequenting this Google group, they may be of interest for showing a=
 motivating use case and for a discussion of some of the various alternativ=
es and features of the implementation. I provide a link below for those int=
erested, but my main purposes here is to clarify the use of remove_if over =
decay.</font></div><div><font face=3D"arial, sans-serif"><br></font></div><=
div><a href=3D"http://crascit.com/2015/06/03/on-leaving-scope-part-2/" targ=
et=3D"_blank">http://crascit.com/2015/06/03/on-leaving-scope-part-2/</a><fo=
nt face=3D"arial, sans-serif"><br></font></div><div><font face=3D"arial, sa=
ns-serif"><br></font></div><div><font face=3D"arial, sans-serif">--</font><=
/div><div><font face=3D"arial, sans-serif">Craig Scott</font></div><span cl=
ass=3D"HOEnZb"><font color=3D"#888888"><div><font face=3D"arial, sans-serif=
"><br></font></div><div><font face=3D"arial, sans-serif"><br></font></div><=
div><br></div><div><br></div></font></span></div><span class=3D"HOEnZb"><fo=
nt color=3D"#888888">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br><br clear=3D"all"><br>-- <br><div clas=
s=3D"gmail_signature"><font size=3D"4"><b style=3D"color:rgb(153,0,0);font-=
family:comic sans ms,sans-serif">Andrew L. Sandoval</b></font><br><span sty=
le=3D"font-family:courier new,monospace"><a href=3D"mailto:sandoval@netways=
global.com" target=3D"_blank">sandoval@netwaysglobal.com</a></span><br><br>=
<a href=3D"http://mormon.org/me/72HW/" target=3D"_blank"><img src=3D"http:/=
/qrcode.kaywa.com/img.php?s=3D5&amp;d=3Dhttp%3A%2F%2Fmormon.org%2Fme%2F72HW=
%2F" alt=3D"qrcode" height=3D"62" width=3D"62"></a><br></div>
</div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1146ff14a8630205190ca052--

.