Topic: introduce: not_fn to complete set of standardized functors.
Author: anna.salwa.05@gmail.com
Date: Sun, 19 May 2013 10:02:46 -0700 (PDT)
Raw View
------=_Part_193_20731286.1368982966403
Content-Type: text/plain; charset=ISO-8859-1
Is there interest to add to C++14 generalization of not1, not2 library
functions that can be used with C++11 mem_fn and bind and C++14 plimorphic
operators wrappers<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3421.htm>.
This would complete the set of new standarized functors
template<class F> unspecified not_fn(F&&);
Returns: A simple call wrapper fn such that the expression fn(t, a2, ...,
aN) is equivalent to !INVOKE (pm, t, a2, ..., aN).
The main advantage of this function over hand-written labmda is that it
will support any callable type (functors, functions, pointer to members)
with the same syntax. The old negators should be deprecated.
--
---
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/?hl=en.
------=_Part_193_20731286.1368982966403
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Is there interest to add to C++14 generalization of not1, not2 library func=
tions that can be used with C++11 mem_fn and bind and <a href=3D"http://www=
..open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3421.htm">C++14 plimorphic o=
perators wrappers</a>. This would complete the set of new standarized funct=
ors<br><br>template<class F> unspecified not_fn(F&&);<br>Retu=
rns: A simple call wrapper fn such that the expression fn(t, a2, ...,=
aN) is equivalent to !INVOKE (pm, t, a2, ..., aN).<br><br>The main advanta=
ge of this function over hand-written labmda is that it will support any ca=
llable type (functors, functions, pointer to members) with the same syntax.=
The old negators should be deprecated.<br>
<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_193_20731286.1368982966403--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 19 May 2013 10:27:22 -0700 (PDT)
Raw View
------=_Part_2414_25894753.1368984442547
Content-Type: text/plain; charset=ISO-8859-1
On Sunday, May 19, 2013 10:02:46 AM UTC-7, anna.s...@gmail.com wrote:
>
> Is there interest to add to C++14 generalization of not1, not2 library
> functions that can be used with C++11 mem_fn and bind and C++14
> plimorphic operators wrappers<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3421.htm>.
> This would complete the set of new standarized functors
>
> template<class F> unspecified not_fn(F&&);
> Returns: A simple call wrapper fn such that the expression fn(t, a2, ...,
> aN) is equivalent to !INVOKE (pm, t, a2, ..., aN).
>
> The main advantage of this function over hand-written labmda is that it
> will support any callable type (functors, functions, pointer to members)
> with the same syntax. The old negators should be deprecated.
>
I'm fairly sure C++14 is closed for new stuff, but you can submit a
proposal on this if you like. It could still make it into a companion
library TS.
--
---
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/?hl=en.
------=_Part_2414_25894753.1368984442547
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Sunday, May 19, 2013 10:02:46 AM UTC-7, anna.s...@gmail.com wrote:<block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;">Is there interest to add to C++14 ge=
neralization of not1, not2 library functions that can be used with C++11 me=
m_fn and bind and <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/pa=
pers/2012/n3421.htm" target=3D"_blank">C++14 plimorphic operators wrappers<=
/a>. This would complete the set of new standarized functors<br><br>templat=
e<class F> unspecified not_fn(F&&);<br>Returns: A simple call=
wrapper fn such that the expression fn(t, a2, ..., aN) is equivalent=
to !INVOKE (pm, t, a2, ..., aN).<br><br>The main advantage of this functio=
n over hand-written labmda is that it will support any callable type (funct=
ors, functions, pointer to members) with the same syntax. The old negators =
should be deprecated.<br></blockquote><div><br>I'm fairly sure C++14 is clo=
sed for new stuff, but you can submit a proposal on this if you like. It co=
uld still make it into a companion library TS. <br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_2414_25894753.1368984442547--
.
Author: Jonathan Wakely <cxx@kayari.org>
Date: Mon, 20 May 2013 04:21:55 -0700 (PDT)
Raw View
------=_Part_973_1153903.1369048915921
Content-Type: text/plain; charset=ISO-8859-1
I'm definitely intersted, I've been thinking about the same thing after a
user reported a bug against GCC's not1().
At first I was thinking we should just fix unary_negate<T> to stop relying
on the presence of the argument_type typedef, or use the N3421 trick to
make unary_negate<void> do the right thing, but as with the mem_fun() to
mem_fn() shift we should support arbitrary functors, so I came up with this
(updated to use your not_fn name, which I prefer):
#include <functional>
template<typename Fn>
struct not_fn_type
{
Fn fn;
template<typename... Args>
auto
operator()(Args&&... args)
noexcept(noexcept(!std::forward<Fn>(fn)(std::forward<Args>(args)...)))
-> decltype(!std::forward<Fn>(fn)(std::forward<Args>(args)...))
{
return !std::forward<Fn>(fn)(std::forward<Args>(args)...);
}
};
template<typename Fn>
auto make_callable(Fn f) { return f; }
template<typename R, typename T>
auto make_callable(R T::* f) { return std::mem_fn(f); }
template<typename F>
auto
not_fn(F f)
{
auto fn = make_callable(f);
return not_fn_type<decltype(fn)>{fn};
}
I think the lack of this almost qualifies as a defect, as the existing
not1() and not2() functions are useless with most C++14 function objects
but there is no replacement.
--
---
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/?hl=en.
------=_Part_973_1153903.1369048915921
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
I'm definitely intersted, I've been thinking about the same thing after a u=
ser reported a bug against GCC's not1().<br><br>At first I was thinking we =
should just fix unary_negate<T> to stop relying on <iframe style=3D"p=
adding: 0px; position: absolute; top: 0px; left: 0px; width: 821px; height:=
200px; visibility: hidden;" frameborder=3D"0"></iframe> the presence of th=
e argument_type typedef, or use the N3421 trick to make unary_negate<voi=
d> do the right thing, but as with the mem_fun() to mem_fn() shift we sh=
ould support arbitrary functors, so I came up with this (updated to use you=
r not_fn name, which I prefer):<br><br>#include <functional><br><br>t=
emplate<typename Fn><br> struct not_fn_type<br> {<br>&nbs=
p; Fn fn;<br><br> template<typename... Arg=
s><br> auto<br> &nb=
sp; operator()(Args&&... args)<br> no=
except(noexcept(!std::forward<Fn>(fn)(std::forward<Args>(args).=
...)))<br> -> decltype(!std::forward<Fn&=
gt;(fn)(std::forward<Args>(args)...))<br> &nbs=
p; {<br> return !std::forward<=
Fn>(fn)(std::forward<Args>(args)...);<br> &=
nbsp; }<br> };<br><br>template<typename Fn><br> auto make=
_callable(Fn f) { return f; }<br><br>template<typename R, typename T>=
<br> auto make_callable(R T::* f) { return std::mem_fn(f); }<br><br>t=
emplate<typename F><br> auto<br> not_fn(F f)<br> {<=
br> auto fn =3D make_callable(f);<br> r=
eturn not_fn_type<decltype(fn)>{fn};<br> }<br><br>I think the l=
ack of this almost qualifies as a defect, as the existing not1() and not2()=
functions are useless with most C++14 function objects but there is no rep=
lacement.<br><br><br>
<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_973_1153903.1369048915921--
.
Author: Jonathan Wakely <cxx@kayari.org>
Date: Mon, 20 May 2013 04:35:11 -0700 (PDT)
Raw View
------=_Part_151_12551764.1369049711753
Content-Type: text/plain; charset=ISO-8859-1
P.S. if we just wanted to update not1 and not2 we could do this:
template<typename F>
auto not1(F f)
{
return std::bind(std::logical_not<>(), std::bind(f, std::placeholders::_1));
}
template<typename F>
auto not2(F f)
{
return std::bind(std::logical_not<>(), std::bind(f, std::placeholders::_1, std::placeholders:_2));
}
--
---
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/?hl=en.
------=_Part_151_12551764.1369049711753
Content-Type: text/html; charset=ISO-8859-1
P.S. if we just wanted to update not1 and not2 we could do this:<br><br><pre class="bz_comment_text" id="comment_text_4">template<typename F>
auto not1(F f)
{
return std::bind(std::logical_not<>(), std::bind(f, std::placeholders::_1));
}<br><br>template<typename F>
auto not2(F f)
{
return std::bind(std::logical_not<>(), std::bind(f, std::placeholders::_1, std::placeholders:_2));
}<br></pre><br>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
<br />
<br />
------=_Part_151_12551764.1369049711753--
.
Author: tomaszkam@gmail.com
Date: Wed, 22 May 2013 13:04:28 -0700 (PDT)
Raw View
------=_Part_621_32552275.1369253068475
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu niedziela, 19 maja 2013 19:02:46 UTC+2 u=BFytkownik=20
anna.s...@gmail.com napisa=B3:
>
> Is there interest to add to C++14 generalization of not1, not2 library=20
> functions that can be used with C++11 mem_fn and bind and C++14=20
> plimorphic operators wrappers<http://www.open-std.org/jtc1/sc22/wg21/docs=
/papers/2012/n3421.htm>.=20
> This would complete the set of new standarized functors
>
> template<class F> unspecified not_fn(F&&);
> Returns: A simple call wrapper fn such that the expression fn(t, a2, ...=
,=20
> aN) is equivalent to !INVOKE (pm, t, a2, ..., aN).
>
> The main advantage of this function over hand-written labmda is that it=
=20
> will support any callable type (functors, functions, pointer to members)=
=20
> with the same syntax. The old negators should be deprecated.
>
--=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/?hl=3Den.
------=_Part_621_32552275.1369253068475
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu niedziela, 19 maja 2013 19:02:46 UTC+2 u=BFytkownik anna.s..=
..@gmail.com napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Is there=
interest to add to C++14 generalization of not1, not2 library functions th=
at can be used with C++11 mem_fn and bind and <a href=3D"http://www.open-st=
d.org/jtc1/sc22/wg21/docs/papers/2012/n3421.htm" target=3D"_blank">C++14 pl=
imorphic operators wrappers</a>. This would complete the set of new standar=
ized functors<br><br>template<class F> unspecified not_fn(F&&=
);<br>Returns: A simple call wrapper fn such that the expression fn(t=
, a2, ..., aN) is equivalent to !INVOKE (pm, t, a2, ..., aN).<br><br>The ma=
in advantage of this function over hand-written labmda is that it will supp=
ort any callable type (functors, functions, pointer to members) with the sa=
me syntax. The old negators should be deprecated.<br></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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_621_32552275.1369253068475--
.
Author: tomaszkam@gmail.com
Date: Thu, 23 May 2013 22:07:41 -0700 (PDT)
Raw View
------=_Part_70_24323869.1369372061993
Content-Type: multipart/alternative;
boundary="----=_Part_71_17636648.1369372061993"
------=_Part_71_17636648.1369372061993
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
With the Anna's permission I prepared a proposal for that functionality,=20
which you may be found in attachment.=20
@Jonathan: could you provide my a link to gcc issue that you have mentioned=
?
W dniu niedziela, 19 maja 2013 19:02:46 UTC+2 u=BFytkownik=20
anna.s...@gmail.com napisa=B3:
>
> Is there interest to add to C++14 generalization of not1, not2 library=20
> functions that can be used with C++11 mem_fn and bind and C++14=20
> plimorphic operators wrappers<http://www.open-std.org/jtc1/sc22/wg21/docs=
/papers/2012/n3421.htm>.=20
> This would complete the set of new standarized functors
>
> template<class F> unspecified not_fn(F&&);
> Returns: A simple call wrapper fn such that the expression fn(t, a2, ...=
,=20
> aN) is equivalent to !INVOKE (pm, t, a2, ..., aN).
>
> The main advantage of this function over hand-written labmda is that it=
=20
> will support any callable type (functors, functions, pointer to members)=
=20
> with the same syntax. The old negators should be deprecated.
>
--=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/?hl=3Den.
------=_Part_71_17636648.1369372061993
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
With the Anna's permission I prepared a proposal for that functionality, wh=
ich you may be found in attachment. <br><br>@<span class=3D"_username"><spa=
n style=3D"color: rgb(34, 34, 34);" class=3D"GGVPNNKCOIB">Jonathan: </span>=
</span>could you provide my a link to gcc issue that you have mentioned?<br=
><br>W dniu niedziela, 19 maja 2013 19:02:46 UTC+2 u=BFytkownik anna.s...@g=
mail.com napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Is there in=
terest to add to C++14 generalization of not1, not2 library functions that =
can be used with C++11 mem_fn and bind and <a href=3D"http://www.open-std.o=
rg/jtc1/sc22/wg21/docs/papers/2012/n3421.htm" target=3D"_blank">C++14 plimo=
rphic operators wrappers</a>. This would complete the set of new standarize=
d functors<br><br>template<class F> unspecified not_fn(F&&);<=
br>Returns: A simple call wrapper fn such that the expression fn(t, a=
2, ..., aN) is equivalent to !INVOKE (pm, t, a2, ..., aN).<br><br>The main =
advantage of this function over hand-written labmda is that it will support=
any callable type (functors, functions, pointer to members) with the same =
syntax. The old negators should be deprecated.<br></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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_71_17636648.1369372061993--
------=_Part_70_24323869.1369372061993
Content-Type: text/html; charset=US-ASCII;
name="A proposal to add a generalized callable negator.html"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="A proposal to add a generalized callable negator.html"
X-Attachment-Id: c5974047-1db8-4024-9d3a-2b85470e376f
Content-ID: <c5974047-1db8-4024-9d3a-2b85470e376f>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<style type="text/css">
pre {margin-left:20pt; }
pre > i {
font-family: "OCR A Extended", "Consolas", "Lucida Console", monospace;
font-style:italic;
}
code > i {
font-family: "OCR A Extended", "Consolas", "Lucida Console", monospace;
font-style:italic;
}
pre > em {
font-family: "OCR A Extended", "Consolas", "Lucida Console", monospace;
font-style:italic;
}
code > em {
font-family: "OCR A Extended", "Consolas", "Lucida Console", monospace;
font-style:italic;
}
body { color: #000000; background-color: #FFFFFF; }
del { text-decoration: line-through; color: #8B0040; }
ins { text-decoration: underline; color: #005100; }
p.example { margin-left: 2em; }
pre.example { margin-left: 2em; }
div.example { margin-left: 2em; }
code.extract { background-color: #F5F6A2; }
pre.extract { margin-left: 2em; background-color: #F5F6A2;
border: 1px solid #E1E28E; }
p.function { }
..attribute { margin-left: 2em; }
..attribute dt { float: left; font-style: italic;
padding-right: 1ex; }
..attribute dd { margin-left: 0em; }
blockquote.std { color: #000000; background-color: #F1F1F1;
border: 1px solid #D1D1D1;
padding-left: 0.5em; padding-right: 0.5em; }
blockquote.stddel { text-decoration: line-through;
color: #000000; background-color: #FFEBFF;
border: 1px solid #ECD7EC;
padding-left: 0.5empadding-right: 0.5em; ; }
blockquote.stdins { text-decoration: underline;
color: #000000; background-color: #C8FFC8;
border: 1px solid #B3EBB3; padding: 0.5em; }
table { border: 1px solid black; border-spacing: 0px;
margin-left: auto; margin-right: auto; }
th { text-align: left; vertical-align: top;
padding-left: 0.4em; border: none;
padding-right: 0.4em; border: none; }
td { text-align: left; vertical-align: top;
padding-left: 0.4em; border: none;
padding-right: 0.4em; border: none; }
</style>
<title>A proposal to add a generalized callable negator</title>
<script type="text/javascript">$(function() {
var next_id = 0
function find_id(node) {
// Look down the first children of 'node' until we find one
// with an id. If we don't find one, give 'node' an id and
// return that.
var cur = node[0];
while (cur) {
if (cur.id) return curid;
if (cur.tagName == 'A' && cur.name)
return cur.name;
cur = cur.firstChild;
};
// No id.
node.attr('id', 'gensection-' + next_id++);
return node.attr('id');
};
// Put a table of contents in the #toc nav.
// This is a list of <ol> elements, where toc[N] is the list for
// the current sequence of <h(N+2)> tags. When a header of an
// existing level is encountered, all higher levels are popped,
// and an <li> is appended to the level
var toc = [$("<ol/>")];
$(':header').not('h1').each(function() {
var header = $(this);
// For each <hN> tag, add a link to the toc at the appropriate
// level. When toc is one element too short, start a new list
var levels = {H2: 0, H3: 1, H4: 2, H5: 3, H6: 4};
var level = levels[this.tagName];
if (typeof level == 'undefined') {
throw 'Unexpected tag: ' + this.tagName;
}
// Truncate to the new level.
toc.splice(level + 1, toc.length);
if (toc.length < level) {
// Omit TOC entries for skipped header levels.
return;
}
if (toc.length == level) {
// Add a <ol> to the previous level's last <li> and push
// it into the array.
var ol = $('<ol/>')
toc[toc.length - 1].children().last().append(ol);
toc.push(ol);
}
var header_text = header.text();
toc[toc.length - 1].append(
$('<li/>').append($('<a href="#' + find_id(header) + '"/>')
.text(header_text)));
});
$('#toc').append(toc[0]);
})
</script>
</head>
<body>
<h1><a name="title">A proposal to add a generalized callable negator</a></h1>
<!--p>
ISO/IEC JTC1 SC22 WG21 N?? 2013-04-19
</p-->
<address>
Tomasz Kamiński, tomaszkam@gmail.com
</address>
<h2><a name="intro">Introduction</a></h2>
<p>This proposal is to add function template <code>not_fn</code> that will allow to create negator of any callable.</p>
<!--h2><a name="toc">Table of contents</a></h2-->
<h2><a name="motivation">Motivation and Scope</a></h2>
<p>The standard negators <code>not1</code> and <code>not2</code> accept only unary and binary functors that define <code>argument_type</code> or <code>first_argument_type</code> and <code>second_argument_type</code> respectively, which make them unusable with results of standard library functions such as <code>bind</code> and <code>mem_fn</code>. Furthermore, with relation to N3421, they cannot be used with new operator functor specializations.</p>
<p>This proposal addresses the problem by introducing a template function <code>not_fn</code> that returns complement of arbitrary predicate.</p>
<h3><a name="motivation.lambda">Comparison with lambda</a></h3>
<p>While the polymorphic lambda expressions (<a href="http://isocpp.org/files/papers/N3649.html">N3649</a>) may be used to negate arbitrary functor, the proposed function offers more compact syntax:</p>
<pre>
std::partition(v.begin(), v.end(), [f](auto& p) { return !f(p); });
std::partition(v.begin(), v.end(), std::not_fn(f));
</pre>
<p>Furthermore, the use of lambda expression requires separate treatment of member pointers:</p>
<pre>
std::partition(v.begin(), v.end(), [pm](auto& p) { return !std::mem_fn(pm)(p); });
std::partition(v.begin(), v.end(), std::not_fn(pm));
</pre>
<h3><a name="motivation.depraction">Deprecation</a></h3>
<p>With the incorporation of proposed functionality the old standard negators should be deprecated.</p>
<h2><a name="design">Design Decisions</a></h2>
<h3><a name="design.specializations">New specializations of <code>unary_negate</code>, <code>binary_negate</code></a></h3>
<p>Problem addressed by this paper may be solved by introducing perfect forwarding specializations of <code>unary_negate</code>, <code>binary_negate</code> for types that do not define <code>argument_type</code> and <code>first_argument_type</code>, <code>second_argument_type</code> nested types, respectively, without breaking existing code. Although this solution does not address functions with arbitrary number of arguments and requires additional implementation burden.</p>
<h3><a name="design.return">Return type</a></h3>
<p>The perfect forwarding of return type was chosen instead of hard-coded <code>bool</code>. Similar argumentation to the one provided in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3421.htm">N3421</a> applies.</p>
<h2><a name="standard">Impact On The Standard</a></h2>
<p>This proposal has no dependencies beyond a C++11 compiler and Standard Library implementation. (It depends on perfect forwarding, <code>decltype</code> and trailing return types.)</p>
<p>Nothing depends on this proposal.</p>
<h2><a name="wording">Proposed wording</a></h2>
<p>After paragraph 20.8.8 Negators [negators], insert a new paragraph. (Chapter [bind] (Function template <code>bind</code>) becomes 20.8.10)</p>
<blockquote class="std">
<h4><a name="optional.general">20.8.9 Function template <code>not_fn</code> <span style="float:right">[not_fn]</span></a></h4>
<pre>
template <class F>
<em>unspecified</em> not_fn(F f);
</pre>
<dl class="attribute">
<dt>Requires:</dt> <dd><p><code>F</code> shall be <code>CopyConstructible</code>. <code>f</code> shall be <code>Callable</code> (20.8.11.2).</p></dd>
<dt>Returns:</dt> <dd><p>A simple call wrapper <code>fn</code> such that the expression <code>fn(a1, a2, ..., aN)</code> is equivalent to <code>!INVOKE(f, a1, a2, ..., aN)</code> (20.8.2).</p>
<dd><p>If the forwarding call wrapper with a weak result type (20.8.2) for <code>f</code> would have a nested type <code>result_type</code> that is a synonym to <code>R</code>, then the simple call wrapper shall have a nested type <code>result_type</code> that is a synonym to <code>decltype(!std::declval<R>())</code>.</p></dd>
</dl>
</blockquote>
<h2><a name="acknowledgements">Acknowledgements</a></h2>
<p>Anna Salwa who originally proposed <code>not_fn</code> in discussion group "ISO C++ Standard - Future Proposals".</p>
<h2><a name="literature">References</a></h2>
<ol>
<li>Stephan T. Lavavej, "Making Operator Functors greater<>" (N3421, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3421.htm">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3421.htm</a>)</li>
<li>Faisal Vali, Herb Sutter, Dave Abrahams, "Generic (Polymorphic) Lambda Expressions (Revision 3) " (<a href="https://github.com/akrzemi1/Optional/">https://github.com/akrzemi1/Optional/</a>)</li>
</ol>
</body></html>
------=_Part_70_24323869.1369372061993--
.
Author: Jonathan Wakely <cxx@kayari.org>
Date: Fri, 24 May 2013 07:54:16 -0700 (PDT)
Raw View
------=_Part_517_18365391.1369407256914
Content-Type: text/plain; charset=ISO-8859-1
On Friday, May 24, 2013 6:07:41 AM UTC+1, toma...@gmail.com wrote:
>
> With the Anna's permission I prepared a proposal for that functionality,
> which you may be found in attachment.
>
>
Thanks for writing up the proposal.
I don't like the wording for the result_type requirement, I think it would
be made a bit better by saying "If <INS>a</INS><DEL>the</DEL> forwarding
...." and "a synonym <INS>for</INS><DEL>of</DEL>" but I think there's still
room for improvement.
The section numbers in the C++14 CD are different, you might want to use
([func.require] 20.10.2) instead of just (20.8.2) as this tells the editor
exactly which section the reference is to without having to look up the
numbers.
> @Jonathan: could you provide my a link to gcc issue that you have
> mentioned?
>
It's http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57283
--
---
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/?hl=en.
------=_Part_517_18365391.1369407256914
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Friday, May 24, 2013 6:07:41 AM UTC+1, toma...@gmail.com wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
1px #ccc solid;padding-left: 1ex;">With the Anna's permission I prepared a=
proposal for that functionality, which you may be found in attachment. <br=
><br></blockquote><div><br>Thanks for writing up the proposal.<br><br>I don=
't like the wording for the result_type requirement, I think it would be ma=
de a bit better by saying "If <INS>a</INS><DEL>the</DE=
L> forwarding ..." and "a synonym <INS>for</INS><DEL>o=
f</DEL>" but I think there's still room for improvement.<br><br>The s=
ection numbers in the C++14 CD are different, you might want to use ([func.=
require] 20.10.2) instead of just (20.8.2) as this tells the editor exactly=
which section the reference is to without having to look up the numbers.<b=
r><br> </div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">@<span><span=
style=3D"color:rgb(34,34,34)">Jonathan: </span></span>could you provide my=
a link to gcc issue that you have mentioned?<br></blockquote><div><br>It's=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D57283</div><br>
<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_517_18365391.1369407256914--
.
Author: tomaszkam@gmail.com
Date: Fri, 24 May 2013 11:46:28 -0700 (PDT)
Raw View
------=_Part_650_14710896.1369421188046
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
I have changed a numbers reference numbers to this used inc C++14 CD=20
(N3690) and put section names in additions. Also I changed the wording for=
=20
a result_type a bit.
Do you think that I should add requirements for argument_type,=20
first_argument_type, second_argument_type nested types in similar way at it=
=20
is done for reference wrapper ([refwrap] 20.10.3)?
W dniu pi=B1tek, 24 maja 2013 16:54:16 UTC+2 u=BFytkownik Jonathan Wakely=
=20
napisa=B3:
>
> On Friday, May 24, 2013 6:07:41 AM UTC+1, toma...@gmail.com wrote:
>>
>> With the Anna's permission I prepared a proposal for that functionality,=
=20
>> which you may be found in attachment.=20
>>
>>
> Thanks for writing up the proposal.
>
> I don't like the wording for the result_type requirement, I think it woul=
d=20
> be made a bit better by saying "If <INS>a</INS><DEL>the</DEL> forwarding=
=20
> ..." and "a synonym <INS>for</INS><DEL>of</DEL>" but I think there's stil=
l=20
> room for improvement.
>
> The section numbers in the C++14 CD are different, you might want to use=
=20
> ([func.require] 20.10.2) instead of just (20.8.2) as this tells the edito=
r=20
> exactly which section the reference is to without having to look up the=
=20
> numbers.
>
> =20
>
>> @Jonathan: could you provide my a link to gcc issue that you have=20
>> mentioned?
>>
>
> It's http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D57283
>
>
--=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/?hl=3Den.
------=_Part_650_14710896.1369421188046
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
I have changed a numbers reference numbers to this used inc C++14 CD (N3690=
) and put section names in additions. Also I changed the wording for a resu=
lt_type a bit.<br><br>Do you think that I should add requirements for argum=
ent_type, first_argument_type, second_argument_type nested types in similar=
way at it is done for reference wrapper ([refwrap] 20.10.3)?<br><br>W dniu=
pi=B1tek, 24 maja 2013 16:54:16 UTC+2 u=BFytkownik Jonathan Wakely napisa=
=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">On Friday, May 24, 2013 6:=
07:41 AM UTC+1, <a>toma...@gmail.com</a> wrote:<blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex">With the Anna's permission I prepared a proposal for that funct=
ionality, which you may be found in attachment. <br><br></blockquote><div><=
br>Thanks for writing up the proposal.<br><br>I don't like the wording for =
the result_type requirement, I think it would be made a bit better by sayin=
g "If <INS>a</INS><DEL>the</DEL> forwarding ..." an=
d "a synonym <INS>for</INS><DEL>of</DEL>" but I thi=
nk there's still room for improvement.<br><br>The section numbers in the C+=
+14 CD are different, you might want to use ([func.require] 20.10.2) instea=
d of just (20.8.2) as this tells the editor exactly which section the refer=
ence is to without having to look up the numbers.<br><br> </div><block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex">@<span><span style=3D"color:rgb(34,34,34)=
">Jonathan: </span></span>could you provide my a link to gcc issue that you=
have mentioned?<br></blockquote><div><br>It's <a href=3D"http://gcc.gnu.or=
g/bugzilla/show_bug.cgi?id=3D57283" target=3D"_blank">http://gcc.gnu.org/bu=
gzilla/<wbr>show_bug.cgi?id=3D57283</a></div><br></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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_650_14710896.1369421188046--
.
Author: tomaszkam@gmail.com
Date: Fri, 24 May 2013 11:47:26 -0700 (PDT)
Raw View
------=_Part_650_19214384.1369421246602
Content-Type: multipart/alternative;
boundary="----=_Part_651_8302934.1369421246602"
------=_Part_651_8302934.1369421246602
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
I have changed a numbers reference numbers to this used inc C++14 CD=20
(N3690) and put section names in additions. Also I changed the wording for=
=20
a result_type a bit.
Do you think that I should add requirements for argument_type,=20
first_argument_type, second_argument_type nested types in similar way at it=
=20
is done for reference wrapper ([refwrap] 20.10.3)?
W dniu pi=B1tek, 24 maja 2013 16:54:16 UTC+2 u=BFytkownik Jonathan Wakely=
=20
napisa=B3:
>
> On Friday, May 24, 2013 6:07:41 AM UTC+1, toma...@gmail.com wrote:
>>
>> With the Anna's permission I prepared a proposal for that functionality,=
=20
>> which you may be found in attachment.=20
>>
>>
> Thanks for writing up the proposal.
>
> I don't like the wording for the result_type requirement, I think it woul=
d=20
> be made a bit better by saying "If <INS>a</INS><DEL>the</DEL> forwarding=
=20
> ..." and "a synonym <INS>for</INS><DEL>of</DEL>" but I think there's stil=
l=20
> room for improvement.
>
> The section numbers in the C++14 CD are different, you might want to use=
=20
> ([func.require] 20.10.2) instead of just (20.8.2) as this tells the edito=
r=20
> exactly which section the reference is to without having to look up the=
=20
> numbers.
>
> =20
>
>> @Jonathan: could you provide my a link to gcc issue that you have=20
>> mentioned?
>>
>
> It's http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D57283
>
>
--=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/?hl=3Den.
------=_Part_651_8302934.1369421246602
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
I have changed a numbers reference numbers to this used inc C++14 CD=20
(N3690) and put section names in additions. Also I changed the wording=20
for a result_type a bit.<br><br>Do you think that I should add=20
requirements for argument_type, first_argument_type,=20
second_argument_type nested types in similar way at it is done for=20
reference wrapper ([refwrap] 20.10.3)?<br><br>W dniu pi=B1tek, 24 maja 2013=
16:54:16 UTC+2 u=BFytkownik Jonathan Wakely napisa=B3:<blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;">On Friday, May 24, 2013 6:07:41 AM UTC+1, <a>toma.=
...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;=
margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">With the Ann=
a's permission I prepared a proposal for that functionality, which you may =
be found in attachment. <br><br></blockquote><div><br>Thanks for writing up=
the proposal.<br><br>I don't like the wording for the result_type requirem=
ent, I think it would be made a bit better by saying "If <INS>a</I=
NS><DEL>the</DEL> forwarding ..." and "a synonym <INS>=
for</INS><DEL>of</DEL>" but I think there's still room fo=
r improvement.<br><br>The section numbers in the C++14 CD are different, yo=
u might want to use ([func.require] 20.10.2) instead of just (20.8.2) as th=
is tells the editor exactly which section the reference is to without havin=
g to look up the numbers.<br><br> </div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex">@<span><span style=3D"color:rgb(34,34,34)">Jonathan: </span></spa=
n>could you provide my a link to gcc issue that you have mentioned?<br></bl=
ockquote><div><br>It's <a href=3D"http://gcc.gnu.org/bugzilla/show_bug.cgi?=
id=3D57283" target=3D"_blank">http://gcc.gnu.org/bugzilla/<wbr>show_bug.cgi=
?id=3D57283</a></div><br></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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_651_8302934.1369421246602--
------=_Part_650_19214384.1369421246602
Content-Type: text/html; charset=US-ASCII;
name="A proposal to add a generalized callable negator.html"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="A proposal to add a generalized callable negator.html"
X-Attachment-Id: 9a771e14-0785-48f0-8a47-f163419b80d0
Content-ID: <9a771e14-0785-48f0-8a47-f163419b80d0>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<style type="text/css">
pre {margin-left:20pt; }
pre > i {
font-family: "OCR A Extended", "Consolas", "Lucida Console", monospace;
font-style:italic;
}
code > i {
font-family: "OCR A Extended", "Consolas", "Lucida Console", monospace;
font-style:italic;
}
pre > em {
font-family: "OCR A Extended", "Consolas", "Lucida Console", monospace;
font-style:italic;
}
code > em {
font-family: "OCR A Extended", "Consolas", "Lucida Console", monospace;
font-style:italic;
}
body { color: #000000; background-color: #FFFFFF; }
del { text-decoration: line-through; color: #8B0040; }
ins { text-decoration: underline; color: #005100; }
p.example { margin-left: 2em; }
pre.example { margin-left: 2em; }
div.example { margin-left: 2em; }
code.extract { background-color: #F5F6A2; }
pre.extract { margin-left: 2em; background-color: #F5F6A2;
border: 1px solid #E1E28E; }
p.function { }
..attribute { margin-left: 2em; }
..attribute dt { float: left; font-style: italic;
padding-right: 1ex; }
..attribute dd { margin-left: 0em; }
blockquote.std { color: #000000; background-color: #F1F1F1;
border: 1px solid #D1D1D1;
padding-left: 0.5em; padding-right: 0.5em; }
blockquote.stddel { text-decoration: line-through;
color: #000000; background-color: #FFEBFF;
border: 1px solid #ECD7EC;
padding-left: 0.5empadding-right: 0.5em; ; }
blockquote.stdins { text-decoration: underline;
color: #000000; background-color: #C8FFC8;
border: 1px solid #B3EBB3; padding: 0.5em; }
table { border: 1px solid black; border-spacing: 0px;
margin-left: auto; margin-right: auto; }
th { text-align: left; vertical-align: top;
padding-left: 0.4em; border: none;
padding-right: 0.4em; border: none; }
td { text-align: left; vertical-align: top;
padding-left: 0.4em; border: none;
padding-right: 0.4em; border: none; }
</style>
<title>A proposal to add a generalized callable negator</title>
<script type="text/javascript">$(function() {
var next_id = 0
function find_id(node) {
// Look down the first children of 'node' until we find one
// with an id. If we don't find one, give 'node' an id and
// return that.
var cur = node[0];
while (cur) {
if (cur.id) return curid;
if (cur.tagName == 'A' && cur.name)
return cur.name;
cur = cur.firstChild;
};
// No id.
node.attr('id', 'gensection-' + next_id++);
return node.attr('id');
};
// Put a table of contents in the #toc nav.
// This is a list of <ol> elements, where toc[N] is the list for
// the current sequence of <h(N+2)> tags. When a header of an
// existing level is encountered, all higher levels are popped,
// and an <li> is appended to the level
var toc = [$("<ol/>")];
$(':header').not('h1').each(function() {
var header = $(this);
// For each <hN> tag, add a link to the toc at the appropriate
// level. When toc is one element too short, start a new list
var levels = {H2: 0, H3: 1, H4: 2, H5: 3, H6: 4};
var level = levels[this.tagName];
if (typeof level == 'undefined') {
throw 'Unexpected tag: ' + this.tagName;
}
// Truncate to the new level.
toc.splice(level + 1, toc.length);
if (toc.length < level) {
// Omit TOC entries for skipped header levels.
return;
}
if (toc.length == level) {
// Add a <ol> to the previous level's last <li> and push
// it into the array.
var ol = $('<ol/>')
toc[toc.length - 1].children().last().append(ol);
toc.push(ol);
}
var header_text = header.text();
toc[toc.length - 1].append(
$('<li/>').append($('<a href="#' + find_id(header) + '"/>')
.text(header_text)));
});
$('#toc').append(toc[0]);
})
</script>
</head>
<body>
<h1><a name="title">A proposal to add a generalized callable negator</a></h1>
<!--p>
ISO/IEC JTC1 SC22 WG21 N?? 2013-04-19
</p-->
<address>
Tomasz Kamiński, tomaszkam@gmail.com
</address>
<h2><a name="intro">Introduction</a></h2>
<p>This proposal is to add function template <code>not_fn</code> that will allow to create negator of any callable.</p>
<!--h2><a name="toc">Table of contents</a></h2-->
<h2><a name="motivation">Motivation and Scope</a></h2>
<p>The standard negators <code>not1</code> and <code>not2</code> accept only unary and binary functors that define <code>argument_type</code> or <code>first_argument_type</code> and <code>second_argument_type</code> respectively, which make them unusable with results of standard library functions such as <code>bind</code> and <code>mem_fn</code>. Furthermore, with relation to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3421.htm">N3421</a>, they cannot be used with new operator functor specializations.</p>
<p>This proposal addresses the problem by introducing a template function <code>not_fn</code> that returns complement of arbitrary predicate.</p>
<h3><a name="motivation.lambda">Comparison with lambda</a></h3>
<p>While the polymorphic lambda expressions (<a href="http://isocpp.org/files/papers/N3649.html">N3649</a>) may be used to negate arbitrary functor, the proposed function offers more compact syntax:</p>
<pre>
std::partition(v.begin(), v.end(), [f](auto& p) { return !f(p); });
std::partition(v.begin(), v.end(), std::not_fn(f));
</pre>
<p>Furthermore, the use of lambda expression requires separate treatment of member pointers:</p>
<pre>
std::partition(v.begin(), v.end(), [pm](auto& p) { return !std::mem_fn(pm)(p); });
std::partition(v.begin(), v.end(), std::not_fn(pm));
</pre>
<h3><a name="motivation.depraction">Deprecation</a></h3>
<p>With the incorporation of proposed functionality the old standard negators should be deprecated.</p>
<h2><a name="design">Design Decisions</a></h2>
<h3><a name="design.specializations">New specializations of <code>unary_negate</code>, <code>binary_negate</code></a></h3>
<p>Problem addressed by this paper may be solved by introducing perfect forwarding specializations of <code>unary_negate</code>, <code>binary_negate</code> for types that do not define <code>argument_type</code> and <code>first_argument_type</code>, <code>second_argument_type</code> nested types, respectively, without breaking existing code. Although this solution does not address functions with arbitrary number of arguments and requires additional implementation burden.</p>
<h3><a name="design.return">Return type</a></h3>
<p>The perfect forwarding of return type was chosen instead of hard-coded <code>bool</code>. Similar argumentation to the one provided in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3421.htm">N3421</a> applies.</p>
<h2><a name="standard">Impact On The Standard</a></h2>
<p>This proposal has no dependencies beyond a C++11 compiler and Standard Library implementation. (It depends on perfect forwarding, <code>decltype</code> and trailing return types.)</p>
<p>Nothing depends on this proposal.</p>
<h2><a name="wording">Proposed wording</a></h2>
<p>After paragraph 20.10.8 Negators [negators], insert a new paragraph. (Chapter [bind] (Function template <code>bind</code>) becomes 20.10.10)</p>
<blockquote class="std">
<h4><a name="optional.general">20.10.9 Function template <code>not_fn</code> <span style="float:right">[not_fn]</span></a></h4>
<pre>
template <class F>
<em>unspecified</em> not_fn(F f);
</pre>
<dl class="attribute">
<dt>Requires:</dt> <dd><p><code>F</code> shall be <code>CopyConstructible</code>. <code>f</code> shall be <code>Callable</code> ([func.require] 20.10.2).</p></dd>
<dt>Returns:</dt> <dd><p>A simple call wrapper <code>fn</code> such that the expression <code>fn(a1, a2, ..., aN)</code> is equivalent to <code>!INVOKE(f, a1, a2, ..., aN)</code> ([func.require] 20.10.2).</p>
<dd><p>The simple call wrapper <code>fn</code> should define a nested type <code>result_type</code> only if the the forwarding call wrapper <code>fw</code> with a weak result type ([func.require] 20.10.2) whould have a nested nested type <code>result_type</code>. The <code>result_type</code> definied in <code>fn</code> should be synonim to <code>decltype(!std::declval<R>())</code>, where <code>R</code> is synonim to <code>result_type</code> definied in <code>fw</code>.</p></dd>
</dl>
</blockquote>
<h2><a name="acknowledgements">Acknowledgements</a></h2>
<p>Anna Salwa who originally proposed <code>not_fn</code> in discussion group "ISO C++ Standard - Future Proposals".</p>
<p>Jonathan Wakely and Mateusz Kwiatkowski offered many useful suggestions and corrections to the proposal.</p>
<h2><a name="literature">References</a></h2>
<ol>
<li>Stephan T. Lavavej, "Making Operator Functors greater<>" (N3421, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3421.htm">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3421.htm</a>)</li>
<li>Faisal Vali, Herb Sutter, Dave Abrahams, "Generic (Polymorphic) Lambda Expressions (Revision 3) " (<a href="https://github.com/akrzemi1/Optional/">https://github.com/akrzemi1/Optional/</a>)</li>
</ol>
</body></html>
------=_Part_650_19214384.1369421246602--
.