--089e0129526aa0ac2304dd24d08d
Content-Type: text/plain; charset=ISO-8859-1

On 20 May 2013 14:21, Jonathan Wakely <cxx@kayari.org> wrote:

> 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)...);
>       }
>   };
>
>
I would expect that with c++14 you no longer need that late-specified
return type,
since we have deduction for it. Now we just need to add noexcept(auto).

--

---
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.



--089e0129526aa0ac2304dd24d08d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 20 May 2013 14:21, Jonathan Wakely <span dir=3D"ltr">&lt;<a href=
=3D"mailto:cxx@kayari.org" target=3D"_blank">cxx@kayari.org</a>&gt;</span> =
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">I&#39;m definitely intersted, I&#39;ve been =
thinking about the same thing after a user reported a bug against GCC&#39;s=
 not1().<br>
<br>At first I was thinking we should just fix unary_negate&lt;T&gt; to sto=
p relying on  the presence of the argument_type typedef, or use the N3421 t=
rick to make unary_negate&lt;void&gt; do the right thing, but as with the m=
em_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):<br>
<br>#include &lt;functional&gt;<br><br>template&lt;typename Fn&gt;<br>=A0 s=
truct not_fn_type<br>=A0 {<br>=A0=A0=A0 Fn fn;<br><br>=A0=A0=A0 template&lt=
;typename... Args&gt;<br>=A0=A0=A0=A0=A0 auto<br>=A0=A0=A0=A0=A0 operator()=
(Args&amp;&amp;... args)<br>=A0=A0=A0=A0=A0 noexcept(noexcept(!std::forward=
&lt;Fn&gt;(fn)(std::forward&lt;Args&gt;(args)...)))<br>
=A0=A0=A0=A0=A0 -&gt; decltype(!std::forward&lt;Fn&gt;(fn)(std::forward&lt;=
Args&gt;(args)...))<br>=A0=A0=A0=A0=A0 {<br>=A0=A0=A0=A0=A0=A0=A0 return !s=
td::forward&lt;Fn&gt;(fn)(std::forward&lt;Args&gt;(args)...);<br>=A0=A0=A0=
=A0=A0 }<br>=A0 };<br><br></blockquote><div>
<br></div><div>I would expect that with c++14 you no longer need that late-=
specified return type,<br>since we have deduction for it. Now we just need =
to add noexcept(auto). <br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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 />
&nbsp;<br />
&nbsp;<br />

--089e0129526aa0ac2304dd24d08d--

.

------=_Part_1035_16068854.1369050862453
Content-Type: text/plain; charset=ISO-8859-1



On Monday, May 20, 2013 12:41:35 PM UTC+1, Ville Voutilainen wrote:
>
>
> I would expect that with c++14 you no longer need that late-specified
> return type,
> since we have deduction for it. Now we just need to add noexcept(auto).
>

It's not needed (unless you want SFINAE to make the not_fn_type
not-callable) but my real code is a C++11 implementation, so also has a
return type on the make_callable and not_fn functions too.


--

---
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_1035_16068854.1369050862453
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Monday, May 20, 2013 12:41:35 PM UTC+1, Ville Voutilainen wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><div><div=
 class=3D"gmail_quote">I would expect that with c++14 you no longer need th=
at late-specified return type,<br><div>since we have deduction for it. Now =
we just need to add noexcept(auto). <br></div></div></div></div></blockquot=
e><div><br>It's not needed (unless you want SFINAE to make the not_fn_type =
not-callable) but my real code is a C++11 implementation, so also has a ret=
urn type on the make_callable and not_fn functions too.<br>&nbsp;<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_1035_16068854.1369050862453--

.

2013/5/24  <tomaszkam@gmail.com>:
> 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
> result_type a bit.

The term "Callable" is tricky. Without any qualification it would
refer to [func.wrap.func] and would need further "annotations" such as
"for argument types ArgTypes and return type R", which are not
available at this point. Maybe you want to say:

"f shall be a callable object ([func.require] 20.10.2)."

?

There are also some typos in regard to "synonim", "whould", and "definied".

Please don't say what the new paragraph number *will* be (such as
20.10.9), better say "20.10.?", nor how other paragraphs would change
(such as "(Function template bind) becomes 20.10.10"), because that
will anyway change according to the editors discretion and it is an
automatic result of the LaTeX processing, so is not helpful.

When you say "should define" this has a special meaning in a standard
and means that an implementation can decide that as they like. If they
don't like it, they don't add this - is that intended? (I doubt). You
need to say "shall define" instead to impose the requirement for
adding the member type. It would probably more helpful (and shorter)
to say instead:

"Returns: A simple call wrapper fn <ins>with a weak result type
(20.10.2)</ins> [..]"

Now everything is clear, because 20.10.2 imposes the necessary
requirements an implementations has to realize, and you don't need the
sentence "The simple call wrapper fn should define [..]".

> Do you think that I should add requirements for argument_type,
> first_argument_type, second_argument_type nested types in similar way at it
> is done for reference wrapper ([refwrap] 20.10.3)?

My understanding is that not_fn is very similar to bind (without
arguments), so I would not suggest these types.

- Daniel

--

---
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_371_1395477.1369428190817
Content-Type: multipart/alternative;
 boundary="----=_Part_372_32791302.1369428190817"

------=_Part_372_32791302.1369428190817
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



W dniu pi=B1tek, 24 maja 2013 21:28:00 UTC+2 u=BFytkownik Daniel Kr=FCgler=
=20
napisa=B3:
>
> 2013/5/24  <toma...@gmail.com <javascript:>>:=20
> > I have changed a numbers reference numbers to this used inc C++14 CD=20
> (N3690)=20
> > and put section names in additions. Also I changed the wording for a=20
> > result_type a bit.=20
>
> The term "Callable" is tricky. Without any qualification it would=20
> refer to [func.wrap.func] and would need further "annotations" such as=20
> "for argument types ArgTypes and return type R", which are not=20
> available at this point. Maybe you want to say:=20
>
> "f shall be a callable object ([func.require] 20.10.2)."=20
>
> ?=20
>
> There are also some typos in regard to "synonim", "whould", and=20
> "definied".=20
>
> Please don't say what the new paragraph number *will* be (such as=20
> 20.10.9), better say "20.10.?", nor how other paragraphs would change=20
> (such as "(Function template bind) becomes 20.10.10"), because that=20
> will anyway change according to the editors discretion and it is an=20
> automatic result of the LaTeX processing, so is not helpful.=20
>
> When you say "should define" this has a special meaning in a standard=20
> and means that an implementation can decide that as they like. If they=20
> don't like it, they don't add this - is that intended? (I doubt). You=20
> need to say "shall define" instead to impose the requirement for=20
> adding the member type. It would probably more helpful (and shorter)=20
> to say instead:=20
>
> Thank you for you suggestions, I changed the proposal accordingly.
=20

> "Returns: A simple call wrapper fn <ins>with a weak result type=20
> (20.10.2)</ins> [..]"=20
>
> Now everything is clear, because 20.10.2 imposes the necessary=20
> requirements an implementations has to realize, and you don't need the=20
> sentence "The simple call wrapper fn should define [..]".=20
>
> I think it won't work of not_fn, because I want to define result_type for=
=20
negator in the means of result_type (decltype(!declval<result_type>()) of=
=20
call wrapper with weak result type instead of just forwarding definition.=
=20
For most cases the type will be the same, but it can change.
=20

> > Do you think that I should add requirements for argument_type,=20
> > first_argument_type, second_argument_type nested types in similar way a=
t=20
> it=20
> > is done for reference wrapper ([refwrap] 20.10.3)?=20
>
> My understanding is that not_fn is very similar to bind (without=20
> arguments), so I would not suggest these types.=20
>
> Standard library is somehow about this typedefs - only bind does not=20
define these typedefs where they are well defined for target callable type.=
=20
Also it increase compatibility of results of not1, not2 with not_fn. I have=
=20
included appropriate section in design decisions.
=20

> - Daniel=20
>

--=20

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



------=_Part_372_32791302.1369428190817
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>W dniu pi=B1tek, 24 maja 2013 21:28:00 UTC+2 u=BFytkownik Daniel Kr=
=FCgler napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">2013/5/24 &n=
bsp;&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
DfxAk8CyZ1YJ">toma...@gmail.com</a>&gt;:
<br>&gt; I have changed a numbers reference numbers to this used inc C++14 =
CD (N3690)
<br>&gt; and put section names in additions. Also I changed the wording for=
 a
<br>&gt; result_type a bit.
<br>
<br>The term "Callable" is tricky. Without any qualification it would
<br>refer to [func.wrap.func] and would need further "annotations" such as
<br>"for argument types ArgTypes and return type R", which are not
<br>available at this point. Maybe you want to say:
<br>
<br>"f shall be a callable object ([func.require] 20.10.2)."
<br>
<br>?
<br>
<br>There are also some typos in regard to "synonim", "whould", and "defini=
ed".
<br>
<br>Please don't say what the new paragraph number *will* be (such as
<br>20.10.9), better say "20.10.?", nor how other paragraphs would change
<br>(such as "(Function template bind) becomes 20.10.10"), because that
<br>will anyway change according to the editors discretion and it is an
<br>automatic result of the LaTeX processing, so is not helpful.
<br>
<br>When you say "should define" this has a special meaning in a standard
<br>and means that an implementation can decide that as they like. If they
<br>don't like it, they don't add this - is that intended? (I doubt). You
<br>need to say "shall define" instead to impose the requirement for
<br>adding the member type. It would probably more helpful (and shorter)
<br>to say instead:
<br>
<br></blockquote><div>Thank you for you suggestions, I changed the proposal=
 accordingly.<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">"=
