Topic: First draft: Non-copyable call wrapper, std::unique_function
Author: David Krauss <potswa@gmail.com>
Date: Wed, 20 May 2015 00:06:56 +0800
Raw View
--Apple-Mail=_E1A6F440-2B6C-476F-8975-5972BDFBA697
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Here=E2=80=99s a first draft of a non-copyable polymorphic call wrapper pro=
posal: http://bit.ly/uniqfun <http://bit.ly/uniqfun>
> This proposal describes a variation of std::function supporting non-copya=
ble target objects. It removes the copy constructor, and adds in-place cons=
truction of target objects.
>=20
All comments welcome. Doesn=E2=80=99t look too scary, I just might prototyp=
e it.
Inspired by the recent discussion, "smart function pointer proposal."
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_E1A6F440-2B6C-476F-8975-5972BDFBA697
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D"">Here=E2=80=99s a f=
irst draft of a non-copyable polymorphic call wrapper proposal: <a hre=
f=3D"http://bit.ly/uniqfun" class=3D"">http://bit.ly/uniqfun</a><div class=
=3D""><br class=3D""></div><div class=3D""><blockquote type=3D"cite" class=
=3D""><p style=3D"margin: 0px 0px 16px; -webkit-text-stroke-color: rgb(0, 0=
, 0); -webkit-text-stroke-width: initial;" class=3D"">This proposal describ=
es a variation of <span style=3D"font-family: Courier; background-color: rg=
b(245, 245, 245);" class=3D"">std::function</span> supporting non-copyable =
target objects. It removes the copy constructor, and adds in-place construc=
tion of target objects.</p></blockquote></div><div class=3D"">All comments =
welcome. Doesn=E2=80=99t look too scary, I just might prototype it.</div><d=
iv class=3D""><br class=3D""></div><div class=3D"">Inspired by the recent d=
iscussion, "<font face=3D"Helvetica Neue" class=3D"">smart function pointer=
proposal."</font></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_E1A6F440-2B6C-476F-8975-5972BDFBA697--
.
Author: Casey Carter <cartec69@gmail.com>
Date: Tue, 19 May 2015 10:26:34 -0700 (PDT)
Raw View
------=_Part_271_784866342.1432056394424
Content-Type: multipart/alternative;
boundary="----=_Part_272_1404050120.1432056394424"
------=_Part_272_1404050120.1432056394424
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tuesday, May 19, 2015 at 11:07:03 AM UTC-5, David Krauss wrote:
>
> Here=E2=80=99s a first draft of a non-copyable polymorphic call wrapper p=
roposal:=20
> http://bit.ly/uniqfun
>
unique_function would probably be more useful if it had operator(). Joking=
=20
aside, there should probably be three overloads qualified by &, const&, and=
=20
&& respectively. That way you both avoid std::function's threadsafety=20
problems=20
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4348.html) and=20
enable unique_function to usefully hold "one-shot" functions.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_272_1404050120.1432056394424
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>On Tuesday, May 19, 2015 at 11:07:03 AM UTC-5, David K=
rauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word=
-wrap:break-word">Here=E2=80=99s a first draft of a non-copyable polymorphi=
c call wrapper proposal: <a href=3D"http://bit.ly/uniqfun" target=3D"_=
blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.com/u=
rl?q\75http%3A%2F%2Fbit.ly%2Funiqfun\46sa\75D\46sntz\0751\46usg\75AFQjCNHpv=
1IQvwAGd50WXzFZsNAyV4dpRA';return true;" onclick=3D"this.href=3D'http://www=
..google.com/url?q\75http%3A%2F%2Fbit.ly%2Funiqfun\46sa\75D\46sntz\0751\46us=
g\75AFQjCNHpv1IQvwAGd50WXzFZsNAyV4dpRA';return true;">http://bit.ly/<wbr>un=
iqfun</a></div></blockquote><div><br></div><div>unique_function would proba=
bly be more useful if it had operator(). Joking aside, there should probabl=
y be three overloads qualified by &, const&, and && respect=
ively. That way you both avoid std::function's threadsafety problems (http:=
//www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4348.html) and enable u=
nique_function to usefully hold "one-shot" functions.</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_272_1404050120.1432056394424--
------=_Part_271_784866342.1432056394424--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 19 May 2015 10:42:33 -0700 (PDT)
Raw View
------=_Part_422_2104664548.1432057353927
Content-Type: multipart/alternative;
boundary="----=_Part_423_1893908499.1432057353927"
------=_Part_423_1893908499.1432057353927
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tuesday, May 19, 2015 at 12:07:03 PM UTC-4, David Krauss wrote:
>
> Here=E2=80=99s a first draft of a non-copyable polymorphic call wrapper p=
roposal:=20
> http://bit.ly/uniqfun
>
It'd probably be a good idea to let someone know if a link goes to Dropbox=
=20
to download a PDF, or if it's just a HTML page on the web. You know,=20
without having to click the link.
This proposal describes a variation of std::function supporting=20
> non-copyable target objects. It removes the copy constructor, and adds=20
> in-place construction of target objects.
>
> All comments welcome. Doesn=E2=80=99t look too scary, I just might protot=
ype it.
>
Well, that would help. At least it would let us know the kind of work that=
=20
would be involved in doing a move-transfer from `function` to=20
`unique_function`. The concern there being the changes to `function`'s=20
implementation that would need to be made.
On the proposal, I think the idea of a `unique_any` could be valuable. I'm=
=20
not sure if a non-moveable `unique_any` could be useful by someone, but=20
it's possible.
But I don't like the idea of considering `any`s to be at all equivalent to=
=20
or transformable between `function`s. While their implementations are very=
=20
similar, the objects are conceptually quite distinct. Just like `vector`=20
and `string`. As such, I don't think we should explicitly support=20
transforming one into the other.
I see you have `allocate_assign` and `emplace_assign`. It seems to me that=
=20
you should follow the existing std::function convention. `allocate_assign`=
=20
is conceptually equivalent to `function::assign`, so you should probably=20
just call it that. Also, I see no reason why it shouldn't also be able to=
=20
work like `function::assign`. Similarly, `emplace_assign` should simply be=
=20
called `emplace`. These sound more like the standard=20
I'm going to assume that you intended to add an `operator()` overload in=20
there somewhere. ;) However, unlike Casey Carter, I would not suggest=20
attempting to fix the thread safety problem until the committee has decided=
=20
how they're going to fix it in `std::function`. We don't want two=20
completely different fixes involved.
That's not to say that something shouldn't be done. It's more to say that=
=20
this proposal should hold off on committing to any one solution until more=
=20
is known.
Lastly, bikeshedding. I'm not sure that `unique` is the right word. Oh, it=
=20
conjures up thoughts of `unique_ptr`, which makes you think "move only".=20
But `unique_ptr` is about ownership of memory, while `unique_function` is=
=20
just about being a move-only function wrapper. At the same time, I cannot=
=20
come up with a more explicit name that doesn't sound silly (like=20
`move_only_function`).
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_423_1893908499.1432057353927
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, May 19, 2015 at 12:07:03 PM UTC-4, David Kraus=
s wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wra=
p:break-word">Here=E2=80=99s a first draft of a non-copyable polymorphic ca=
ll wrapper proposal: <a href=3D"http://bit.ly/uniqfun" target=3D"_blan=
k" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.com/url?q=
\75http%3A%2F%2Fbit.ly%2Funiqfun\46sa\75D\46sntz\0751\46usg\75AFQjCNHpv1IQv=
wAGd50WXzFZsNAyV4dpRA';return true;" onclick=3D"this.href=3D'http://www.goo=
gle.com/url?q\75http%3A%2F%2Fbit.ly%2Funiqfun\46sa\75D\46sntz\0751\46usg\75=
AFQjCNHpv1IQvwAGd50WXzFZsNAyV4dpRA';return true;">http://bit.ly/<wbr>uniqfu=
n</a></div></blockquote><div><br>It'd probably be a good idea to let someon=
e know if a link goes to Dropbox to download a PDF, or if it's just a HTML =
page on the web. You know, without having to click the link.<br><br></div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break-w=
ord"><div><blockquote type=3D"cite"><p style=3D"margin:0px 0px 16px">This p=
roposal describes a variation of <span style=3D"font-family:Courier;backgro=
und-color:rgb(245,245,245)">std::function</span> supporting non-copyable ta=
rget objects. It removes the copy constructor, and adds in-place constructi=
on of target objects.</p></blockquote></div><div>All comments welcome. Does=
n=E2=80=99t look too scary, I just might prototype it.</div></div></blockqu=
ote><div><br>Well, that would help. At least it would let us know the kind =
of work that would be involved in doing a move-transfer from `function` to =
`unique_function`. The concern there being the changes to `function`'s impl=
ementation that would need to be made.<br><br>On the proposal, I think the =
idea of a `unique_any` could be valuable. I'm not sure if a non-moveable `u=
nique_any` could be useful by someone, but it's possible.<br><br>But I don'=
t like the idea of considering `any`s to be at all equivalent to or transfo=
rmable between `function`s. While their implementations are very similar, t=
he objects are conceptually quite distinct. Just like `vector` and `string`=
.. As such, I don't think we should explicitly support transforming one into=
the other.<br><br>I see you have `allocate_assign` and `emplace_assign`. I=
t seems to me that you should follow the existing std::function convention.=
`allocate_assign` is conceptually equivalent to `function::assign`, so you=
should probably just call it that. Also, I see no reason why it shouldn't =
also be able to work like `function::assign`. Similarly, `emplace_assign` s=
hould simply be called `emplace`. These sound more like the standard <br><b=
r>I'm going to assume that you intended to add an `operator()` overload in =
there somewhere. ;) However, unlike Casey Carter, I would not suggest attem=
pting to fix the thread safety problem until the committee has decided how =
they're going to fix it in `std::function`. We don't want two completely di=
fferent fixes involved.<br><br>That's not to say that something shouldn't b=
e done. It's more to say that this proposal should hold off on committing t=
o any one solution until more is known.<br><br>Lastly, bikeshedding. I'm no=
t sure that `unique` is the right word. Oh, it conjures up thoughts of `uni=
que_ptr`, which makes you think "move only". But `unique_ptr` is about owne=
rship of memory, while `unique_function` is just about being a move-only fu=
nction wrapper. At the same time, I cannot come up with a more explicit nam=
e that doesn't sound silly (like `move_only_function`).<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_423_1893908499.1432057353927--
------=_Part_422_2104664548.1432057353927--
.
Author: "'Matt Calabrese' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Tue, 19 May 2015 10:48:24 -0700
Raw View
--001a1130d45ec718f4051672ead8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tue, May 19, 2015 at 10:26 AM, Casey Carter <cartec69@gmail.com> wrote:
>
> On Tuesday, May 19, 2015 at 11:07:03 AM UTC-5, David Krauss wrote:
>>
>> Here=E2=80=99s a first draft of a non-copyable polymorphic call wrapper =
proposal:
>> http://bit.ly/uniqfun
>>
>
> unique_function would probably be more useful if it had operator(). Jokin=
g
> aside, there should probably be three overloads qualified by &, const&, a=
nd
> && respectively. That way you both avoid std::function's threadsafety
> problems (
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4348.html) and
> enable unique_function to usefully hold "one-shot" functions.
>
Please no, as this would require type erasing all of those. I've been
working on a similar effort and my personal thoughts are that the
qualification should be specified as a part of the function type, with
exactly one signature being erased (and that signature being reflected at
the top-level as well):
unique_function<void() const> // for operator() const
unique_function<void() &&> // for operator() &&
Do not type-erase more than is necessary as it can force compile errors
even when the operations are not actually used (and cause bloating, but
this is probably not as important to worry about). It's the same reason we
need a move-only function even though you might not ever actually use the
copy operation when you put something that is move only into it. Don't type
erase more than what you need. Keep the requirements minimal.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a1130d45ec718f4051672ead8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, May 19, 2015 at 10:26 AM, Casey Carter <span dir=3D"ltr"><<a href=3D=
"mailto:cartec69@gmail.com" target=3D"_blank">cartec69@gmail.com</a>></s=
pan> 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"><span class=
=3D""><br>On Tuesday, May 19, 2015 at 11:07:03 AM UTC-5, David Krauss wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word=
">Here=E2=80=99s a first draft of a non-copyable polymorphic call wrapper p=
roposal:=C2=A0<a href=3D"http://bit.ly/uniqfun" rel=3D"nofollow" target=3D"=
_blank">http://bit.ly/uniqfun</a></div></blockquote><div><br></div></span><=
div>unique_function would probably be more useful if it had operator(). Jok=
ing aside, there should probably be three overloads qualified by &, con=
st&, and && respectively. That way you both avoid std::function=
's threadsafety problems (<a href=3D"http://www.open-std.org/jtc1/sc22/=
wg21/docs/papers/2015/n4348.html" target=3D"_blank">http://www.open-std.org=
/jtc1/sc22/wg21/docs/papers/2015/n4348.html</a>) and enable unique_function=
to usefully hold "one-shot" functions.</div></div></blockquote><=
div><br></div><div>Please no, as this would require type erasing all of tho=
se. I've been working on a similar effort and my personal thoughts are =
that the qualification should be specified as a part of the function type, =
with exactly one signature being erased (and that signature being reflected=
at the top-level as well):</div><div><br></div><div>unique_function<voi=
d() const> // for operator() const</div><div>unique_function<void() &=
amp;&> // for operator() &&</div><div><br></div><div>Do not =
type-erase more than is necessary as it can force compile errors even when =
the operations are not actually used (and cause bloating, but this is proba=
bly not as important to worry about). It's the same reason we need a mo=
ve-only function even though you might not ever actually use the copy opera=
tion when you put something that is move only into it. Don't type erase=
more than what you need. Keep the requirements minimal.</div></div></div><=
/div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a1130d45ec718f4051672ead8--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Tue, 19 May 2015 12:49:22 -0500
Raw View
--001a11c33d32ad9d39051672f039
Content-Type: text/plain; charset=UTF-8
On 19 May 2015 at 12:42, Nicol Bolas <jmckesson@gmail.com> wrote:
>
> On the proposal, I think the idea of a `unique_any` could be valuable. I'm
> not sure if a non-moveable `unique_any` could be useful by someone, but
> it's possible.
>
Can't you always make unique_any moveable, given that it can allocate in
the heap?
Also, consider making unique_function(unique_function&&) noexcept.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
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/.
--001a11c33d32ad9d39051672f039
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 19 May 2015 at 12:42, Nicol Bolas <span dir=3D"ltr"><=
;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.c=
om</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_=
quote"><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><br>On the prop=
osal, I think the idea of a `unique_any` could be valuable. I'm not sur=
e if a non-moveable `unique_any` could be useful by someone, but it's p=
ossible.<br></div></div></blockquote><div><br></div><div>Can't you alwa=
ys make unique_any moveable, given that it can allocate in the heap?</div><=
div><br></div><div>Also, consider making unique_function(unique_function&am=
p;&) noexcept.</div></div>-- <br><div class=3D"gmail_signature">=C2=A0N=
evin ":-)" Liber=C2=A0 <mailto:<a href=3D"mailto:nevin@evilove=
rlord.com" target=3D"_blank">nevin@eviloverlord.com</a>>=C2=A0 (847) 691=
-1404</div>
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c33d32ad9d39051672f039--
.
Author: "'Matt Calabrese' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Tue, 19 May 2015 10:52:14 -0700
Raw View
--20cf303f64d082368b051672f815
Content-Type: text/plain; charset=UTF-8
On Tue, May 19, 2015 at 10:49 AM, Nevin Liber <nevin@eviloverlord.com>
wrote:
> Also, consider making unique_function(unique_function&&) noexcept.
>
+1 for noexcept, and it should be able to avoid calling the move
constructor when in remote storage (forcing remote storage if the
underlying object has a move constructor that can throw)
--
---
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/.
--20cf303f64d082368b051672f815
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, May 19, 2015 at 10:49 AM, Nevin Liber <span dir=3D"ltr"><<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><div>Also, consider making=
unique_function(unique_function&&) noexcept.</div></div></div></di=
v></blockquote><div><br></div><div>+1 for noexcept, and it should be able t=
o avoid calling the move constructor when in remote storage (forcing remote=
storage if the underlying object has a move constructor that can throw)</d=
iv></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--20cf303f64d082368b051672f815--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 19 May 2015 12:40:53 -0700 (PDT)
Raw View
------=_Part_878_2143929285.1432064453551
Content-Type: multipart/alternative;
boundary="----=_Part_879_391379982.1432064453551"
------=_Part_879_391379982.1432064453551
Content-Type: text/plain; charset=UTF-8
On Tuesday, May 19, 2015 at 1:50:05 PM UTC-4, Nevin ":-)" Liber wrote:
>
> On 19 May 2015 at 12:42, Nicol Bolas <jmck...@gmail.com <javascript:>>
> wrote:
>
>>
>> On the proposal, I think the idea of a `unique_any` could be valuable.
>> I'm not sure if a non-moveable `unique_any` could be useful by someone, but
>> it's possible.
>>
>
> Can't you always make unique_any moveable, given that it can allocate in
> the heap?
>
Oh, I wasn't saying that `unique_any` should be non-moveable. I was
referring to the way that `unique_function` allows the storage of
non-moveable types, and I was saying that this feature probably won't be as
useful to `unique_any`.
> Also, consider making unique_function(unique_function&&) noexcept.
>
>
Well, the reason it's not noexcept is that `unique_function` is allowed to
store non-moveable types. And since the type is erased (unlike, say,
non-moveable std::vector), the only way to signal an error when you attempt
to move it is to throw an exception.
That being said, I don't think the benefits of being able to store immobile
functions outweight the benefits of having noexcept move
constructor/assignment.
--
---
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_879_391379982.1432064453551
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, May 19, 2015 at 1:50:05 PM UTC-4, Nevi=
n ":-)" Liber wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">On 19 May 2015 at 12:42, Nicol Bolas <span dir=3D"ltr"><<a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"vo7lnzYfyCQJ" r=
el=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return true;" oncl=
ick=3D"this.href=3D'javascript:';return true;">jmck...@gmail.com</a>></s=
pan> wrote:<br><div><div class=3D"gmail_quote"><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><div><br>On the proposal, I think the idea of a `unique=
_any` could be valuable. I'm not sure if a non-moveable `unique_any` could =
be useful by someone, but it's possible.<br></div></div></blockquote><div><=
br></div><div>Can't you always make unique_any moveable, given that it can =
allocate in the heap?</div></div></div></div></blockquote><div><br>Oh, I wa=
sn't saying that `unique_any` should be non-moveable. I was referring to th=
e way that `unique_function` allows the storage of non-moveable types, and =
I was saying that this feature probably won't be as useful to `unique_any`.=
<br> </div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><div><div class=3D"gmail_quote"><div></div><div>Also, consider making un=
ique_function(unique_<wbr>function&&) noexcept.</div></div><br></di=
v></div></blockquote><div><br>Well, the reason it's not noexcept is that `u=
nique_function` is allowed to store non-moveable types. And since the type =
is erased (unlike, say, non-moveable std::vector), the only way to signal a=
n error when you attempt to move it is to throw an exception.<br><br>That b=
eing said, I don't think the benefits of being able to store immobile funct=
ions outweight the benefits of having noexcept move constructor/assignment.=
<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_879_391379982.1432064453551--
------=_Part_878_2143929285.1432064453551--
.
Author: "'Matt Calabrese' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Tue, 19 May 2015 12:47:14 -0700
Raw View
--089e013a1a38bc998d0516749339
Content-Type: text/plain; charset=UTF-8
On Tue, May 19, 2015 at 12:40 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
> Well, the reason it's not noexcept is that `unique_function` is allowed to
> store non-moveable types. And since the type is erased (unlike, say,
> non-moveable std::vector), the only way to signal an error when you attempt
> to move it is to throw an exception.
>
> That being said, I don't think the benefits of being able to store
> immobile functions outweight the benefits of having noexcept move
> constructor/assignment.
>
Or just don't require invocation of the move constructor since you can,
instead, copy the pointer to it if it's in remote storage (and you just
force remote storage if the operation isn't noexcept, even if it fits in
the small object storage). I don't buy the "what if the move constructor
has side effects so we must call it" standpoint, since the language already
allows things like copy/move elision for return value and argument passing.
You can implement no-except move even if the type-erased object has a move
constructor that can throw.
FWIW, I'm pretty sure the proposed std::any has noexcept move operations.
--
---
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/.
--089e013a1a38bc998d0516749339
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, May 19, 2015 at 12:40 PM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"=
mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></=
span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Well, the =
reason it's not noexcept is that `unique_function` is allowed to store =
non-moveable types. And since the type is erased (unlike, say, non-moveable=
std::vector), the only way to signal an error when you attempt to move it =
is to throw an exception.<br><br>That being said, I don't think the ben=
efits of being able to store immobile functions outweight the benefits of h=
aving noexcept move constructor/assignment.</div></div></blockquote><div><b=
r></div><div>Or just don't require invocation of the move constructor s=
ince you can, instead, copy the pointer to it if it's in remote storage=
(and you just force remote storage if the operation isn't noexcept, ev=
en if it fits in the small object storage). I don't buy the "what =
if the move constructor has side effects so we must call it" standpoin=
t, since the language already allows things like copy/move elision for retu=
rn value and argument passing. You can implement no-except move even if the=
type-erased object has a move constructor that can throw.</div><div><br></=
div><div>FWIW, I'm pretty sure the proposed std::any has noexcept move =
operations.</div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e013a1a38bc998d0516749339--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Tue, 19 May 2015 15:02:48 -0500
Raw View
--089e01419ad2dec34c051674cd20
Content-Type: text/plain; charset=UTF-8
On 19 May 2015 at 14:40, Nicol Bolas <jmckesson@gmail.com> wrote:
> Well, the reason it's not noexcept is that `unique_function` is allowed to
> store non-moveable types. And since the type is erased (unlike, say,
> non-moveable std::vector), the only way to signal an error when you attempt
> to move it is to throw an exception.
>
The libc++ version of std::function has a noexcept move constructor, and
other implementers are looking to follow suit.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
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/.
--089e01419ad2dec34c051674cd20
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1=
9 May 2015 at 14:40, Nicol Bolas <span dir=3D"ltr"><<a href=3D"mailto:jm=
ckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></span> wro=
te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Well, the reaso=
n it's not noexcept is that `unique_function` is allowed to store non-m=
oveable types. And since the type is erased (unlike, say, non-moveable std:=
:vector), the only way to signal an error when you attempt to move it is to=
throw an exception.=C2=A0</div></div></blockquote><div><br></div><div>The =
libc++ version of std::function has a noexcept move constructor, and other =
implementers are looking to follow suit.=C2=A0</div></div>-- <br><div class=
=3D"gmail_signature">=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a =
href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord=
..com</a>>=C2=A0 (847) 691-1404</div>
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e01419ad2dec34c051674cd20--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Tue, 19 May 2015 15:06:16 -0500
Raw View
--047d7bb70e4a4e98ab051674da52
Content-Type: text/plain; charset=UTF-8
On 19 May 2015 at 14:47, 'Matt Calabrese' via ISO C++ Standard - Future
Proposals <std-proposals@isocpp.org> wrote:
> On Tue, May 19, 2015 at 12:40 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>>
>> Well, the reason it's not noexcept is that `unique_function` is allowed
>> to store non-moveable types. And since the type is erased (unlike, say,
>> non-moveable std::vector), the only way to signal an error when you attempt
>> to move it is to throw an exception.
>>
>> That being said, I don't think the benefits of being able to store
>> immobile functions outweight the benefits of having noexcept move
>> constructor/assignment.
>>
>
> Or just don't require invocation of the move constructor since you can,
> instead, copy the pointer to it if it's in remote storage (and you just
> force remote storage if the operation isn't noexcept, even if it fits in
> the small object storage). I don't buy the "what if the move constructor
> has side effects so we must call it" standpoint, since the language already
> allows things like copy/move elision for return value and argument passing.
>
Worse, if you required it, you'd have to do a second heap allocation for
moves that couldn't be embedded in the unique_function object just to call
it. Ugh.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
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/.
--047d7bb70e4a4e98ab051674da52
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1=
9 May 2015 at 14:47, 'Matt Calabrese' via ISO C++ Standard - Future=
Proposals <span dir=3D"ltr"><<a href=3D"mailto:std-proposals@isocpp.org=
" target=3D"_blank">std-proposals@isocpp.org</a>></span> wrote:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><span class=3D"">On Tue, May 19, 2015 at 12:40 PM, Ni=
col Bolas <span dir=3D"ltr"><<a href=3D"mailto:jmckesson@gmail.com" targ=
et=3D"_blank">jmckesson@gmail.com</a>></span> wrote:<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>Well, the reason it's not noexcept is =
that `unique_function` is allowed to store non-moveable types. And since th=
e type is erased (unlike, say, non-moveable std::vector), the only way to s=
ignal an error when you attempt to move it is to throw an exception.<br><br=
>That being said, I don't think the benefits of being able to store imm=
obile functions outweight the benefits of having noexcept move constructor/=
assignment.</div></div></blockquote><div><br></div></span><div>Or just don&=
#39;t require invocation of the move constructor since you can, instead, co=
py the pointer to it if it's in remote storage (and you just force remo=
te storage if the operation isn't noexcept, even if it fits in the smal=
l object storage). I don't buy the "what if the move constructor h=
as side effects so we must call it" standpoint, since the language alr=
eady allows things like copy/move elision for return value and argument pas=
sing.</div></div></div></div></blockquote><div><br></div><div>Worse, if you=
required it, you'd have to do a second heap allocation for moves that =
couldn't be embedded in the unique_function object just to call it.=C2=
=A0 Ugh.</div></div>-- <br><div class=3D"gmail_signature">=C2=A0Nevin "=
;:-)" Liber=C2=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.com"=
target=3D"_blank">nevin@eviloverlord.com</a>>=C2=A0 (847) 691-1404</div=
>
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7bb70e4a4e98ab051674da52--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 19 May 2015 13:16:47 -0700 (PDT)
Raw View
------=_Part_539_814529928.1432066607590
Content-Type: multipart/alternative;
boundary="----=_Part_540_1743733918.1432066607590"
------=_Part_540_1743733918.1432066607590
Content-Type: text/plain; charset=UTF-8
On Tuesday, May 19, 2015 at 3:47:15 PM UTC-4, Matt Calabrese wrote:
>
> On Tue, May 19, 2015 at 12:40 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>>
>> Well, the reason it's not noexcept is that `unique_function` is allowed
>> to store non-moveable types. And since the type is erased (unlike, say,
>> non-moveable std::vector), the only way to signal an error when you attempt
>> to move it is to throw an exception.
>>
>> That being said, I don't think the benefits of being able to store
>> immobile functions outweight the benefits of having noexcept move
>> constructor/assignment.
>>
>
> Or just don't require invocation of the move constructor since you can,
> instead, copy the pointer to it if it's in remote storage (and you just
> force remote storage if the operation isn't noexcept, even if it fits in
> the small object storage). I don't buy the "what if the move constructor
> has side effects so we must call it" standpoint, since the language already
> allows things like copy/move elision for return value and argument passing.
> You can implement no-except move even if the type-erased object has a move
> constructor that can throw.
>
Right. Obviously. Sorry, wasn't paying attention.
So yes, make it noexcept.
--
---
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_540_1743733918.1432066607590
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, May 19, 2015 at 3:47:15 PM UTC-4, Matt=
Calabrese wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><div class=3D"gmail_quote">On Tue, May 19, 2015 at 12:40 PM, Nicol=
Bolas <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-=
obfuscated-mailto=3D"YmrLEohSOOEJ" rel=3D"nofollow" onmousedown=3D"this.hre=
f=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';return=
true;">jmck...@gmail.com</a>></span> wrote:<blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><div>Well, the reason it's not noexcept is that `unique=
_function` is allowed to store non-moveable types. And since the type is er=
ased (unlike, say, non-moveable std::vector), the only way to signal an err=
or when you attempt to move it is to throw an exception.<br><br>That being =
said, I don't think the benefits of being able to store immobile functions =
outweight the benefits of having noexcept move constructor/assignment.</div=
></div></blockquote><div><br></div><div>Or just don't require invocation of=
the move constructor since you can, instead, copy the pointer to it if it'=
s in remote storage (and you just force remote storage if the operation isn=
't noexcept, even if it fits in the small object storage). I don't buy the =
"what if the move constructor has side effects so we must call it" standpoi=
nt, since the language already allows things like copy/move elision for ret=
urn value and argument passing. You can implement no-except move even if th=
e type-erased object has a move constructor that can throw.</div></div></di=
v></div></blockquote><div><br>Right. Obviously. Sorry, wasn't paying attent=
ion.<br><br>So yes, make it noexcept.<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_540_1743733918.1432066607590--
------=_Part_539_814529928.1432066607590--
.
Author: David Krauss <potswa@mac.com>
Date: Wed, 20 May 2015 07:16:02 +0800
Raw View
> On 2015=E2=80=9305=E2=80=9320, at 1:26 AM, Casey Carter <cartec69@gmail.c=
om> wrote:
>=20
> unique_function would probably be more useful if it had operator(). Jokin=
g aside, there should probably be three overloads qualified by &, const&, a=
nd && respectively. That way you both avoid std::function's threadsafety pr=
oblems (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4348.html)=
and enable unique_function to usefully hold "one-shot" functions.
I=E2=80=99m writing a separate proposal for that.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: David Krauss <potswa@mac.com>
Date: Wed, 20 May 2015 08:08:37 +0800
Raw View
--Apple-Mail=_B22101B2-87A8-4B2B-9FAB-58B1A13F5CFF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9305=E2=80=9320, at 1:42 AM, Nicol Bolas <jmckesson@gmail.c=
om> wrote:
>=20
> On Tuesday, May 19, 2015 at 12:07:03 PM UTC-4, David Krauss wrote:
> Here=E2=80=99s a first draft of a non-copyable polymorphic call wrapper p=
roposal: http://bit.ly/uniqfun <http://bit.ly/uniqfun>
>=20
> It'd probably be a good idea to let someone know if a link goes to Dropbo=
x to download a PDF, or if it's just a HTML page on the web. You know, with=
out having to click the link.
Ah. It=E2=80=99s a PDF. I tried to put the extension inside the link, but f=
or some reason Bitly doesn=E2=80=99t allow it.
> Well, that would help. At least it would let us know the kind of work tha=
t would be involved in doing a move-transfer from `function` to `unique_fun=
ction`. The concern there being the changes to `function`'s implementation =
that would need to be made.
Unfortunately, prototyping it once will only provide information about one =
std::function implementation.
Having reviewed GNU=E2=80=99s, I think will involve adding a __move_functor=
verb after __clone_functor, which may already be needed for conformance: I=
t never calls the target move constructor, but [func.wrap.func.con]/11 ment=
ions doing so.
But I=E2=80=99m still at square one: I=E2=80=99ll probably do it as a Clang=
extension, because their license allows other implementations to borrow.
> But I don't like the idea of considering `any`s to be at all equivalent t=
o or transformable between `function`s. While their implementations are ver=
y similar, the objects are conceptually quite distinct. Just like `vector` =
and `string`. As such, I don't think we should explicitly support transform=
ing one into the other.
That sort of thing will only be proposed later. I think the use-case could =
become more apparent following a first round of extensions.
For now, I=E2=80=99m only using the any name in the common interfaces. Alte=
rnate names would be appreciated.
> I see you have `allocate_assign` and `emplace_assign`. It seems to me tha=
t you should follow the existing std::function convention. `allocate_assign=
` is conceptually equivalent to `function::assign`, so you should probably =
just call it that.
I guess so. I don=E2=80=99t like how assign always requires an allocator, a=
nd reverses the order of arguments compared to the constructor.
> Also, I see no reason why it shouldn't also be able to work like `functio=
n::assign`.
Can you elaborate?
There draft should individually specify those functions. The new assign/all=
ocate_assign performs
unique_function( allocator_arg_t, a, any_piecewise_construct_tag<F>, std::f=
orward<Args>(args)... ).swap(*this);
(This is an overspecification, since it requires an extraneous move in the =
small-function optimization case, but the style is how std::function is cur=
rently specified.)
> Similarly, `emplace_assign` should simply be called `emplace`. These soun=
d more like the standard=20
Ehh, but emplace always does an insert operation, not an overwrite operatio=
n.
> I'm going to assume that you intended to add an `operator()` overload in =
there somewhere. ;) However, unlike Casey Carter, I would not suggest attem=
pting to fix the thread safety problem until the committee has decided how =
they're going to fix it in `std::function`. We don't want two completely di=
fferent fixes involved.
I initially wrote the synopsis including all the member signatures of std::=
function. That was really messy, so I rewrote it with using declarations. T=
he private-inheritance thing was really distracting and misleading so I jus=
t put a one-line comment instead.
I=E2=80=99ll add a second comment line, since I guess a <functional> propos=
al that never mentions the call operator is weird.
> That's not to say that something shouldn't be done. It's more to say that=
this proposal should hold off on committing to any one solution until more=
is known.
There=E2=80=99s a separate proposal, which I actually split this one from:
> std::function has some rough edges. Its interface is a product of evoluti=
on, and not necessarily the expression of a consistent theory. A model is p=
resented to describe what std::function already safely does. Evolutionary, =
not-immediately-breaking solutions to all the problems presented in N4159 a=
re proposed, plus further extensions.
>=20
> Specifically, this proposal includes:
>=20
> =E2=80=A2 Specializations over cv-qualified and ref-qualified signatures
> =E2=80=A2 Multiple signatures in a single specialization
> =E2=80=A2 Interface unification with std::any from the Library Fundament=
als TS
> =E2=80=A2 A functor adapter template critical_section for adding thread =
safety
>=20
> So, std::unique_function< void() &, void() const &, void() && > would be =
a handle to a non-copyable function object which discriminates the major ac=
cess styles.
Stay tuned. It=E2=80=99s Deusy.
> Lastly, bikeshedding. I'm not sure that `unique` is the right word. Oh, i=
t conjures up thoughts of `unique_ptr`, which makes you think "move only". =
But `unique_ptr` is about ownership of memory, while `unique_function` is j=
ust about being a move-only function wrapper. At the same time, I cannot co=
me up with a more explicit name that doesn't sound silly (like `move_only_f=
unction`).
It=E2=80=99s not about the memory, it=E2=80=99s about the object in the mem=
ory. The ownership idea is the same. There=E2=80=99s the small-function opt=
imization, but it doesn=E2=80=99t really make a conceptual difference. It g=
ets disabled if there=E2=80=99s no move constructor.
move_only_function doesn=E2=80=99t fit because targets may be copyable or n=
on-movable.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_B22101B2-87A8-4B2B-9FAB-58B1A13F5CFF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9305=
=E2=80=9320, at 1:42 AM, Nicol Bolas <<a href=3D"mailto:jmckesson@gmail.=
com" class=3D"">jmckesson@gmail.com</a>> wrote:</div><br class=3D"Apple-=
interchange-newline"><div class=3D""><div dir=3D"ltr" class=3D"">On Tuesday=
, May 19, 2015 at 12:07:03 PM UTC-4, David Krauss wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div style=3D"word-wrap:break-word" class=3D"">=
Here=E2=80=99s a first draft of a non-copyable polymorphic call wrapper pro=
posal: <a href=3D"http://bit.ly/uniqfun" target=3D"_blank" rel=3D"nofo=
llow" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%=
2Fbit.ly%2Funiqfun\46sa\75D\46sntz\0751\46usg\75AFQjCNHpv1IQvwAGd50WXzFZsNA=
yV4dpRA';return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\=
75http%3A%2F%2Fbit.ly%2Funiqfun\46sa\75D\46sntz\0751\46usg\75AFQjCNHpv1IQvw=
AGd50WXzFZsNAyV4dpRA';return true;" class=3D"">http://bit.ly/<wbr class=3D"=
">uniqfun</a></div></blockquote><div class=3D""><br class=3D"">It'd probabl=
y be a good idea to let someone know if a link goes to Dropbox to download =
a PDF, or if it's just a HTML page on the web. You know, without having to =
click the link.<br class=3D""></div></div></div></blockquote><div><br class=
=3D""></div><div>Ah. It=E2=80=99s a PDF. I tried to put the extension insid=
e the link, but for some reason Bitly doesn=E2=80=99t allow it.</div><br cl=
ass=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div dir=3D"l=
tr" class=3D""><div class=3D"">Well, that would help. At least it would let=
us know the kind of work that would be involved in doing a move-transfer f=
rom `function` to `unique_function`. The concern there being the changes to=
`function`'s implementation that would need to be made.</div></div></div><=
/blockquote><div><br class=3D""></div><div>Unfortunately, prototyping it on=
ce will only provide information about one <font face=3D"Courier" class=3D"=
">std::function</font> implementation.</div><div><br class=3D""></div><div>=
Having reviewed GNU=E2=80=99s, I think will involve adding a <font face=3D"=
Courier" class=3D"">__move_functor</font> verb after <font face=3D"Courier"=
class=3D"">__clone_functor</font>, which may already be needed for conform=
ance: It never calls the target move constructor, but [func.wrap.func.con]/=
11 mentions doing so.</div><div><br class=3D""></div><div>But I=E2=80=99m s=
till at square one: I=E2=80=99ll probably do it as a Clang extension, becau=
se their license allows other implementations to borrow.</div><br class=3D"=
"><blockquote type=3D"cite" class=3D""><div class=3D""><div dir=3D"ltr" cla=
ss=3D""><div class=3D"">But I don't like the idea of considering `any`s to =
be at all equivalent to or transformable between `function`s. While their i=
mplementations are very similar, the objects are conceptually quite distinc=
t. Just like `vector` and `string`. As such, I don't think we should explic=
itly support transforming one into the other.<br class=3D""></div></div></d=
iv></blockquote><div><br class=3D""></div><div>That sort of thing will only=
be proposed later. I think the use-case could become more apparent followi=
ng a first round of extensions.</div><div><br class=3D""></div><div>For now=
, I=E2=80=99m only using the <font face=3D"Courier" class=3D"">any</font> n=
ame in the common interfaces. Alternate names would be appreciated.</div><d=
iv><br class=3D""></div><blockquote type=3D"cite" class=3D""><div class=3D"=
"><div dir=3D"ltr" class=3D""><div class=3D"">I see you have `allocate_assi=
gn` and `emplace_assign`. It seems to me that you should follow the existin=
g std::function convention. `allocate_assign` is conceptually equivalent to=
`function::assign`, so you should probably just call it that. </div></div>=
</div></blockquote><div><br class=3D""></div><div>I guess so. I don=E2=80=
=99t like how <font face=3D"Courier" class=3D"">assign</font> always requir=
es an allocator, and reverses the order of arguments compared to the constr=
uctor.</div><br class=3D""><blockquote type=3D"cite" class=3D""><div class=
=3D""><div dir=3D"ltr" class=3D""><div class=3D"">Also, I see no reason why=
it shouldn't also be able to work like `function::assign`.</div></div></di=
v></blockquote><div><br class=3D""></div><div>Can you elaborate?</div><div>=
<br class=3D""></div><div>There draft should individually specify those fun=
ctions. The new <font face=3D"Courier" class=3D"">assign</font>/<font face=
=3D"Courier" class=3D"">allocate_assign</font> performs</div><div><br class=
=3D""></div><div><font face=3D"Courier" class=3D"">unique_function( al=
locator_arg_t, a, any_piecewise_construct_tag<F>, std::forward<Arg=
s>(args)... ).swap(*this);</font></div><div><br class=3D""></div><div>(T=
his is an overspecification, since it requires an extraneous move in the sm=
all-function optimization case, but the style is how <font face=3D"Courier"=
class=3D"">std::function</font> is currently specified.)</div><br class=3D=
""><blockquote type=3D"cite" class=3D""><div class=3D""><div dir=3D"ltr" cl=
ass=3D""><div class=3D"">Similarly, `emplace_assign` should simply be calle=
d `emplace`. These sound more like the standard <br class=3D""></div></div>=
</div></blockquote><div><br class=3D""></div><div>Ehh, but <font face=3D"Co=
urier" class=3D"">emplace</font> always does an insert operation, not =
an overwrite operation.</div><br class=3D""><blockquote type=3D"cite" class=
=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div class=3D"">I'm going=
to assume that you intended to add an `operator()` overload in there somew=
here. ;) However, unlike Casey Carter, I would not suggest attempting to fi=
x the thread safety problem until the committee has decided how they're goi=
ng to fix it in `std::function`. We don't want two completely different fix=
es involved.<br class=3D""></div></div></div></blockquote><div><br class=3D=
""></div><div>I initially wrote the synopsis including all the member signa=
tures of <font face=3D"Courier" class=3D"">std::function</font>. That was r=
eally messy, so I rewrote it with <font face=3D"Courier" class=3D"">us=
ing</font> declarations. The private-inheritance thing was really distracti=
ng and misleading so I just put a one-line comment instead.</div><div><br c=
lass=3D""></div><div>I=E2=80=99ll add a second comment line, since I guess =
a <font face=3D"Courier" class=3D""><functional></font> proposal that=
never mentions the call operator is weird.</div><br class=3D""><blockquote=
type=3D"cite" class=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div =
class=3D"">That's not to say that something shouldn't be done. It's more to=
say that this proposal should hold off on committing to any one solution u=
ntil more is known.<br class=3D""></div></div></div></blockquote><div><br c=
lass=3D""></div><div>There=E2=80=99s a separate proposal, which I actually =
split this one from:</div><div><br class=3D""></div><div><blockquote type=
=3D"cite" class=3D"">std::function has some rough edges. Its interface=
is a product of evolution, and not necessarily the expression of a consist=
ent theory. A model is presented to describe what std::function a=
lready safely does. Evolutionary, not-immediately-breaking solutions t=
o all the problems presented in N4159 are proposed, plus further extensions=
..<br class=3D""><br class=3D"">Specifically, this proposal includes:<br cla=
ss=3D""><br class=3D""><div class=3D""><span class=3D"Apple-tab-span" style=
=3D"white-space:pre"> </span>=E2=80=A2 Specializations over cv-qualified an=
d ref-qualified signatures<br class=3D""></div><div class=3D""><span class=
=3D"Apple-tab-span" style=3D"white-space: pre;"> </span>=E2=80=A2 Multiple =
signatures in a single specialization</div><div class=3D""><span class=3D"A=
pple-tab-span" style=3D"white-space:pre"> </span>=E2=80=A2 Interface unific=
ation with std::any from the Library Fundamentals TS<br class=3D"=
"></div><div><span class=3D"Apple-tab-span" style=3D"white-space: pre;"> </=
span>=E2=80=A2 A functor adapter template critical_section f=
or adding thread safety</div></blockquote><blockquote type=3D"cite" class=
=3D""><br class=3D""></blockquote><blockquote type=3D"cite" class=3D"">So,&=
nbsp;std::unique_function< void() &, void() const &, void() &=
;& > would be a handle to a non-copyable function object which =
discriminates the major access styles.<br class=3D""></blockquote><br class=
=3D""></div><div>Stay tuned. It=E2=80=99s Deusy.</div><br class=3D""><block=
quote type=3D"cite" class=3D""><div class=3D""><div dir=3D"ltr" class=3D"">=
<div class=3D"">Lastly, bikeshedding. I'm not sure that `unique` is the rig=
ht word. Oh, it conjures up thoughts of `unique_ptr`, which makes you think=
"move only". But `unique_ptr` is about ownership of memory, while `unique_=
function` is just about being a move-only function wrapper. At the same tim=
e, I cannot come up with a more explicit name that doesn't sound silly (lik=
e `move_only_function`).<br class=3D""></div></div></div></blockquote><div>=
<br class=3D""></div></div>It=E2=80=99s not about the memory, it=E2=80=99s =
about the object in the memory. The ownership idea is the same. There=E2=80=
=99s the small-function optimization, but it doesn=E2=80=99t really make a =
conceptual difference. It gets disabled if there=E2=80=99s no move construc=
tor.<div class=3D""><br class=3D""></div><div class=3D""><font face=3D"Cour=
ier" class=3D"">move_only_function</font> doesn=E2=80=99t fit because targe=
ts may be copyable or non-movable.</div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_B22101B2-87A8-4B2B-9FAB-58B1A13F5CFF--
.
Author: David Krauss <potswa@gmail.com>
Date: Wed, 20 May 2015 09:26:53 +0800
Raw View
--Apple-Mail=_61F33E0D-EDFD-4798-BD88-4364CDD98D1F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9305=E2=80=9320, at 1:49 AM, Nevin Liber <nevin@eviloverlor=
d.com <mailto:nevin@eviloverlord.com>> wrote:
>=20
> Can't you always make unique_any moveable, given that it can allocate in =
the heap?
unique_any is not proposed here, only mentioned in =E2=80=9Cfuture directio=
ns.=E2=80=9D
> Also, consider making unique_function(unique_function&&) noexcept.
The noexcept qualification of unique_function is the same as for function. =
Both allow exceptions to propagate from the move constructor when the small=
function optimization is applied. It=E2=80=99s a rare corner case, but the=
re=E2=80=99s no static information to make any guarantee.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_61F33E0D-EDFD-4798-BD88-4364CDD98D1F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"><meta http-equiv=3D"Content-Type" content=3D"text/html charset=3D=
utf-8"><meta http-equiv=3D"Content-Type" content=3D"text/html charset=3Dutf=
-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space;" class=3D""><br class=3D""><div clas=
s=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=
=9305=E2=80=9320, at 1:49 AM, Nevin Liber <<a href=3D"mailto:nevin@evilo=
verlord.com" class=3D"">nevin@eviloverlord.com</a>> wrote:</div><br clas=
s=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" class=3D""=
><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D"">Can'=
t you always make unique_any moveable, given that it can allocate in the he=
ap?</div><div class=3D""></div></div></div></div></div></blockquote><div cl=
ass=3D""><br class=3D""></div><div class=3D""><font face=3D"Courier" class=
=3D"">unique_any</font> is not proposed here, only mentioned in =E2=80=9Cfu=
ture directions.=E2=80=9D</div><br class=3D""><blockquote type=3D"cite" cla=
ss=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote"><div class=3D"">Also, consider making unique=
_function(unique_function&&) noexcept.</div></div></div></div></div=
></blockquote><br class=3D""></div><div class=3D"">The noexcept qualificati=
on of <font face=3D"Courier" class=3D"">unique_function</font> is the same =
as for <font face=3D"Courier" class=3D"">function</font>. Both allow except=
ions to propagate from the move constructor when the small function optimiz=
ation is applied. It=E2=80=99s a rare corner case, but there=E2=80=99s no s=
tatic information to make any guarantee.</div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_61F33E0D-EDFD-4798-BD88-4364CDD98D1F--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Tue, 19 May 2015 20:40:23 -0500
Raw View
--089e01177205205cf50516798507
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 19 May 2015 at 20:26, David Krauss <potswa@gmail.com> wrote:
>
> On 2015=E2=80=9305=E2=80=9320, at 1:49 AM, Nevin Liber <nevin@eviloverlor=
d.com> wrote:
>
> Can't you always make unique_any moveable, given that it can allocate in
> the heap?
>
>
> unique_any is not proposed here, only mentioned in =E2=80=9Cfuture direct=
ions.=E2=80=9D
>
So it's off limits to talk about here?
> Also, consider making unique_function(unique_function&&) noexcept.
>
>
> The noexcept qualification of unique_function is the same as for function=
..
> Both allow exceptions to propagate from the move constructor when the sma=
ll
> function optimization is applied. It=E2=80=99s a rare corner case, but th=
ere=E2=80=99s no
> static information to make any guarantee.
>
Fine. Should you present this in Kona, I'll bring this up in LEWG. As we
like to say, until you present a proposal, it's your time to waste.
--=20
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--089e01177205205cf50516798507
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 19 May 2015 at 20:26, David Krauss <span dir=3D"ltr">&l=
t;<a href=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a=
>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote=
"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><br><d=
iv><span class=3D""><blockquote type=3D"cite"><div>On 2015=E2=80=9305=E2=80=
=9320, at 1:49 AM, Nevin Liber <<a href=3D"mailto:nevin@eviloverlord.com=
" target=3D"_blank">nevin@eviloverlord.com</a>> wrote:</div><br><div><di=
v dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>Ca=
n't you always make unique_any moveable, given that it can allocate in =
the heap?</div><div></div></div></div></div></div></blockquote><div><br></d=
iv></span><div><font face=3D"Courier">unique_any</font> is not proposed her=
e, only mentioned in =E2=80=9Cfuture directions.=E2=80=9D</div></div></div>=
</blockquote><div><br></div><div>So it's off limits to talk about here?=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><d=
iv><span class=3D""><blockquote type=3D"cite"><div><div dir=3D"ltr"><div cl=
ass=3D"gmail_extra"><div class=3D"gmail_quote"><div>Also, consider making u=
nique_function(unique_function&&) noexcept.</div></div></div></div>=
</div></blockquote><br></span></div><div>The noexcept qualification of <fon=
t face=3D"Courier">unique_function</font> is the same as for <font face=3D"=
Courier">function</font>. Both allow exceptions to propagate from the move =
constructor when the small function optimization is applied. It=E2=80=99s a=
rare corner case, but there=E2=80=99s no static information to make any gu=
arantee.</div></div></blockquote><div><br></div><div>Fine.=C2=A0 Should you=
present this in Kona, I'll bring this up in LEWG.=C2=A0 As we like to =
say, until you present a proposal, it's your time to waste.</div></div>=
-- <br><div class=3D"gmail_signature">=C2=A0Nevin ":-)" Liber=C2=
=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">=
nevin@eviloverlord.com</a>>=C2=A0 (847) 691-1404</div>
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e01177205205cf50516798507--
.
Author: David Krauss <potswa@gmail.com>
Date: Wed, 20 May 2015 09:53:42 +0800
Raw View
--Apple-Mail=_9AA3278A-698B-488F-BA75-CF628664B6CA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9305=E2=80=9320, at 1:52 AM, 'Matt Calabrese' via ISO C++ S=
tandard - Future Proposals <std-proposals@isocpp.org <mailto:std-proposals@=
isocpp.org>> wrote:
>=20
> On Tue, May 19, 2015 at 10:49 AM, Nevin Liber <nevin@eviloverlord.com <ma=
ilto:nevin@eviloverlord.com>> wrote:
> Also, consider making unique_function(unique_function&&) noexcept.
>=20
> +1 for noexcept, and it should be able to avoid calling the move construc=
tor when in remote storage (forcing remote storage if the underlying object=
has a move constructor that can throw)
That=E2=80=99s an idea. I don=E2=80=99t know if it=E2=80=99s worth it, but =
I=E2=80=99ll add it as a note.
The idea would apply to std::function just as well.
The main problem is that most explicitly-defined move constructors in pract=
ice aren=E2=80=99t noexcept, just because people forget. On the other hand,=
most classes with an explicitly-defined move constructor (or composed from=
something with one) are big enough that the in-wrapper storage optimizatio=
n won=E2=80=99t apply anyway.
Also, another corner case: the move constructor will allocate memory when t=
he source has a non-POCMA (allocator_traits::propagate_on_container_move_as=
signment) allocator. I=E2=80=99m not really seeing an exception-safety guar=
antee being feasible.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_9AA3278A-698B-488F-BA75-CF628664B6CA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"><meta http-equiv=3D"Content-Type" content=3D"text/html charset=3D=
utf-8"><meta http-equiv=3D"Content-Type" content=3D"text/html charset=3Dutf=
-8"><meta http-equiv=3D"Content-Type" content=3D"text/html charset=3Dutf-8"=
><meta http-equiv=3D"Content-Type" content=3D"text/html charset=3Dutf-8"><m=
eta http-equiv=3D"Content-Type" content=3D"text/html charset=3Dutf-8"><meta=
http-equiv=3D"Content-Type" content=3D"text/html charset=3Dutf-8"><meta ht=
tp-equiv=3D"Content-Type" content=3D"text/html charset=3Dutf-8"><meta http-=
equiv=3D"Content-Type" content=3D"text/html charset=3Dutf-8"></head><body s=
tyle=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break=
: after-white-space;" class=3D""><br class=3D""><div class=3D""><blockquote=
type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9305=E2=80=9320, at=
1:52 AM, 'Matt Calabrese' via ISO C++ Standard - Future Proposals <<a h=
ref=3D"mailto:std-proposals@isocpp.org" class=3D"">std-proposals@isocpp.org=
</a>> wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D"=
"><div dir=3D"ltr" class=3D""><div class=3D"gmail_extra"><div class=3D"gmai=
l_quote">On Tue, May 19, 2015 at 10:49 AM, Nevin Liber <span dir=3D"ltr" cl=
ass=3D""><<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank" cl=
ass=3D"">nevin@eviloverlord.com</a>></span> wrote:<br class=3D""><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr" class=3D""><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote"><div class=3D"">Also, consider making unique=
_function(unique_function&&) noexcept.</div></div></div></div></blo=
ckquote><div class=3D""><br class=3D""></div><div class=3D"">+1 for noexcep=
t, and it should be able to avoid calling the move constructor when in remo=
te storage (forcing remote storage if the underlying object has a move cons=
tructor that can throw)</div></div></div></div></div></blockquote><br class=
=3D""></div><div class=3D"">That=E2=80=99s an idea. I don=E2=80=99t know if=
it=E2=80=99s worth it, but I=E2=80=99ll add it as a note.</div><div class=
=3D""><br class=3D""></div><div class=3D"">The idea would apply to <font fa=
ce=3D"Courier" class=3D"">std::function</font> just as well.</div><div clas=
s=3D""><br class=3D""></div><div class=3D"">The main problem is that most e=
xplicitly-defined move constructors in practice aren=E2=80=99t <font face=
=3D"Courier" class=3D"">noexcept</font>, just because people forget. On the=
other hand, most classes with an explicitly-defined move constructor (or c=
omposed from something with one) are big enough that the in-wrapper storage=
optimization won=E2=80=99t apply anyway.</div><div class=3D""><br class=3D=
""></div><div class=3D"">Also, another corner case: the move constructor wi=
ll allocate memory when the source has a non-POCMA (<font face=3D"Courier" =
class=3D"">allocator_traits::propagate_on_container_move_assignment</font>)=
allocator. I=E2=80=99m not really seeing an exception-safety guarantee bei=
ng feasible.</div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_9AA3278A-698B-488F-BA75-CF628664B6CA--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Tue, 19 May 2015 21:18:41 -0500
Raw View
--001a11c33d3221c8ab05167a0e37
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 19 May 2015 at 20:53, David Krauss <potswa@gmail.com> wrote:
> Also, another corner case: the move constructor will allocate memory when
> the source has a non-POCMA (
> allocator_traits::propagate_on_container_move_assignment) allocator. I=E2=
=80=99m
> not really seeing an exception-safety guarantee being feasible.
>
std::vector and std::basic_string have noexcept(true) move constructors.
Are you saying they can't use propagate_on_container_move_assignment
allocators?
--=20
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a11c33d3221c8ab05167a0e37
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On 19 May 2015 at 20:53, David Krauss <span dir=3D"ltr"><<a href=3D"mail=
to:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>></span> wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><d=
iv>Also, another corner case: the move constructor will allocate memory whe=
n the source has a non-POCMA (<font face=3D"Courier">allocator_traits::prop=
agate_on_container_move_assignment</font>) allocator. I=E2=80=99m not reall=
y seeing an exception-safety guarantee being feasible.</div></div></blockqu=
ote><div><br></div><div>std::vector and std::basic_string have noexcept(tru=
e) move constructors.=C2=A0 Are you saying they can't use propagate_on_=
container_move_assignment allocators?</div><div>--=C2=A0<br></div></div><di=
v class=3D"gmail_signature">=C2=A0Nevin ":-)" Liber=C2=A0 <mai=
lto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@evilo=
verlord.com</a>>=C2=A0 (847) 691-1404</div>
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c33d3221c8ab05167a0e37--
.
Author: David Krauss <potswa@mac.com>
Date: Wed, 20 May 2015 10:27:03 +0800
Raw View
--Apple-Mail=_E6E04D6E-736F-46C9-81CA-5063CE772DBA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9305=E2=80=9320, at 9:40 AM, Nevin Liber <nevin@eviloverlor=
d.com> wrote:
>=20
> The noexcept qualification of unique_function is the same as for function=
.. Both allow exceptions to propagate from the move constructor when the sma=
ll function optimization is applied. It=E2=80=99s a rare corner case, but t=
here=E2=80=99s no static information to make any guarantee.
>=20
> Fine. Should you present this in Kona, I'll bring this up in LEWG. As w=
e like to say, until you present a proposal, it's your time to waste.
I don=E2=80=99t understand.
So far, I think noexcept-movable std::function deserves its own paper. Now =
I=E2=80=99m leaning towards saying that it is feasible, but:
1. A throwing move constructor should force heap allocation (disable memory=
optimization). Essentially, both std::function and std::unique_function wo=
uld treat a throwing move constructor as if it didn=E2=80=99t exist, even w=
hile the former may use the copy constructor.
2. std::function is inherently POCMA, and passing a non-POCMA allocator sho=
uld be ill-formed.
> On 2015=E2=80=9305=E2=80=9320, at 10:18 AM, Nevin Liber <nevin@eviloverlo=
rd.com> wrote:
>=20
> std::vector and std::basic_string have noexcept(true) move constructors. =
Are you saying they can't use propagate_on_container_move_assignment alloc=
ators?
Not quite, their noexcept specifications depend on the POCMA of the allocat=
or template parameter.
The idea behind POCMA (or lack thereof) is that you can keep an allocator a=
ttached to a container. But it=E2=80=99s not really designed to work with p=
olymorphism, which introduces the condition where the current allocator is =
non-POCMA and the RHS of assignment, being POCMA, wants to replace it. If f=
unction were to respect the literal meaning, any would-be attached allocato=
r is at the mercy of every assignment operation. So, I conclude point #2 ab=
ove.
(Also, non-POCMA would be a major pain to implement.)
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_E6E04D6E-736F-46C9-81CA-5063CE772DBA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9305=
=E2=80=9320, at 9:40 AM, Nevin Liber <<a href=3D"mailto:nevin@eviloverlo=
rd.com" class=3D"">nevin@eviloverlord.com</a>> wrote:</div></blockquote>=
<blockquote type=3D"cite" class=3D""><div class=3D""><div dir=3D"ltr" class=
=3D""><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div style=3D"word-wrap:break-word" class=3D""><div class=
=3D""><span class=3D""><br class=3D""></span></div><div class=3D"">The noex=
cept qualification of <font face=3D"Courier" class=3D"">unique_function</fo=
nt> is the same as for <font face=3D"Courier" class=3D"">function</font>. B=
oth allow exceptions to propagate from the move constructor when the small =
function optimization is applied. It=E2=80=99s a rare corner case, but ther=
e=E2=80=99s no static information to make any guarantee.</div></div></block=
quote><div class=3D""><br class=3D""></div><div class=3D"">Fine. Shou=
ld you present this in Kona, I'll bring this up in LEWG. As we like t=
o say, until you present a proposal, it's your time to waste.</div></div></=
div></div></div></blockquote><div><br class=3D""></div><div>I don=E2=80=99t=
understand.</div><div><br class=3D""></div><div>So far, I think <font face=
=3D"Courier" class=3D"">noexcept</font>-movable <font face=3D"Courier" clas=
s=3D"">std::function</font> deserves its own paper. Now I=E2=80=99m leaning=
towards saying that it is feasible, but:</div><div><br class=3D""></div><d=
iv>1. A throwing move constructor should force heap allocation (disabl=
e memory optimization). Essentially, both <font face=3D"Courier" class=3D""=
>std::function</font> and <font face=3D"Courier" class=3D"">std::unique_fun=
ction</font> would treat a throwing move constructor as if it didn=E2=80=99=
t exist, even while the former may use the copy constructor.</div><div><br =
class=3D""></div><div>2. <span style=3D"font-family: Courier;" class=
=3D"">std::function</span> is inherently POCMA, and passing a non-POCM=
A allocator should be ill-formed.</div><div><br class=3D""></div><div><br c=
lass=3D""></div><div><blockquote type=3D"cite" class=3D""><div class=3D"">O=
n 2015=E2=80=9305=E2=80=9320, at 10:18 AM, Nevin Liber <<a href=3D"mailt=
o:nevin@eviloverlord.com" class=3D"">nevin@eviloverlord.com</a>> wrote:<=
/div><br class=3D"Apple-interchange-newline"><div class=3D""><div class=3D"=
">std::vector and std::basic_string have noexcept(true) move constructors.&=
nbsp; Are you saying they can't use propagate_on_container_move_assignment =
allocators?</div></div></blockquote><br class=3D""></div><div>Not quite, th=
eir noexcept specifications depend on the POCMA of the allocator template p=
arameter.</div><div><br class=3D""></div><div><div>The idea behind POCMA (o=
r lack thereof) is that you can keep an allocator attached to a container. =
But it=E2=80=99s not really designed to work with polymorphism, which intro=
duces the condition where the current allocator is non-POCMA and the RHS of=
assignment, being POCMA, wants to replace it. If <font face=3D"Courie=
r" class=3D"">function</font> were to respect the literal meaning, any=
would-be attached allocator is at the mercy of every assignment operation.=
So, I conclude point #2 above.</div><div><br class=3D""></div><div>(Also, =
non-POCMA would be a major pain to implement.)</div></div></div></body></ht=
ml>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_E6E04D6E-736F-46C9-81CA-5063CE772DBA--
.
Author: David Krauss <potswa@mac.com>
Date: Wed, 20 May 2015 10:39:34 +0800
Raw View
--Apple-Mail=_537FA55E-6A6A-4282-9849-9B9B074550F0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9305=E2=80=9320, at 10:27 AM, David Krauss <potswa@mac.com>=
wrote:
>=20
> So far, I think noexcept-movable std::function deserves its own paper.
Nah, really it amounts to two separate defects. I=E2=80=99ll report the POC=
MA thing, since it=E2=80=99s almost just academic, and you can take care of=
throwing move constructors if you like.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_537FA55E-6A6A-4282-9849-9B9B074550F0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9305=
=E2=80=9320, at 10:27 AM, David Krauss <<a href=3D"mailto:potswa@mac.com=
" class=3D"">potswa@mac.com</a>> wrote:</div><br class=3D"Apple-intercha=
nge-newline"><div class=3D""><span style=3D"font-family: Helvetica; font-si=
ze: 12px; font-style: normal; font-variant: normal; font-weight: normal; le=
tter-spacing: normal; line-height: normal; orphans: auto; text-align: start=
; text-indent: 0px; text-transform: none; white-space: normal; widows: auto=
; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: =
inline !important;" class=3D"">So far, I think<span class=3D"Apple-converte=
d-space"> </span></span><font face=3D"Courier" class=3D"" style=3D"fon=
t-size: 12px; font-style: normal; font-variant: normal; font-weight: normal=
; letter-spacing: normal; line-height: normal; orphans: auto; text-align: s=
tart; text-indent: 0px; text-transform: none; white-space: normal; widows: =
auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">noexcept</font><s=
pan style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; f=
ont-variant: normal; font-weight: normal; letter-spacing: normal; line-heig=
ht: normal; orphans: auto; text-align: start; text-indent: 0px; text-transf=
orm: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-te=
xt-stroke-width: 0px; float: none; display: inline !important;" class=3D"">=
-movable<span class=3D"Apple-converted-space"> </span></span><font fac=
e=3D"Courier" class=3D"" style=3D"font-size: 12px; font-style: normal; font=
-variant: normal; font-weight: normal; letter-spacing: normal; line-height:=
normal; orphans: auto; text-align: start; text-indent: 0px; text-transform=
: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-=
stroke-width: 0px;">std::function</font><span style=3D"font-family: Helveti=
ca; font-size: 12px; font-style: normal; font-variant: normal; font-weight:=
normal; letter-spacing: normal; line-height: normal; orphans: auto; text-a=
lign: start; text-indent: 0px; text-transform: none; white-space: normal; w=
idows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none=
; display: inline !important;" class=3D""><span class=3D"Apple-converted-sp=
ace"> </span>deserves its own paper.</span></div></blockquote></div><b=
r class=3D""><div class=3D"">Nah, really it amounts to two separate defects=
.. I=E2=80=99ll report the POCMA thing, since it=E2=80=99s almost just acade=
mic, and you can take care of throwing move constructors if you like.</div>=
</body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_537FA55E-6A6A-4282-9849-9B9B074550F0--
.
Author: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Thu, 25 Jun 2015 00:03:09 -0700 (PDT)
Raw View
------=_Part_563_676369765.1435215789573
Content-Type: multipart/alternative;
boundary="----=_Part_564_1115696784.1435215789573"
------=_Part_564_1115696784.1435215789573
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tuesday, May 19, 2015 at 10:48:25 AM UTC-7, Matt Calabrese wrote:
>
> On Tue, May 19, 2015 at 10:26 AM, Casey Carter <cart...@gmail.com=20
> <javascript:>> wrote:
>
>>
>> On Tuesday, May 19, 2015 at 11:07:03 AM UTC-5, David Krauss wrote:
>>>
>>> Here=E2=80=99s a first draft of a non-copyable polymorphic call wrapper=
=20
>>> proposal: http://bit.ly/uniqfun
>>>
>>
>> unique_function would probably be more useful if it had operator().=20
>> Joking aside, there should probably be three overloads qualified by &,=
=20
>> const&, and && respectively. That way you both avoid std::function's=20
>> threadsafety problems (
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4348.html) and=
=20
>> enable unique_function to usefully hold "one-shot" functions.
>>
>
> Please no, as this would require type erasing all of those. I've been=20
> working on a similar effort and my personal thoughts are that the=20
> qualification should be specified as a part of the function type, with=20
> exactly one signature being erased (and that signature being reflected at=
=20
> the top-level as well):
>
> unique_function<void() const> // for operator() const
> unique_function<void() &&> // for operator() &&
>
This is exactly N4159 "std::function and beyond", correct?
N4159 strikes me as exactly the reasonable and sensible thing to do (both=
=20
to fix the thread-safety/const-correctness issue, and to enable=20
std::function-izing of move-only lambdas); can anyone shed some light on=20
its current disposition?
David Krauss, as the author of N4543 (std::unique_function<R(A...)>), do=20
you think it's in any way *preferable* to N4159 (std::function<R(A...)&&>),=
=20
as in,
- is there a good reason to reject N4159?
- if N4159 were adopted, would there still be a good reason to adopt N4543?
I would understand the argument "N4159 is preferable, but N4543 is a decent=
=20
consolation prize were N4159 to be rejected"; I'm just wondering whether=20
that's the only motivating argument behind N4543 or whether I'm missing=20
something.
=E2=80=93Arthur
P.S.: I just ran into this issue while attempting to write a Scheduler that=
=20
manipulates Tasks, where a Task might be for example a lambda one of whose=
=20
captures is a non-copyable UniquePromise. My solution was to implement Task=
=20
from scratch; but in a perfect world Task would have been a typedef for=20
std::function<void()&&>.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_564_1115696784.1435215789573
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tuesday, May 19, 2015 at 10:48:25 AM UTC-7, Matt Calabrese wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"g=
mail_quote">On Tue, May 19, 2015 at 10:26 AM, Casey Carter <span dir=3D"ltr=
"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"Yi=
5x-sYlCIwJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';retur=
n true;" onclick=3D"this.href=3D'javascript:';return true;">cart...@gmail.c=
om</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><span><br>On Tuesday, May 19, 2015 at 11:07:03 AM UTC-5, David Krauss wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-wor=
d">Here=E2=80=99s a first draft of a non-copyable polymorphic call wrapper =
proposal: <a href=3D"http://bit.ly/uniqfun" rel=3D"nofollow" target=3D=
"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%=
2F%2Fbit.ly%2Funiqfun\46sa\75D\46sntz\0751\46usg\75AFQjCNHpv1IQvwAGd50WXzFZ=
sNAyV4dpRA';return true;" onclick=3D"this.href=3D'http://www.google.com/url=
?q\75http%3A%2F%2Fbit.ly%2Funiqfun\46sa\75D\46sntz\0751\46usg\75AFQjCNHpv1I=
QvwAGd50WXzFZsNAyV4dpRA';return true;">http://bit.ly/<wbr>uniqfun</a></div>=
</blockquote><div><br></div></span><div>unique_function would probably be m=
ore useful if it had operator(). Joking aside, there should probably be thr=
ee overloads qualified by &, const&, and && respectively. T=
hat way you both avoid std::function's threadsafety problems (<a href=3D"ht=
tp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4348.html" target=3D=
"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.com=
/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers=
%2F2015%2Fn4348.html\46sa\75D\46sntz\0751\46usg\75AFQjCNFJoUIq2-tdMDiA4oV6Q=
eUx8FItpw';return true;" onclick=3D"this.href=3D'http://www.google.com/url?=
q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F20=
15%2Fn4348.html\46sa\75D\46sntz\0751\46usg\75AFQjCNFJoUIq2-tdMDiA4oV6QeUx8F=
Itpw';return true;">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers=
/2015/<wbr>n4348.html</a>) and enable unique_function to usefully hold "one=
-shot" functions.</div></div></blockquote><div><br></div><div>Please no, as=
this would require type erasing all of those. I've been working on a simil=
ar effort and my personal thoughts are that the qualification should be spe=
cified as a part of the function type, with exactly one signature being era=
sed (and that signature being reflected at the top-level as well):</div><di=
v><br></div><div>unique_function<void() const> // for operator() cons=
t</div><div>unique_function<void() &&> // for operator() &=
;&</div></div></div></div></blockquote><div><br></div><div>This is exac=
tly N4159 "std::function and beyond", correct?</div><div><br></div><div>N41=
59 strikes me as exactly the reasonable and sensible thing to do (both to f=
ix the thread-safety/const-correctness issue, and to enable std::function-i=
zing of move-only lambdas); can anyone shed some light on its current dispo=
sition?</div><div><br></div><div>David Krauss, as the author of N4543 (<fon=
t face=3D"courier new, monospace">std::unique_function<R(A...)></font=
>), do you think it's in any way <i>preferable</i> to N4159 (<font face=3D"=
courier new, monospace">std::function<R(A...)&&></font>), as =
in,</div><div>- is there a good reason to reject N4159?</div><div>- if N415=
9 were adopted, would there still be a good reason to adopt N4543?</div><di=
v>I would understand the argument "N4159 is preferable, but N4543 is a dece=
nt consolation prize were N4159 to be rejected"; I'm just wondering whether=
that's the only motivating argument behind N4543 or whether I'm missing so=
mething.</div><div><br></div><div>=E2=80=93Arthur</div><div><br></div><div>=
P.S.: I just ran into this issue while attempting to write a Scheduler that=
manipulates Tasks, where a Task might be for example a lambda one of whose=
captures is a non-copyable UniquePromise. My solution was to implement Tas=
k from scratch; but in a perfect world Task would have been a typedef for <=
font face=3D"courier new, monospace">std::function<void()&&><=
/font>.</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
</blockquote>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_564_1115696784.1435215789573--
------=_Part_563_676369765.1435215789573--
.
Author: David Krauss <david_work@me.com>
Date: Thu, 25 Jun 2015 15:36:50 +0800
Raw View
--Apple-Mail=_AF07809F-0245-48C1-BB15-A3290151F244
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9306=E2=80=9325, at 3:03 PM, Arthur O'Dwyer <arthur.j.odwye=
r@gmail.com> wrote:
>=20
> This is exactly N4159 "std::function and beyond", correct?
Not =E2=80=9Cexactly,=E2=80=9D but pretty much.
> N4159 strikes me as exactly the reasonable and sensible thing to do (both=
to fix the thread-safety/const-correctness issue, and to enable std::funct=
ion-izing of move-only lambdas); can anyone shed some light on its current =
disposition?
N4159 was accepted as a good to-do list. N4348 and N4543 are follow-ups.
> David Krauss, as the author of N4543 (std::unique_function<R(A...)>), do =
you think it's in any way preferable to N4159 (std::function<R(A...)&&>), a=
s in,
> - is there a good reason to reject N4159?
> - if N4159 were adopted, would there still be a good reason to adopt N454=
3?
Some cognitive dissonance here. How have I contradicted N4159?
If you want to allow non-copyable targets, there are only two choices: 1. L=
et std::function accept them and define its copy constructor to throw (or U=
B), or 2. Create a new, non-copyable polymorphic wrapper.
Looking at page 8 of N4159, it suggests the name std::movable_function for =
what I called unique_function. It goes on to suggest a combined template st=
d::basic_function with a bool non-type parameter. I left this as an impleme=
ntation detail; I don=E2=80=99t think it=E2=80=99s a good interface. I don=
=E2=80=99t see it analyzing alternative #1 at all.
> P.S.: I just ran into this issue while attempting to write a Scheduler th=
at manipulates Tasks, where a Task might be for example a lambda one of who=
se captures is a non-copyable UniquePromise. My solution was to implement T=
ask from scratch; but in a perfect world Task would have been a typedef for=
std::function<void()&&>.
That would be std::unique_function<void()>. Put an rvalue qualifier inside =
if you like. See this summary <https://github.com/potswa/cxx_function#non-c=
opyable-functions> from the documentation to my prototype library.
LEWG in Urbana took a number of straw polls to refine the direction of N415=
9. They=E2=80=99re in the LEWG bugzilla but I can=E2=80=99t find the link r=
ight now.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_AF07809F-0245-48C1-BB15-A3290151F244
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9306=
=E2=80=9325, at 3:03 PM, Arthur O'Dwyer <<a href=3D"mailto:arthur.j.odwy=
er@gmail.com" class=3D"">arthur.j.odwyer@gmail.com</a>> wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div class=3D"">This is=
exactly N4159 "std::function and beyond", correct?</div></div></blockquote=
><div><br class=3D""></div><div>Not =E2=80=9Cexactly,=E2=80=9D but pretty m=
uch.</div><div><br class=3D""></div><blockquote type=3D"cite" class=3D""><d=
iv class=3D""><div class=3D"">N4159 strikes me as exactly the reasonable an=
d sensible thing to do (both to fix the thread-safety/const-correctness iss=
ue, and to enable std::function-izing of move-only lambdas); can anyone she=
d some light on its current disposition?</div></div></blockquote><div><br c=
lass=3D""></div><div>N4159 was accepted as a good to-do list. N4348 and N45=
43 are follow-ups.</div><br class=3D""><blockquote type=3D"cite" class=3D""=
><div class=3D""><div class=3D"">David Krauss, as the author of N4543 (<fon=
t face=3D"courier new, monospace" class=3D"">std::unique_function<R(A...=
)></font>), do you think it's in any way <i class=3D"">preferable</i> to=
N4159 (<font face=3D"courier new, monospace" class=3D"">std::function<R=
(A...)&&></font>), as in,</div><div class=3D"">- is there a good=
reason to reject N4159?</div><div class=3D"">- if N4159 were adopted, woul=
d there still be a good reason to adopt N4543?</div></div></blockquote><div=
><br class=3D""></div><div>Some cognitive dissonance here. How have I contr=
adicted N4159?</div><div><br class=3D""></div><div>If you want to allow non=
-copyable targets, there are only two choices: 1. Let <font face=3D"Courier=
" class=3D"">std::function</font> accept them and define its copy construct=
or to throw (or UB), or 2. Create a new, non-copyable polymorphic wrapper.<=
/div><div><br class=3D""></div><div>Looking at page 8 of N4159, it suggests=
the name <font face=3D"Courier" class=3D"">std::movable_function</font> fo=
r what I called <font face=3D"Courier" class=3D"">unique_function</font>. I=
t goes on to suggest a combined template <font face=3D"Courier" class=3D"">=
std::basic_function</font> with a <font face=3D"Courier" class=3D"">bool</f=
ont> non-type parameter. I left this as an implementation detail; I don=E2=
=80=99t think it=E2=80=99s a good interface. I don=E2=80=99t see it analyzi=
ng alternative #1 at all.</div><br class=3D""><blockquote type=3D"cite" cla=
ss=3D""><div class=3D"">P.S.: I just ran into this issue while attempting t=
o write a Scheduler that manipulates Tasks, where a Task might be for examp=
le a lambda one of whose captures is a non-copyable UniquePromise. My solut=
ion was to implement Task from scratch; but in a perfect world Task would h=
ave been a typedef for <font face=3D"courier new, monospace" class=3D"">std=
::function<void()&&></font>.</div><blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;">
</blockquote></blockquote></div><br class=3D""><div class=3D"">That would b=
e <font face=3D"Courier" class=3D"">std::unique_function<void()></fon=
t>. Put an rvalue qualifier inside if you like. See <a href=3D"https:/=
/github.com/potswa/cxx_function#non-copyable-functions" class=3D"">this sum=
mary</a> from the documentation to my prototype library.</div><div cla=
ss=3D""><br class=3D""></div><div class=3D"">LEWG in Urbana took a number o=
f straw polls to refine the direction of N4159. They=E2=80=99re in the LEWG=
bugzilla but I can=E2=80=99t find the link right now.</div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_AF07809F-0245-48C1-BB15-A3290151F244--
.
Author: David Krauss <david_work@me.com>
Date: Thu, 25 Jun 2015 15:51:01 +0800
Raw View
--Apple-Mail=_A998E045-A328-4515-9406-1FE7D7FE2831
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9306=E2=80=9325, at 3:03 PM, Arthur O'Dwyer <arthur.j.odwye=
r@gmail.com> wrote:
>=20
> David Krauss, as the author of N4543 (std::unique_function<R(A...)>), do =
you think it's in any way preferable to N4159 (std::function<R(A...)&&>), a=
s in,
I see the confusion now. These are orthogonal problems:
1. Can no more than one copy of the target exist? (Solution: unique_functio=
n.)=20
2. Can a given copy be called not more than once? (Solution: function<R(A..=
..)&&>.)
N4159 already explains this distinction, but the exposition might not be cl=
ear enough.
More depth is provided by the link at the end of the previous message. Most=
of the time, rvalue ref-qualification is going to be a bit obscure (as it =
always has been), and unique_function is what you=E2=80=99ll be looking for=
..
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_A998E045-A328-4515-9406-1FE7D7FE2831
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9306=
=E2=80=9325, at 3:03 PM, Arthur O'Dwyer <<a href=3D"mailto:arthur.j.odwy=
er@gmail.com" class=3D"">arthur.j.odwyer@gmail.com</a>> wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div class=3D"">David K=
rauss, as the author of N4543 (<font face=3D"courier new, monospace" class=
=3D"">std::unique_function<R(A...)></font>), do you think it's in any=
way <i class=3D"">preferable</i> to N4159 (<font face=3D"courier new, mono=
space" class=3D"">std::function<R(A...)&&></font>), as in,</d=
iv></div></blockquote><div><br class=3D""></div><div>I see the confusion no=
w. These are orthogonal problems:</div><div><br class=3D""></div><div>1. Ca=
n no more than one copy of the target exist? (Solution: <font face=3D"Couri=
er" class=3D"">unique_function</font>.) </div><div>2. Can a given copy=
be called not more than once? (Solution: <font face=3D"Courier" class=3D""=
>function<R(A...)&&></font>.)</div><div><br class=3D""></div>=
<div>N4159 already explains this distinction, but the exposition might not =
be clear enough.</div><div><br class=3D""></div><div>More depth is provided=
by the link at the end of the previous message. Most of the time, rvalue r=
ef-qualification is going to be a bit obscure (as it always has been), and =
<font face=3D"Courier" class=3D"">unique_function</font> is what you=E2=80=
=99ll be looking for.</div></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_A998E045-A328-4515-9406-1FE7D7FE2831--
.
Author: "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com>
Date: Thu, 25 Jun 2015 00:53:00 -0700
Raw View
On Thu, Jun 25, 2015 at 12:36 AM, David Krauss <david_work@me.com> wrote:
> On 2015=E2=80=9306=E2=80=9325, at 3:03 PM, Arthur O'Dwyer <arthur.j.odwye=
r@gmail.com> wrote:
>>
>> N4159 strikes me as exactly the reasonable and sensible thing to do (bot=
h to
>> fix the thread-safety/const-correctness issue, and to enable
>> std::function-izing of move-only lambdas); can anyone shed some light on=
its
>> current disposition?
>
> N4159 was accepted as a good to-do list. N4348 and N4543 are follow-ups.
>
>> David Krauss, as the author of N4543 (std::unique_function<R(A...)>), do=
you
>> think it's in any way preferable to N4159 (std::function<R(A...)&&>), as=
in,
>> - is there a good reason to reject N4159?
>> - if N4159 were adopted, would there still be a good reason to adopt N45=
43?
>
> Some cognitive dissonance here. How have I contradicted N4159?
Aha, you merely contradicted my misreading of N4159! Basically, I
misinterpreted the && qualifier on N4159's std::function<R(A...)&&> as
meaning "move-only", when really N4159 intends it to be read literally
as "calling operator()&& on the wrapped object" and not saying
anything about the copyability of the wrapped object.
Page 11 of N4159 even says "Of course, we cannot specify copyability
in such a way, so we still need a parameter for that (or, perhaps, two
separate templates)." I just completely skipped over that in my
misreading. :P
> If you want to allow non-copyable targets, there are only two choices: 1.
> Let std::function accept them and define its copy constructor to throw (o=
r
> UB), or 2. Create a new, non-copyable polymorphic wrapper.
Or #3 (my misreading) assume that nobody would ever want to literally
"call operator()&& on the wrapped object" and therefore it's safe to
co-opt that qualifier to mean "move-only".
Your prototype library's documentation covers this misconception in
one sentence:
> Note that copyability is different from an rvalue-qualified (&&) signatur=
e.
True dat.
Thanks for the reply and for the info on N4159/N4348/N4543's current
disposition,
=E2=80=93Arthur
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.