Returns: A simple call wrapper fn &lt;ins&gt;with a weak result type
<br>(20.10.2)&lt;/ins&gt; [..]"
<br>
<br>Now everything is clear, because 20.10.2 imposes the necessary
<br>requirements an implementations has to realize, and you don't need the
<br>sentence "The simple call wrapper fn should define [..]".
<br>
<br></blockquote><div>I think it won't work of not_fn, because I want to de=
fine result_type for negator in the means of result_type (decltype(!declval=
&lt;result_type&gt;()) of call wrapper with weak result type instead of jus=
t forwarding definition. For most cases the type will be the same, but it c=
an change.<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt;=
 Do you think that I should add requirements for argument_type,
<br>&gt; first_argument_type, second_argument_type nested types in similar =
way at it
<br>&gt; is done for reference wrapper ([refwrap] 20.10.3)?
<br>
<br>My understanding is that not_fn is very similar to bind (without
<br>arguments), so I would not suggest these types.
<br>
<br></blockquote><div>Standard library is somehow about this typedefs - onl=
y bind does not define these typedefs where they are well defined for targe=
t callable type. Also it increase compatibility of results of not1, not2 wi=
th not_fn. I have included appropriate section in design decisions.<br>&nbs=
p;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">- Daniel
<br></blockquote>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_372_32791302.1369428190817--
------=_Part_371_1395477.1369428190817
Content-Type: text/html; charset=UTF-8;
 name="A proposal to add a generalized callable negator.html"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="A proposal to add a generalized callable negator.html"
X-Attachment-Id: ee0462f5-a6c0-420d-8ca9-95cb8f9db568
Content-ID: <ee0462f5-a6c0-420d-8ca9-95cb8f9db568>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/htm=
l4/strict.dtd">
<html><head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8">

<style type=3D"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;=20
  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=3D"text/javascript">$(function() {
    var next_id =3D 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 =3D node[0];
        while (cur) {
            if (cur.id) return curid;
            if (cur.tagName =3D=3D 'A' && cur.name)
                return cur.name;
            cur =3D 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 =3D [$("<ol/>")];
    $(':header').not('h1').each(function() {
        var header =3D $(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 =3D {H2: 0, H3: 1, H4: 2, H5: 3, H6: 4};
        var level =3D levels[this.tagName];
        if (typeof level =3D=3D '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 =3D=3D level) {
            // Add a <ol> to the previous level's last <li> and push
            // it into the array.
            var ol =3D $('<ol/>')
            toc[toc.length - 1].children().last().append(ol);
            toc.push(ol);
        }
        var header_text =3D header.text();
        toc[toc.length - 1].append(
            $('<li/>').append($('<a href=3D"#' + find_id(header) + '"/>')
                              .text(header_text)));
    });
    $('#toc').append(toc[0]);
})
</script>
</head>

<body>

<h1><a name=3D"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&#324;ski, tomaszkam@gmail.com
</address>


<h2><a name=3D"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=3D"toc">Table of contents</a></h2-->

<h2><a name=3D"motivation">Motivation and Scope</a></h2>

<p>The standard negators <code>not1</code> and <code>not2</code> accept onl=
y unary and binary functors that define <code>argument_type</code> or <code=
>first_argument_type</code> and <code>second_argument_type</code> respectiv=
ely, which make them unusable with results of standard library functions su=
ch as <code>bind</code> and <code>mem_fn</code>. Furthermore, with relation=
 to <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n342=
1.htm">N3421</a>, they cannot be used with new operator functor specializat=
ions.</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=3D"motivation.lambda">Comparison with lambda</a></h3>

<p>While the polymorphic lambda expressions (<a href=3D"http://isocpp.org/f=
iles/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&amp; 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&amp; p) { return !std::mem_f=
n(pm)(p); });
  std::partition(v.begin(), v.end(), std::not_fn(pm));
</pre>

<h3><a name=3D"motivation.depraction">Deprecation</a></h3>
<p>With the incorporation of proposed functionality the old standard negato=
rs should be deprecated.</p>

<h2><a name=3D"design">Design Decisions</a></h2>

<h3><a name=3D"design.specializations">New specializations of <code>unary_n=
egate</code>, <code>binary_negate</code></a></h3>

<p>Problem addressed by this paper may be solved by introducing perfect for=
warding specializations of <code>unary_negate</code>, <code>binary_negate</=
code> for types that do not define <code>argument_type</code> and <code>fir=
st_argument_type</code>, <code>second_argument_type</code> nested types, re=
spectively, without breaking existing code. Although this solution does not=
 address functions with arbitrary number of arguments and requires addition=
al implementation burden.</p>

<h3><a name=3D"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=3D"h=
ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3421.htm">N3421</a>=
 applies.</p>

<h3><a name=3D"design.return">Argument typedefs</a></h3>
<p>The <code>argument_type</code>, <code>first_argument_type</code> and <co=
de>second_argument_type</code> nested types are required by implemenatation=
 to be consistent with most of libary functors, that define these types whe=
re they are well defined for target callable type. Futhermore it is increas=
ing the amount of existing code that will remain valid after changing <code=
>not1</code>, <code>not2</code> to <code>not_fn</code>.</p>

<h2><a name=3D"standard">Impact On The Standard</a></h2>

<p>This proposal has no dependencies beyond a C++11 compiler and Standard L=
ibrary implementation. (It depends on perfect forwarding, <code>decltype</c=
ode> and trailing return types.)</p>

<p>Nothing depends on this proposal.</p>

<h2><a name=3D"wording">Proposed wording</a></h2>

<p>After paragraph 20.10.8 Negators [negators], insert a new paragraph. (Ch=
apter [bind] (Function template <code>bind</code>) becomes 20.10.?)</p>
 =20
<blockquote class=3D"std">=20
<h4><a name=3D"optional.general">20.10.9 Function template <code>not_fn</co=
de> <span style=3D"float:right">[not_fn]</span></a></h4>

<pre>
  template &lt;class F&gt;
    <em>unspecified</em> not_fn(F f);
</pre>
    <dl class=3D"attribute">
    <dd><p>In the text that follows, the following names have the following=
 meanings:
    <ul>
      <li><code>fn</code> is simple call wrapper <code>fn</code> created as=
 a result of <code>not_fn(f)</code>,</li>
      <li><code>FN</code> is a type of <code>fn</code>,</li>
      <li><code>FW</code> is a type of forwarding call wrapper of <code>f</=
code> with a weak result type ([func.require] 20.10.2).</li>
    </ul></p></dd>

    <dt>Requires:</dt> <dd><p><code>F</code> shall be <code>CopyConstructib=
le</code>. <code>f</code> shall be a callable object ([func.require] 20.10.=
2).</p></dd>
    <dt>Returns:</dt> <dd><p>A simple call wrapper <code>fn</code> such tha=
t the expression <code>fn(a1, a2, ..., aN)</code> is equivalent to <code>!I=
NVOKE(f, a1, a2, ..., aN)</code> ([func.require] 20.10.2).</p>
    <dd><p>The <code>FN</code> shall define a nested type <code>result_type=
</code> as a synonym to <code>R</code> only if <code>FW</code> whould have =
a nested type <code>result_type</code>. The type <code>R</code> is <code>de=
cltype(!std::declval&lt;typename FW::result_type&gt;())</code>.</p></dd>
    <dd><p>The <code>FN</code> shall define a nested type named <code>argum=
ent_type</code> as a synonym for <code>T1</code> only if the type <code>F</=
code> is any of the following:=20
    <dd><ul>
     <li>a function type or a pointer to function type taking one argument =
of type <code>T1</code></li>=20
     <li>a pointer to member function <code>R T0::f cv</code> (where <code>=
cv</code> represents the member function's cv-qualifiers); the type <code>T=
1</code> is <code>cv T0*</code>
</li>
     <li>a class type with a member type <code>argument_type</code>; the ty=
pe <code>T1</code> is <code>T::argument_type.</code>
    </ul></p></dd>
    <dd><p>The <code>FN</code> shall define two nested types named <code>fi=
rst_argument_type</code> and <code>second_argument_type</code> as synonyms =
for <code>T1</code> and <code>T2</code>, respectively, only if the type <co=
de>F</code> is any of the following:
    <dd><ul>
     <li>a function type or a pointer to function type taking two arguments=
 of types <code>T1</code> and <code>T2</code></li>=20
     <li>a pointer to member function <code>R T0::f(T2) cv</code> (where <c=
ode>cv</code> represents the member function's cv-qualifiers); the type <co=
de>T1</code> is <code>cv T0*</code></li>
     <li>a class type with member types <code>first_argument_type</code> an=
d <code>second_argument_type</code>; the type <code>T1</code> is <code>T::f=
irst_argument_type</code>. and the type <code>T2</code> is <code>T::second_=
argument_type.</code>
   </ul></p></dd>
  </dl>
</blockquote>

<h2><a name=3D"acknowledgements">Acknowledgements</a></h2>

<p>Anna Salwa originally proposed <code>not_fn</code> in discussion group "=
ISO C++ Standard - Future Proposals".</p>
<p>Mateusz Kwiatkowski, Jonathan Wakely and Daniel Kr=C3=BCgler offered man=
y useful suggestions and corrections to the proposal.</p>

<h2><a name=3D"literature">References</a></h2>

<ol>

<li>Stephan T. Lavavej, "Making Operator Functors greater&lt;&gt;" (N3421, =
<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3421.ht=
m">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=3D"https://github.com/akrzemi1/Optional=
/">https://github.com/akrzemi1/Optional/</a>)</li>
</ol>


</body></html>
------=_Part_371_1395477.1369428190817--

.

------=_Part_39_10789737.1369467189382
Content-Type: multipart/alternative;
 boundary="----=_Part_40_14963254.1369467189383"

------=_Part_40_14963254.1369467189383
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

Fixed some mistakes in the wording.

W dniu pi=B1tek, 24 maja 2013 22:43:10 UTC+2 u=BFytkownik toma...@gmail.com=
=20
napisa=B3:
>
> > Do you think that I should add requirements for argument_type,=20
>> > first_argument_type, second_argument_type nested types in similar way=
=20
>> at it=20
>> > is done for reference wrapper ([refwrap] 20.10.3)?=20
>>
>> My understanding is that not_fn is very similar to bind (without=20
>> arguments), so I would not suggest these types.=20
>>
>> Standard library is (consistent) somehow about this typedefs - only bind=
=20
> does not define these typedefs where they are well defined for target=20
> callable type. Also it increase compatibility of results of not1, not2 wi=
th=20
> not_fn. I have included appropriate section in design decisions.
> =20
>
Additionally the bind can change order of arguments, so the first argument=
=20
on a call wrapper is not always forwarded as first argument of the target=
=20
and argument typedefs are hard to define in such situations. The not_fn=20
will always preserving the order of arguments (more similiar to=20
reference_wrapper) in this case, so these typedefs all well defined.
=20

--=20

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



------=_Part_40_14963254.1369467189383
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

Fixed some mistakes in the wording.<br><br>W dniu pi=B1tek, 24 maja 2013 22=
:43:10 UTC+2 u=BFytkownik toma...@gmail.com napisa=B3:<blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><blockquote class=3D"gmail_quote" style=3D"margin:0=
;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">&gt; Do you=
 think that I should add requirements for argument_type,
<br>&gt; first_argument_type, second_argument_type nested types in similar =
way at it
<br>&gt; is done for reference wrapper ([refwrap] 20.10.3)?
<br>
<br>My understanding is that not_fn is very similar to bind (without
<br>arguments), so I would not suggest these types.
<br>
<br></blockquote><div>Standard library is (consistent) somehow about this t=
ypedefs - only bind does not define these typedefs where they are well defi=
ned for target callable type. Also it increase compatibility of results of =
not1, not2 with not_fn. I have included appropriate section in design decis=
ions.<br>&nbsp;</div></blockquote><div>Additionally the bind can change ord=
er of arguments, so the first argument on a call wrapper is not always forw=
arded as first argument of the target and argument typedefs are hard to def=
ine in such situations. The not_fn will always preserving the order of argu=
ments (more similiar to reference_wrapper) in this case, so these typedefs =
all well defined.<br>&nbsp;</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_40_14963254.1369467189383--
------=_Part_39_10789737.1369467189382
Content-Type: text/html; charset=UTF-8;
 name="A proposal to add a generalized callable negator.html"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="A proposal to add a generalized callable negator.html"
X-Attachment-Id: 9f1933c1-1bb5-4fcf-aaa3-b4e4bbdc9cee
Content-ID: <9f1933c1-1bb5-4fcf-aaa3-b4e4bbdc9cee>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/htm=
l4/strict.dtd">
<html><head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8">

<style type=3D"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;=20
  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=3D"text/javascript">$(function() {
    var next_id =3D 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 =3D node[0];
        while (cur) {
            if (cur.id) return curid;
            if (cur.tagName =3D=3D 'A' && cur.name)
                return cur.name;
            cur =3D 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 =3D [$("<ol/>")];
    $(':header').not('h1').each(function() {
        var header =3D $(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 =3D {H2: 0, H3: 1, H4: 2, H5: 3, H6: 4};
        var level =3D levels[this.tagName];
        if (typeof level =3D=3D '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 =3D=3D level) {
            // Add a <ol> to the previous level's last <li> and push
            // it into the array.
            var ol =3D $('<ol/>')
            toc[toc.length - 1].children().last().append(ol);
            toc.push(ol);
        }
        var header_text =3D header.text();
        toc[toc.length - 1].append(
            $('<li/>').append($('<a href=3D"#' + find_id(header) + '"/>')
                              .text(header_text)));
    });
    $('#toc').append(toc[0]);
})
</script>
</head>

<body>

<h1><a name=3D"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&#324;ski, tomaszkam@gmail.com
</address>


<h2><a name=3D"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=3D"toc">Table of contents</a></h2-->

<h2><a name=3D"motivation">Motivation and Scope</a></h2>

<p>The standard negators <code>not1</code> and <code>not2</code> accept onl=
y unary and binary functors that define <code>argument_type</code> or <code=
>first_argument_type</code> and <code>second_argument_type</code> respectiv=
ely, which make them unusable with results of standard library functions su=
ch as <code>bind</code> and <code>mem_fn</code>. Furthermore, with relation=
 to <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n342=
1.htm">N3421</a>, they cannot be used with new operator functor specializat=
ions.</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=3D"motivation.lambda">Comparison with lambda</a></h3>

<p>While the polymorphic lambda expressions (<a href=3D"http://isocpp.org/f=
iles/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&amp; 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&amp; p) { return !std::mem_f=
n(pm)(p); });
  std::partition(v.begin(), v.end(), std::not_fn(pm));
</pre>

<h3><a name=3D"motivation.depraction">Deprecation</a></h3>
<p>With the incorporation of proposed functionality the old standard negato=
rs should be deprecated.</p>

<h2><a name=3D"design">Design Decisions</a></h2>

<h3><a name=3D"design.specializations">New specializations of <code>unary_n=
egate</code>, <code>binary_negate</code></a></h3>

<p>Problem addressed by this paper may be solved by introducing perfect for=
warding specializations of <code>unary_negate</code>, <code>binary_negate</=
code> for types that do not define <code>argument_type</code> and <code>fir=
st_argument_type</code>, <code>second_argument_type</code> nested types, re=
spectively, without breaking existing code. Although this solution does not=
 address functions with arbitrary number of arguments and requires addition=
al implementation burden.</p>

<h3><a name=3D"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=3D"h=
ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3421.htm">N3421</a>=
 applies.</p>

<h3><a name=3D"design.return">Argument typedefs</a></h3>
<p>The <code>argument_type</code>, <code>first_argument_type</code> and <co=
de>second_argument_type</code> nested types are required by implemenatation=
 to be consistent with most of libary functors, that define these types whe=
re they are well defined for target callable type. Futhermore it is increas=
ing the amount of existing code that will remain valid after changing <code=
>not1</code>, <code>not2</code> to <code>not_fn</code>.</p>

<h2><a name=3D"standard">Impact On The Standard</a></h2>

<p>This proposal has no dependencies beyond a C++11 compiler and Standard L=
ibrary implementation. (It depends on perfect forwarding, <code>decltype</c=
ode> and trailing return types.)</p>

<p>Nothing depends on this proposal.</p>

<h2><a name=3D"wording">Proposed wording</a></h2>

<p>After paragraph 20.10.8 Negators [negators], insert a new paragraph. (Ch=
apter [bind] (Function template <code>bind</code>) becomes 20.10.?)</p>
 =20
<blockquote class=3D"std">=20
<h4><a name=3D"optional.general">20.10.9 Function template <code>not_fn</co=
de> <span style=3D"float:right">[not_fn]</span></a></h4>

<pre>
  template &lt;class F&gt;
    <em>unspecified</em> not_fn(F f);
</pre>
    <dl class=3D"attribute">
    <dd><p>In the text that follows, the following names have the following=
 meanings:
    <ul>
      <li><code>fn</code> is a simple call wrapper created as a result of <=
code>not_fn(f)</code>,</li>
      <li><code>FN</code> is a type of <code>fn</code>,</li>
      <li><code>FW</code> is a type of forwarding call wrapper of <code>f</=
code> with a weak result type ([func.require] 20.10.2).</li>
    </ul></p></dd>

    <dt>Requires:</dt> <dd><p><code>F</code> shall be <code>CopyConstructib=
le</code>. <code>f</code> shall be a callable object ([func.require] 20.10.=
2).</p></dd>
    <dt>Returns:</dt> <dd><p>A simple call wrapper <code>fn</code> such tha=
t the expression <code>fn(a1, a2, ..., aN)</code> is equivalent to <code>!I=
NVOKE(f, a1, a2, ..., aN)</code> ([func.require] 20.10.2).</p>
    <dd><p>The <code>FN</code> shall define a nested type named <code>resul=
t_type</code> as a synonym to <code>R</code> only if <code>FW</code> whould=
 have a nested type <code>result_type</code>. The type <code>R</code> is <c=
ode>decltype(!std::declval&lt;typename FW::result_type&gt;())</code>.</p></=
dd>
    <dd><p>The <code>FN</code> shall define a nested type named <code>argum=
ent_type</code> as a synonym for <code>T1</code> only if the type <code>F</=
code> is any of the following:=20
    <dd><ul>
     <li>a function type or a pointer to function type taking one argument =
of type <code>T1</code></li>=20
     <li>a pointer to member function <code>R T0::f cv</code> (where <code>=
cv</code> represents the member function's cv-qualifiers); the type <code>T=
1</code> is <code>cv T0*</code>
</li>
     <li>a class type with a member type <code>argument_type</code>; the ty=
pe <code>T1</code> is <code>F::argument_type.</code>
    </ul></p></dd>
    <dd><p>The <code>FN</code> shall define two nested types named <code>fi=
rst_argument_type</code> and <code>second_argument_type</code> as synonyms =
for <code>T1</code> and <code>T2</code>, respectively, only if the type <co=
de>F</code> is any of the following:
    <dd><ul>
     <li>a function type or a pointer to function type taking two arguments=
 of types <code>T1</code> and <code>T2</code></li>=20
     <li>a pointer to member function <code>R T0::f(T2) cv</code> (where <c=
ode>cv</code> represents the member function's cv-qualifiers); the type <co=
de>T1</code> is <code>cv T0*</code></li>
     <li>a class type with member types <code>first_argument_type</code> an=
d <code>second_argument_type</code>; the type <code>T1</code> is <code>F::f=
irst_argument_type</code>. and the type <code>T2</code> is <code>F::second_=
argument_type.</code>
   </ul></p></dd>
  </dl>
</blockquote>

<h2><a name=3D"acknowledgements">Acknowledgements</a></h2>

<p>Anna Salwa originally proposed <code>not_fn</code> in discussion group "=
ISO C++ Standard - Future Proposals".</p>
<p>Mateusz Kwiatkowski, Jonathan Wakely and Daniel Kr=C3=BCgler offered man=
y useful suggestions and corrections to the proposal.</p>

<h2><a name=3D"literature">References</a></h2>

<ol>

<li>Stephan T. Lavavej, "Making Operator Functors greater&lt;&gt;" (N3421, =
<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3421.ht=
m">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=3D"https://github.com/akrzemi1/Optional=
/">https://github.com/akrzemi1/Optional/</a>)</li>
</ol>


</body></html>
------=_Part_39_10789737.1369467189382--

.

------=_Part_1132_30293591.1369470512963
Content-Type: multipart/alternative;
 boundary="----=_Part_1133_23000831.1369470512963"

------=_Part_1133_23000831.1369470512963
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

Fixed some mistakes in the wording.


W dniu pi=B1tek, 24 maja 2013 22:43:10 UTC+2 u=BFytkownik toma...@gmail.com=
=20
napisa=B3:
>
>
>
> W dniu pi=B1tek, 24 maja 2013 21:28:00 UTC+2 u=BFytkownik Daniel Kr=FCgle=
r=20
> napisa=B3:
>>
>> > Do you think that I should add requirements for argument_type,=20
>> > first_argument_type, second_argument_type nested types in similar way=
=20
>> at it=20
>> > is done for reference wrapper ([refwrap] 20.10.3)?=20
>>
>> My understanding is that not_fn is very similar to bind (without=20
>> arguments), so I would not suggest these types.=20
>>
>> Standard library is somehow  (inconsistent) about this typedefs - only=
=20
> bind does not define these typedefs where they are well defined for targe=
t=20
> callable type. Also it increase compatibility of results of not1, not2 wi=
th=20
> not_fn. I have included appropriate section in design decisions.
> =20
>
The bind can change order of arguments, so the first argument on a call=20
wrapper is not always forwarded as first argument of the target and=20
argument typedefs are hard to define in such situations. The not_fn will=20
always preserving the order of arguments (more similar to=20
reference_wrapper) in this case, so these typedefs all well defined.

--=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_1133_23000831.1369470512963
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

Fixed some mistakes in the wording.<br><br><br>W dniu pi=B1tek, 24 maja 201=
3 22:43:10 UTC+2 u=BFytkownik toma...@gmail.com napisa=B3:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><br><br>W dniu pi=B1tek, 24 maja 2013 21:28:00 =
UTC+2 u=BFytkownik Daniel Kr=FCgler napisa=B3:<blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex">&gt; Do you think that I should add requirements for argument_ty=
pe,
<br>&gt; first_argument_type, second_argument_type nested types in similar =
way at it
<br>&gt; is done for reference wrapper ([refwrap] 20.10.3)?
<br>
<br>My understanding is that not_fn is very similar to bind (without
<br>arguments), so I would not suggest these types.
<br>
<br></blockquote><div>Standard library is somehow&nbsp; (inconsistent) abou=
t this typedefs - only bind does not define these typedefs where they are w=
ell defined for target callable type. Also it increase compatibility of res=
ults of not1, not2 with not_fn. I have included appropriate section in desi=
gn decisions.<br>&nbsp;</div></blockquote><div>The bind can change order of=
 arguments, so the first argument on a call wrapper is not always forwarded=
 as first argument of the target and argument typedefs are hard to define i=
n such situations. The not_fn will always preserving the order of arguments=
 (more similar to reference_wrapper) in this case, so these typedefs all we=
ll defined.</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_1133_23000831.1369470512963--
------=_Part_1132_30293591.1369470512963
Content-Type: text/html; charset=UTF-8;
 name="A proposal to add a generalized callable negator.html"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="A proposal to add a generalized callable negator.html"
X-Attachment-Id: c78c14f5-8b5d-489e-acf7-d0c4af6f938a
Content-ID: <c78c14f5-8b5d-489e-acf7-d0c4af6f938a>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/htm=
l4/strict.dtd">
<html><head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8">

<style type=3D"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;=20
  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=3D"text/javascript">$(function() {
    var next_id =3D 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 =3D node[0];
        while (cur) {
            if (cur.id) return curid;
            if (cur.tagName =3D=3D 'A' && cur.name)
                return cur.name;
            cur =3D 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 =3D [$("<ol/>")];
    $(':header').not('h1').each(function() {
        var header =3D $(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 =3D {H2: 0, H3: 1, H4: 2, H5: 3, H6: 4};
        var level =3D levels[this.tagName];
        if (typeof level =3D=3D '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 =3D=3D level) {
            // Add a <ol> to the previous level's last <li> and push
            // it into the array.
            var ol =3D $('<ol/>')
            toc[toc.length - 1].children().last().append(ol);
            toc.push(ol);
        }
        var header_text =3D header.text();
        toc[toc.length - 1].append(
            $('<li/>').append($('<a href=3D"#' + find_id(header) + '"/>')
                              .text(header_text)));
    });
    $('#toc').append(toc[0]);
})
</script>
</head>

<body>

<h1><a name=3D"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&#324;ski, tomaszkam@gmail.com
</address>


<h2><a name=3D"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=3D"toc">Table of contents</a></h2-->

<h2><a name=3D"motivation">Motivation and Scope</a></h2>

<p>The standard negators <code>not1</code> and <code>not2</code> accept onl=
y unary and binary functors that define <code>argument_type</code> or <code=
>first_argument_type</code> and <code>second_argument_type</code> respectiv=
ely, which make them unusable with results of standard library functions su=
ch as <code>bind</code> and <code>mem_fn</code>. Furthermore, with relation=
 to <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n342=
1.htm">N3421</a>, they cannot be used with new operator functor specializat=
ions.</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=3D"motivation.lambda">Comparison with lambda</a></h3>

<p>While the polymorphic lambda expressions (<a href=3D"http://isocpp.org/f=
iles/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&amp; 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&amp; p) { return !std::mem_f=
n(pm)(p); });
  std::partition(v.begin(), v.end(), std::not_fn(pm));
</pre>

<h3><a name=3D"motivation.depraction">Deprecation</a></h3>
<p>With the incorporation of proposed functionality the old standard negato=
rs should be deprecated.</p>

<h2><a name=3D"design">Design Decisions</a></h2>

<h3><a name=3D"design.specializations">New specializations of <code>unary_n=
egate</code>, <code>binary_negate</code></a></h3>

<p>Problem addressed by this paper may be solved by introducing perfect for=
warding specializations of <code>unary_negate</code>, <code>binary_negate</=
code> for types that do not define <code>argument_type</code> and <code>fir=
st_argument_type</code>, <code>second_argument_type</code> nested types, re=
spectively, without breaking existing code. Although this solution does not=
 address functions with arbitrary number of arguments and requires addition=
al implementation burden.</p>

<h3><a name=3D"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=3D"h=
ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3421.htm">N3421</a>=
 applies.</p>

<h3><a name=3D"design.return">Argument typedefs</a></h3>
<p>The <code>argument_type</code>, <code>first_argument_type</code> and <co=
de>second_argument_type</code> nested types are required by implemenatation=
 to be consistent with most of libary functors, that define these types whe=
re they are well defined for target callable type. Futhermore it is increas=
ing the amount of existing code that will remain valid after changing <code=
>not1</code>, <code>not2</code> to <code>not_fn</code>.</p>

<h2><a name=3D"standard">Impact On The Standard</a></h2>

<p>This proposal has no dependencies beyond a C++11 compiler and Standard L=
ibrary implementation. (It depends on perfect forwarding, <code>decltype</c=
ode> and trailing return types.)</p>

<p>Nothing depends on this proposal.</p>

<h2><a name=3D"wording">Proposed wording</a></h2>

<p>After paragraph 20.10.8 Negators [negators], insert a new paragraph. (Ch=
apter [bind] (Function template <code>bind</code>) becomes 20.10.?)</p>
 =20
<blockquote class=3D"std">=20
<h4><a name=3D"optional.general">20.10.9 Function template <code>not_fn</co=
de> <span style=3D"float:right">[not_fn]</span></a></h4>

<pre>
  template &lt;class F&gt;
    <em>unspecified</em> not_fn(F f);
</pre>
    <dl class=3D"attribute">
    <dd><p>In the text that follows, the following names have the following=
 meanings:
    <ul>
      <li><code>fn</code> is a simple call wrapper created as a result of <=
code>not_fn(f)</code>,</li>
      <li><code>FN</code> is a type of <code>fn</code>,</li>
      <li><code>FW</code> is a type of forwarding call wrapper of <code>f</=
code> with a weak result type ([func.require] 20.10.2).</li>
    </ul></p></dd>

    <dt>Requires:</dt> <dd><p><code>F</code> shall be <code>CopyConstructib=
le</code>. <code>f</code> shall be a callable object ([func.require] 20.10.=
2).</p></dd>
    <dt>Returns:</dt> <dd><p>A simple call wrapper <code>fn</code> such tha=
t the expression <code>fn(a1, a2, ..., aN)</code> is equivalent to <code>!I=
NVOKE(f, a1, a2, ..., aN)</code> ([func.require] 20.10.2).</p>
    <dd><p>The <code>FN</code> shall define a nested type named <code>resul=
t_type</code> as a synonym to <code>R</code> only if <code>FW</code> would =
have a nested type <code>result_type</code>; the type <code>R</code> is <co=
de>decltype(!declval&lt;typename FW::result_type&gt;())</code>.</p></dd>
    <dd><p>The <code>FN</code> shall define a nested type named <code>argum=
ent_type</code> as a synonym for <code>T1</code> only if the type <code>F</=
code> is any of the following:=20
    <dd><ul>
     <li>a function type or a pointer to function type taking one argument =
of type <code>T1</code></li>=20
     <li>a pointer to member function <code>R T0::f cv</code> (where <code>=
cv</code> represents the member function's cv-qualifiers); the type <code>T=
1</code> is <code>cv T0*</code>
</li>
     <li>a class type with a member type <code>argument_type</code>; the ty=
pe <code>T1</code> is <code>F::argument_type.</code>
    </ul></p></dd>
    <dd><p>The <code>FN</code> shall define two nested types named <code>fi=
rst_argument_type</code> and <code>second_argument_type</code> as synonyms =
for <code>T1</code> and <code>T2</code>, respectively, only if the type <co=
de>F</code> is any of the following:
    <dd><ul>
     <li>a function type or a pointer to function type taking two arguments=
 of types <code>T1</code> and <code>T2</code></li>=20
     <li>a pointer to member function <code>R T0::f(T2) cv</code> (where <c=
ode>cv</code> represents the member function's cv-qualifiers); the type <co=
de>T1</code> is <code>cv T0*</code></li>
     <li>a class type with member types <code>first_argument_type</code> an=
d <code>second_argument_type</code>; the type <code>T1</code> is <code>F::f=
irst_argument_type</code> and the type <code>T2</code> is <code>F::second_a=
rgument_type.</code>
   </ul></p></dd>
  </dl>
</blockquote>

<h2><a name=3D"acknowledgements">Acknowledgements</a></h2>

<p>Anna Salwa originally proposed <code>not_fn</code> in discussion group "=
ISO C++ Standard - Future Proposals".</p>
<p>Mateusz Kwiatkowski, Jonathan Wakely and Daniel Kr=C3=BCgler offered man=
y useful suggestions and corrections to the proposal.</p>

<h2><a name=3D"literature">References</a></h2>

<ol>

<li>Stephan T. Lavavej, "Making Operator Functors greater&lt;&gt;" (N3421, =
<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3421.ht=
m">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=3D"https://github.com/akrzemi1/Optional=
/">https://github.com/akrzemi1/Optional/</a>)</li>
</ol>


</body></html>
------=_Part_1132_30293591.1369470512963--

.

------=_Part_328_25624449.1369679276261
Content-Type: multipart/alternative;
 boundary="----=_Part_329_32541871.1369679276261"

------=_Part_329_32541871.1369679276261
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Any comments on the new wording?

 I am wondering if the requirements for argument typedefs should be=20
extracted from [refwrap] section and proposed [not_fn] section to=20
[func.require] (they are pretty the same)? Example:
[func.require]

If a call wrapper (20.10.1) has a argument types the types of its member=20
type argument_type is based on the type T of the wrapper=92s target object=
=20
(20.10.1):
- if T is a pointer to function type taking one argument of type T1, then=
=20
argument_type shall be a synonym for T1;
- if T is a pointer to member function R T0::f cv (where cv represents the=
=20
member function=92s cv-qualifiers), then argument_type shall be a synonym=
=20
for  cv T0*;
- if T is a class type with a member type argument_type, then argument_type=
=20
shall be a synonym for T::argument_type;
- otherwise argument_type shall not be defined.

If a call wrapper (20.10.1) has a argument types the types of its member=20
types first_argument_type, second_argument_type are based on the type T of=
=20
the wrapper=92s target object (20.10.1):
- if T is a pointer to function type taking two arguments of types T1 and=
=20
T2, then first_argument_type shall be a synonym for T1 and=20
second_argument_type shall be synonym for T2;
- if T is a pointer to member function R T0::f(T2) cv (where cv represents=
=20
the member function=92s cv-qualifiers), then  first_argument_type shall be =
a=20
synonym for cv T0* and second_argument_type shall be synonym for T2;
- if T is a class type with member types first_argument_type and=20
second_argument_type, then first_argument_type shall be a synonym for=20
T::first_argument_type and second_argument_type shall be synonym for=20
T::second_argument_type;
- otherwise first_argument_type and second_argument_type shall not be=20
defined.

[refwrap]
Add line:
reference_wrapper<T> has argument types (20.10.2). If T is a function type=
=20
the argument_type, first_argument_type, second_argument_type should shall=
=20
be the same as for pointer to a function type.
Remove line about argument typedefs.

[not_fn]
Returns: A call wrapper with argument types fn such that the expression fn(=
a1,=20
a2, ..., aN) is equivalent to !INVOKE(f, a1, a2, ..., aN) ([func.require]=
=20
20.10.2).=20
If such change is recommended, shall I included it in the wording for the=
=20
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/?hl=3Den.



------=_Part_329_32541871.1369679276261
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Any comments on the new wording?<br><br>&nbsp;I am wondering if the require=
ments for argument typedefs should be extracted from [refwrap] section and =
proposed [not_fn] section to [func.require] (they are pretty the same)? Exa=
mple:<br>[func.require]<br><br>If a call wrapper (20.10.1) has a argument t=
ypes the types of its member type argument_type is based on the type T of t=
he wrapper=92s target object (20.10.1):<br>- if T is a pointer to function =
type taking one argument of type T1, then argument_type shall be a synonym =
for T1;<br>- if T is a pointer to member function R T0::f cv (where cv repr=
esents the member function=92s cv-qualifiers), then argument_type shall be =
a synonym for&nbsp; cv T0*;<br>- if T is a class type with a member type ar=
gument_type, then argument_type shall be a synonym for T::argument_type;<br=
>- otherwise argument_type shall not be defined.<br><br>If a call wrapper (=
20.10.1) has a argument types the types of its member
 types first_argument_type, second_argument_type are=20
based on the type T of the wrapper=92s target object (20.10.1):<br>- if T i=
s a pointer to function type taking two arguments of types T1=20
and T2, then  first_argument_type shall be a synonym for T1 and=20
second_argument_type shall be synonym for T2;<br>- if T is a pointer to mem=
ber function R T0::f(T2) cv (where cv represents the member function=92s cv=
-qualifiers), then&nbsp; first_argument_type shall be a synonym for cv T0* =
and second_argument_type shall be synonym for T2;<br>- if T is a class type=
 with member types first_argument_type and second_argument_type, then first=
_argument_type shall be a synonym for T::first_argument_type and second_arg=
ument_type shall be synonym for T::second_argument_type;<br>- otherwise fir=
st_argument_type and second_argument_type shall not be defined.<br><br>[ref=
wrap]<br>Add line:<br>reference_wrapper&lt;T&gt; has argument types (20.10.=
2). If T is a function type the argument_type, first_argument_type, second_=
argument_type should shall be the same as for pointer to a function type.<b=
r>Remove line about argument typedefs.<br><br>[not_fn]<br><dl class=3D"attr=
ibute"><dt>Returns: A <code>call wrapper with argument types fn</code> such=
 that the expression <code>fn(a1, a2, ..., aN)</code> is equivalent to <cod=
e>!INVOKE(f, a1, a2, ..., aN)</code> ([func.require] 20.10.2).</dt><dd>
    <br></dd></dl>If such change is recommended, shall I included it in the=
 wording for the proposal?<br>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_329_32541871.1369679276261--
------=_Part_328_25624449.1369679276261
Content-Type: text/html; charset=UTF-8;
 name="A proposal to add a generalized callable negator.html"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="A proposal to add a generalized callable negator.html"
X-Attachment-Id: 0c7e9923-2d7b-44e8-b50b-a30b95bac3c2
Content-ID: <0c7e9923-2d7b-44e8-b50b-a30b95bac3c2>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/htm=
l4/strict.dtd">
<html><head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8">

<style type=3D"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;=20
  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=3D"text/javascript">$(function() {
    var next_id =3D 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 =3D node[0];
        while (cur) {
            if (cur.id) return curid;
            if (cur.tagName =3D=3D 'A' && cur.name)
                return cur.name;
            cur =3D 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 =3D [$("<ol/>")];
    $(':header').not('h1').each(function() {
        var header =3D $(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 =3D {H2: 0, H3: 1, H4: 2, H5: 3, H6: 4};
        var level =3D levels[this.tagName];
        if (typeof level =3D=3D '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 =3D=3D level) {
            // Add a <ol> to the previous level's last <li> and push
            // it into the array.
            var ol =3D $('<ol/>')
            toc[toc.length - 1].children().last().append(ol);
            toc.push(ol);
        }
        var header_text =3D header.text();
        toc[toc.length - 1].append(
            $('<li/>').append($('<a href=3D"#' + find_id(header) + '"/>')
                              .text(header_text)));
    });
    $('#toc').append(toc[0]);
})
</script>
</head>

<body>

<h1><a name=3D"title">A proposal to add a generalized callable negator</a><=
/h1>


<!--p>ISO/IEC JTC1 SC22 WG21 N??</p-->=20
<p>2013-05-27</p>

<address>
Tomasz Kami&#324;ski, tomaszkam@gmail.com
</address>


<h2><a name=3D"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 object.</p>

<!--h2><a name=3D"toc">Table of contents</a></h2-->

<h2><a name=3D"motivation">Motivation and Scope</a></h2>

<p>The standard negators <code>not1</code> and <code>not2</code> accept onl=
y unary and binary functors that define <code>argument_type</code> or <code=
>first_argument_type</code> and <code>second_argument_type</code> respectiv=
ely, which make them unusable with results of standard library functions su=
ch as <code>bind</code> and <code>mem_fn</code>. Furthermore, with relation=
 to <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n342=
1.htm">N3421</a>, they cannot be used with new operator functor specializat=
ions.</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=3D"motivation.lambda">Comparison with lambda</a></h3>

<p>While the polymorphic lambda expressions (<a href=3D"http://isocpp.org/f=
iles/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&amp; 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&amp; p) { return !std::mem_f=
n(pm)(p); });
  std::partition(v.begin(), v.end(), std::not_fn(pm));
</pre>

<h3><a name=3D"motivation.depraction">Deprecation</a></h3>
<p>With the incorporation of proposed functionality the old standard negato=
rs should be deprecated.</p>

<h2><a name=3D"design">Design Decisions</a></h2>

<h3><a name=3D"design.specializations">New specializations of <code>unary_n=
egate</code>, <code>binary_negate</code></a></h3>

<p>Problem addressed by this paper may be solved by introducing perfect for=
warding specializations of <code>unary_negate</code>, <code>binary_negate</=
code> for types that do not define <code>argument_type</code> and <code>fir=
st_argument_type</code>, <code>second_argument_type</code> nested types, re=
spectively, without breaking existing code. Although this solution does not=
 address functions with arbitrary number of arguments and requires addition=
al implementation burden.</p>

<h3><a name=3D"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=3D"h=
ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3421.htm">N3421</a>=
 applies.</p>

<h3><a name=3D"design.return">Argument typedefs</a></h3>
<p>The <code>argument_type</code>, <code>first_argument_type</code> and <co=
de>second_argument_type</code> nested types are required by implemenatation=
 to be consistent with most of library functors, that define these types wh=
ere they are well defined for target callable type. Futhermore it is increa=
sing the amount of existing code that will remain valid after changing <cod=
e>not1</code>, <code>not2</code> to <code>not_fn</code>.</p>

<h2><a name=3D"standard">Impact On The Standard</a></h2>

<p>This proposal has no dependencies beyond a C++11 compiler and Standard L=
ibrary implementation. (It depends on perfect forwarding, <code>decltype</c=
ode> and trailing return types.)</p>

<p>Nothing depends on this proposal.</p>

<h2><a name=3D"wording">Proposed wording</a></h2>

<p>After paragraph 20.10.8 Negators [negators], insert a new paragraph. (Ch=
apter [bind] (Function template <code>bind</code>) becomes 20.10.?)</p>
 =20
<blockquote class=3D"std">=20
<h4><a name=3D"optional.general">20.10.9 Function template <code>not_fn</co=
de> <span style=3D"float:right">[not_fn]</span></a></h4>

<pre>
  template &lt;class F&gt;
    <em>unspecified</em> not_fn(F f);
</pre>
    <dl class=3D"attribute">
    <dd><p>In the text that follows, the following names have the following=
 meanings:
    <ul>
      <li><code>fn</code> is a simple call wrapper created as a result of <=
code>not_fn(f)</code>,</li>
      <li><code>FN</code> is a type of <code>fn</code>,</li>
      <li><code>FW</code> is a type of forwarding call wrapper for <code>f<=
/code> with a weak result type ([func.require] 20.10.2).</li>
    </ul></p></dd>

    <dt>Requires:</dt> <dd><p><code>F</code> shall be <code>CopyConstructib=
le</code>. <code>f</code> shall be a callable object ([func.require] 20.10.=
2).</p></dd>
    <dt>Returns:</dt> <dd><p>A simple call wrapper <code>fn</code> such tha=
t the expression <code>fn(a1, a2, ..., aN)</code> is equivalent to <code>!I=
NVOKE(f, a1, a2, ..., aN)</code> ([func.require] 20.10.2).</p>
    <dd><p>The <code>FN</code> shall define a nested type named <code>resul=
t_type</code> as a synonym to <code>R</code> only if <code>FW</code> would =
have a nested type <code>result_type</code>; the type <code>R</code> is <co=
de>decltype(!declval&lt;typename FW::result_type&gt;())</code>.</p></dd>
    <dd><p>The <code>FN</code> shall define a nested type named <code>argum=
ent_type</code> as a synonym for <code>T1</code> only if the type <code>F</=
code> is any of the following:=20
    <dd><ul>
     <li>a function type or a pointer to function type taking one argument =
of type <code>T1</code></li>=20
     <li>a pointer to member function <code>R T0::f cv</code> (where <code>=
cv</code> represents the member function's cv-qualifiers); the type <code>T=
1</code> is <code>cv T0*</code>
</li>
     <li>a class type with a member type <code>argument_type</code>; the ty=
pe <code>T1</code> is <code>F::argument_type.</code>
    </ul></p></dd>
    <dd><p>The <code>FN</code> shall define two nested types named <code>fi=
rst_argument_type</code> and <code>second_argument_type</code> as synonyms =
for <code>T1</code> and <code>T2</code>, respectively, only if the type <co=
de>F</code> is any of the following:
    <dd><ul>
     <li>a function type or a pointer to function type taking two arguments=
 of types <code>T1</code> and <code>T2</code></li>=20
     <li>a pointer to member function <code>R T0::f(T2) cv</code> (where <c=
ode>cv</code> represents the member function's cv-qualifiers); the type <co=
de>T1</code> is <code>cv T0*</code></li>
     <li>a class type with member types <code>first_argument_type</code> an=
d <code>second_argument_type</code>; the type <code>T1</code> is <code>F::f=
irst_argument_type</code> and the type <code>T2</code> is <code>F::second_a=
rgument_type.</code>
   </ul></p></dd>
  </dl>
</blockquote>

<h2><a name=3D"acknowledgements">Acknowledgements</a></h2>

<p>Anna Salwa originally proposed <code>not_fn</code> in discussion group "=
ISO C++ Standard - Future Proposals".</p>
<p>Mateusz Kwiatkowski, Jonathan Wakely and Daniel Kr=C3=BCgler offered man=
y useful suggestions and corrections to the proposal.</p>

<h2><a name=3D"literature">References</a></h2>

<ol>

<li>Stephan T. Lavavej, "Making Operator Functors greater&lt;&gt;" (N3421, =
<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3421.ht=
m">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=3D"https://github.com/akrzemi1/Optional=
/">https://github.com/akrzemi1/Optional/</a>)</li>
</ol>


</body></html>
------=_Part_328_25624449.1369679276261--

.

------=_Part_41_19834494.1369726201708
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



W dniu poniedzia=B3ek, 27 maja 2013 20:27:56 UTC+2 u=BFytkownik=20
toma...@gmail.com napisa=B3:
>
> Any comments on the new wording?
>
=20
Is it intentional that* f*'s result type is not required to be convertible=
=20
to *bool*? Even though you forward *f*'s result type, you could still=20
require the convertibility to *bool*. This way the negation is given an=20
intuitive meaning. The only reason not to do it that I can think of is to=
=20
make *not_fn* usable in expression templates, or similar techniques -- was=
=20
this the intent?


Rationale from n3421<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/201=
2/n3421.htm>does not (to me) fully apply to=20
*not_fn*, because in the latter case you transform the value and likely the=
=20
type.=20

Consider *std::cin *(it does provide the negation operator):
int i;
auto read =3D [&] -> std::istream& { std::cin >> i; };
if (read()) {/*...*/} // makes sense
if (not_fn(read)())   // compile-time error?

Perhaps returning *bool *is a safer bet?

Regards,
&rzej

--=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_41_19834494.1369726201708
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>W dniu poniedzia=B3ek, 27 maja 2013 20:27:56 UTC+2 u=BFytkownik tom=
a...@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;">Any c=
omments on the new wording?<br></blockquote><div>&nbsp;<br>Is it intentiona=
l that<b> f</b>'s result type is not required to be convertible to <b>bool<=
/b>? Even though you forward <b>f</b>'s result type, you could still requir=
e the convertibility to <b>bool</b>. This way the negation is given an intu=
itive meaning. The only reason not to do it that I can think of is to make =
<b>not_fn</b> usable in expression templates, or similar techniques -- was =
this the intent?<br><br><br>Rationale from <a href=3D"http://www.open-std.o=
rg/jtc1/sc22/wg21/docs/papers/2012/n3421.htm">n3421</a> does not (to me) fu=
lly apply to <b>not_fn</b>, because in the latter case you transform the va=
lue and likely the type. <br><br>Consider <b>std::cin </b>(it does provide =
the negation operator):<br><div class=3D"prettyprint" style=3D"background-c=
olor: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: s=
olid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint=
"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"style=
d-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> i</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> read </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">[&amp;]</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">-&gt;</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">istream</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">cin </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">&gt;&gt;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> i</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">};</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r></span><span style=3D"color: #008;" class=3D"styled-by-prettify">if</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">read</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">())</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">{</span><span style=3D"color: #800;" class=3D"styled-by-=
prettify">/*...*/</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #800;" class=3D"styled-by-prettify">// makes se=
nse</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">if</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">not_fn</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">read</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">)())</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> &nbsp; </span><span style=3D"color: #800;" class=3D"styled-by=
-prettify">// compile-time error?</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span></div></code></div><br>Perhaps returning=
 <b>bool </b>is a safer bet?<br><br>Regards,<br>&amp;rzej<br><br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_41_19834494.1369726201708--

.

------=_Part_244_27019182.1369737061653
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



W dniu wtorek, 28 maja 2013 09:30:01 UTC+2 u=BFytkownik Andrzej Krzemie=F1s=
ki=20
napisa=B3:
>
>
>
> W dniu poniedzia=B3ek, 27 maja 2013 20:27:56 UTC+2 u=BFytkownik=20
> toma...@gmail.com napisa=B3:
>>
>> Any comments on the new wording?
>>
> =20
> Is it intentional that* f*'s result type is not required to be=20
> convertible to *bool*? Even though you forward *f*'s result type, you=20
> could still require the convertibility to *bool*. This way the negation=
=20
> is given an intuitive meaning. The only reason not to do it that I can=20
> think of is to make *not_fn* usable in expression templates, or similar=
=20
> techniques -- was this the intent?
>
>
> Rationale from n3421<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2=
012/n3421.htm>does not (to me) fully apply to=20
> *not_fn*, because in the latter case you transform the value and likely=
=20
> the type.=20
>
> Consider *std::cin *(it does provide the negation operator):
> int i;
> auto read =3D [&] -> std::istream& { std::cin >> i; };
> if (read()) {/*...*/} // makes sense
> if (not_fn(read)())   // compile-time error?
>
> Perhaps returning *bool *is a safer bet?
>
>
The not_fn does forward the result of expression !f(...), not the result of=
=20
f, so the example your example will work correctly. The only example where=
=20
not_fn may have surprising semantics, are the situations when the f returns=
=20
a type that have operator! returning type diffrent than bool (same=20
sitatuation as for logical_not<> from n3421<http://www.open-std.org/jtc1/sc=
22/wg21/docs/papers/2012/n3421.htm>
).
=20

> Regards,
> &rzej
>
>

--=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_244_27019182.1369737061653
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>W dniu wtorek, 28 maja 2013 09:30:01 UTC+2 u=BFytkownik Andrzej Krz=
emie=F1ski napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br><br>W=
 dniu poniedzia=B3ek, 27 maja 2013 20:27:56 UTC+2 u=BFytkownik <a>toma...@g=
mail.com</a> napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin:0;=
margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Any comments=
 on the new wording?<br></blockquote><div>&nbsp;<br>Is it intentional that<=
b> f</b>'s result type is not required to be convertible to <b>bool</b>? Ev=
en though you forward <b>f</b>'s result type, you could still require the c=
onvertibility to <b>bool</b>. This way the negation is given an intuitive m=
eaning. The only reason not to do it that I can think of is to make <b>not_=
fn</b> usable in expression templates, or similar techniques -- was this th=
e intent?<br> <br></div></blockquote><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
 1ex;"><div><br>Rationale from <a href=3D"http://www.open-std.org/jtc1/sc22=
/wg21/docs/papers/2012/n3421.htm" target=3D"_blank">n3421</a> does not (to =
me) fully apply to <b>not_fn</b>, because in the latter case you transform =
the value and likely the type. <br><br>Consider <b>std::cin </b>(it does pr=
ovide the negation operator):<br><div style=3D"background-color:rgb(250,250=
,250);border-color:rgb(187,187,187);border-style:solid;border-width:1px;wor=
d-wrap:break-word"><code><div><span style=3D"color:#008">int</span><span st=
yle=3D"color:#000"> i</span><span style=3D"color:#660">;</span><span style=
=3D"color:#000"><br></span><span style=3D"color:#008">auto</span><span styl=
e=3D"color:#000"> read </span><span style=3D"color:#660">=3D</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#660">[&amp;]</span><span s=
tyle=3D"color:#000"> </span><span style=3D"color:#660">-&gt;</span><span st=
yle=3D"color:#000"> std</span><span style=3D"color:#660">::</span><span sty=
le=3D"color:#000">istream</span><span style=3D"color:#660">&amp;</span><spa=
n style=3D"color:#000"> </span><span style=3D"color:#660">{</span><span sty=
le=3D"color:#000"> std</span><span style=3D"color:#660">::</span><span styl=
e=3D"color:#000">cin </span><span style=3D"color:#660">&gt;&gt;</span><span=
 style=3D"color:#000"> i</span><span style=3D"color:#660">;</span><span sty=
le=3D"color:#000"> </span><span style=3D"color:#660">};</span><span style=
=3D"color:#000"><br></span><span style=3D"color:#008">if</span><span style=
=3D"color:#000"> </span><span style=3D"color:#660">(</span><span style=3D"c=
olor:#000">read</span><span style=3D"color:#660">())</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#660">{</span><span style=3D"color:=
#800">/*...*/</span><span style=3D"color:#660">}</span><span style=3D"color=
:#000"> </span><span style=3D"color:#800">// makes sense</span><span style=
=3D"color:#000"><br></span><span style=3D"color:#008">if</span><span style=
=3D"color:#000"> </span><span style=3D"color:#660">(</span><span style=3D"c=
olor:#000">not_fn</span><span style=3D"color:#660">(</span><span style=3D"c=
olor:#000">read</span><span style=3D"color:#660">)())</span><span style=3D"=
color:#000"> &nbsp; </span><span style=3D"color:#800">// compile-time error=
?</span><span style=3D"color:#000"><br></span></div></code></div><br>Perhap=
s returning <b>bool </b>is a safer bet?<br><br></div></blockquote><div><br>=
The not_fn does forward the result of expression !f(...), not the result of=
 f, so the example your example will work correctly. The only example where=
 not_fn may have surprising semantics, are the situations when the f return=
s a type that have operator! returning type diffrent than bool (same sitatu=
ation as for logical_not&lt;&gt; from <a href=3D"http://www.open-std.org/jt=
c1/sc22/wg21/docs/papers/2012/n3421.htm" target=3D"_blank">n3421</a>).<br>&=
nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>Regards,<br>&a=
mp;rzej<br><br></div></blockquote>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_244_27019182.1369737061653--

.

On 2013-05-28 03:30, Andrzej Krzemie=F1ski wrote:
> W dniu poniedzia=B3ek, 27 maja 2013 20:27:56 UTC+2 u=BFytkownik
> toma...@gmail.com napisa=B3:
>=20
>     Any comments on the new wording?
>=20
> =20
> Is it intentional that*f*'s result type is not required to be
> convertible to *bool*? Even though you forward *f*'s result type, you
> could still require the convertibility to *bool*. This way the negation
> is given an intuitive meaning. The only reason not to do it that I can
> think of is to make *not_fn* usable in expression templates, or similar
> techniques -- was this the intent?
>=20
>=20
> Rationale from n3421
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3421.htm> does
> not (to me) fully apply to *not_fn*, because in the latter case you
> transform the value and likely the type.
>=20
> Consider *std::cin *(it does provide the negation operator):
> |
> inti;
> autoread =3D[&]->std::istream&{std::cin >>i;};
> if(read()){/*...*/}// makes sense
> if(not_fn(read)())  // compile-time error?
> |
>=20
> Perhaps returning *bool *is a safer bet?

Another reason not to simply return bool is to faithfully forward things
like boost::tribool, which has operator! not returning bool for good
reason (although it is convertible to bool).

John Bytheway


--=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_359_19246832.1372417679778
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I would like if anyone is willing to champion my proposal on Chicago=20
meeting?  It was not changed since version<https://std-proposals-a-isocpp-o=
rg.googlegroups.com/attach/b0044de02098677e/A%20proposal%20to%20add%20a%20g=
eneralized%20callable%20negator.html?view=3D1&part=3D4>presented several po=
st before and the document number will be N3699.

--=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_359_19246832.1372417679778
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I would like if anyone is willing to champion my proposal on Chicago meetin=
g?&nbsp; It was not changed since <a href=3D"https://std-proposals-a-isocpp=
-org.googlegroups.com/attach/b0044de02098677e/A%20proposal%20to%20add%20a%2=
0generalized%20callable%20negator.html?view=3D1&amp;part=3D4">version</a> p=
resented several post before and the document number will be N3699.<br>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_359_19246832.1372417679778--

.

------=_Part_490_16657766.1379795804102
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

The previous version of the wording released in the N3699 disallows=20
wrapping of move-only callable objects via imposing copy on the provider=20
functor. The mistake is corrected in the draft
of the next revisions of the paper, that may be found at=20
https://github.com/tomaszkam/proposals/blob/master/A%20proposal%20to%20add%=
20a%20generalized%20callable%20negator.html
..
Also the previous wording misses appropriate throws clause.

W dniu pi=B1tek, 28 czerwca 2013 13:07:59 UTC+2 u=BFytkownik toma...@gmail.=
com=20
napisa=B3:
>
> I would like if anyone is willing to champion my proposal on Chicago=20
> meeting?  It was not changed since version<https://std-proposals-a-isocpp=
-org.googlegroups.com/attach/b0044de02098677e/A%20proposal%20to%20add%20a%2=
0generalized%20callable%20negator.html?view=3D1&part=3D4>presented several =
post before and the document number will be N3699.
>

--=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_490_16657766.1379795804102
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The previous version of the wording released in the N3699 =
disallows wrapping of move-only callable objects via imposing copy on the p=
rovider functor. The mistake is corrected in the draft<br>of the next revis=
ions of the paper, that may be found at <a href=3D"https://github.com/tomas=
zkam/proposals/blob/master/A%20proposal%20to%20add%20a%20generalized%20call=
able%20negator.html">https://github.com/tomaszkam/proposals/blob/master/A%2=
0proposal%20to%20add%20a%20generalized%20callable%20negator.html</a>.<br>Al=
so the previous wording misses appropriate throws clause.<br><br>W dniu pi=
=B1tek, 28 czerwca 2013 13:07:59 UTC+2 u=BFytkownik toma...@gmail.com napis=
a=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">I would like if anyone is=
 willing to champion my proposal on Chicago meeting?&nbsp; It was not chang=
ed since <a href=3D"https://std-proposals-a-isocpp-org.googlegroups.com/att=
ach/b0044de02098677e/A%20proposal%20to%20add%20a%20generalized%20callable%2=
0negator.html?view=3D1&amp;part=3D4" target=3D"_blank">version</a> presente=
d several post before and the document number will be N3699.<br></blockquot=
e></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_490_16657766.1379795804102--

.