Topic: comment on P0013R1 Logical Operator Type Traits
Author: Robert Ramey <ramey@rrsd.com>
Date: Sat, 2 Jan 2016 10:34:10 -0800
Raw View
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0013r1.html
Quoth Ville: "__and_, __or_ and __not_ as they are already available in
libstdc++ are an absolute godsend, not just for a library writer, but
for any user who needs to do metaprogramming with parameter packs.
Boost.MPL has shipped similar facilities for a very long time, and it's
high time we standardize these simple utilities."
"The traits were originally proposed with the obvious names, "and", "or"
and "not", adjusted to avoid clashing with the alternative tokens of the
same names. Another option would have been static_and but the context
and angle brackets should be enough to make it obvious these are
templates that are evaluated at compile-time, and the shorter names are
easier to read. LEWG discussed a number of names, and the eventual
preference was for longer names, without a trailing underscore."
Indeed these have been in Boost for a very long time. My question is
why change the names at this point. Tons of code have and, or and not
and now we're going to get a set of completely different names. It
is some much more intuitive to replace current code
boost::mpl::if_c<
boost::mpl::and<
...
>::value,
...,
...
>
with
boost::mpl::if_c<
std::and<
...
>::value,
...,
...
>
Robert Ramey
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Sat, 2 Jan 2016 13:13:44 -0600
Raw View
--001a1145a83a215e1805285eb2ad
Content-Type: text/plain; charset=UTF-8
On 2 January 2016 at 12:34, Robert Ramey <ramey@rrsd.com> wrote:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0013r1.html
>
> Indeed these have been in Boost for a very long time. My question is
> why change the names at this point. Tons of code have and, or and not
> and now we're going to get a set of completely different names.
I'm pretty sure no code uses "and", "or" or "not" for this purpose because
those names are reserved; see [lex.key] for more details.
Boost.MPL <http://www.boost.org/doc/libs/1_60_0/libs/mpl/doc/index.html>
uses "and_", "or_" and "not_".
> It
> is some much more intuitive to replace current code
>
> boost::mpl::if_c<
> boost::mpl::and<
> ...
> >::value,
> ...,
> ...
> >
>
> with
>
> boost::mpl::if_c<
> std::and<
> ...
> >::value,
> ...,
> ...
> >
It doesn't return quite the same thing as boost::mpl::and_. You can use
it as a replacement for boost::mpl::and_<...>::value but not
boost::mil::and_<...>. I do not see mixing it with Boost.MPL
<http://www.boost.org/doc/libs/1_60_0/libs/mpl/doc/index.html> to be
sufficiently motivating, as such use would be error-prone at best.
And there are coding standards out there which use trailing underscores for
member variables.
That being said, while naming is extremely important, I don't find most of
the bike shedding of names during committee meetings to be a good use of my
time, so I wouldn't stand in the way if enough other committee members felt
differently.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a1145a83a215e1805285eb2ad
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 2 January 2016 at 12:34, Robert Ramey <span dir=3D"ltr"=
><<a href=3D"mailto:ramey@rrsd.com" target=3D"_blank">ramey@rrsd.com</a>=
></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><a href=3D"http://www.open-std.org/jtc1/sc2=
2/wg21/docs/papers/2015/p0013r1.html" rel=3D"noreferrer" target=3D"_blank">=
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0013r1.html</a><br=
>
<br>Indeed these have been in Boost for a very long time.=C2=A0 My question=
is<br>
why change the names at this point.=C2=A0 Tons of code have and, or and not=
<br>
and now we're going to get a set of completely different names.=C2=A0</=
blockquote><div><br></div><div>I'm pretty sure no code uses "and&q=
uot;, "or" or "not" for this purpose because those name=
s are reserved; see [lex.key] for more details.</div><div><br></div><div><a=
href=3D"http://www.boost.org/doc/libs/1_60_0/libs/mpl/doc/index.html">Boos=
t.MPL</a> uses "and_", "or_" and "not_".</div=
><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"> It<br>
is some much more intuitive to replace current code<br>
<br>
boost::mpl::if_c<<br>
=C2=A0 =C2=A0 boost::mpl::and<<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...<br>
=C2=A0 =C2=A0 >::value,<br>
=C2=A0 =C2=A0 ...,<br>
=C2=A0 =C2=A0 ...<br>
><br>
<br>
with<br>
<br>
boost::mpl::if_c<<br>
=C2=A0 =C2=A0 std::and<<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...<br>
=C2=A0 =C2=A0 >::value,<br>
=C2=A0 =C2=A0 ...,<br>
=C2=A0 =C2=A0 ...<br>
></blockquote><div><br></div><div>It doesn't return quite the same t=
hing as boost::mpl::and_. =C2=A0 You can use it as a replacement for boost:=
:mpl::and_<...>::value but not boost::mil::and_<...>.=C2=A0 I d=
o not see mixing it with <a href=3D"http://www.boost.org/doc/libs/1_60_0/li=
bs/mpl/doc/index.html">Boost.MPL</a> to be sufficiently motivating, as such=
use would be error-prone at best.</div><div><br></div><div>And there are c=
oding standards out there which use trailing underscores for member variabl=
es.</div><div><br></div><div>That being said, while naming is extremely imp=
ortant, I don't find most of the bike shedding of names during committe=
e meetings to be a good use of my time, so I wouldn't stand in the way =
if enough other committee members felt differently.</div></div>-- <br><div =
class=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=
=A0Nevin ":-)" Liber=C2=A0 <mailto:<a href=3D"mailto:nevin@evi=
loverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>> =C2=A0+1-84=
7-691-1404</div></div></div></div></div>
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--001a1145a83a215e1805285eb2ad--
.
Author: Robert Ramey <ramey@rrsd.com>
Date: Sat, 2 Jan 2016 12:02:01 -0800
Raw View
On 1/2/16 11:13 AM, Nevin Liber wrote:
That being said, while naming is extremely important, I don't find most
> of the bike shedding of names during committee meetings to be a good use
> of my time, so I wouldn't stand in the way if enough other committee
> members felt differently.
I feel the same way about such discussions. But still, couldn't anyone
do better than:
// logical conjunction:
template<class... B> struct conjunction;
// logical disjunction:
template<class... B> struct disjunction;
// logical negation:
template<class B> struct negation;
I know you're going to ask me why I don't suggest something. I don't
have any really great response. But even something stupid like
logical_and
logical_or
logical_not
would be easier to read and understand
Robert Ramey
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 2 Jan 2016 22:37:21 +0200
Raw View
On 2 January 2016 at 22:02, Robert Ramey <ramey@rrsd.com> wrote:
> I feel the same way about such discussions. But still, couldn't anyone do
> better than:
> // logical conjunction:
> template<class... B> struct conjunction;
> // logical disjunction:
> template<class... B> struct disjunction;
> // logical negation:
> template<class B> struct negation;
Personally, I found it more important to have the facility than
waiting for it to be agreed
on with an optimal name.
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Patrice Roy <patricer@gmail.com>
Date: Sat, 2 Jan 2016 16:23:33 -0500
Raw View
--94eb2c07701a0ba44405286080c8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I was at the table when we discussed this and there was a small number of
options put before us. We retained the one that seemed the best of the lot
in our eyes; I think we all knew the names we retained were imperfect in a
sense, but they seemed Ok enough and did not clash with other well-known
facilities we were aware of.
When we went back in full LEWG meeting, this =C2=ABwe need it, and these na=
mes
are Ok even though they're not amazingly good=C2=BB impression seemed to me=
et
the general sentiment in the room, and I did not hear anything much better
in terms of naming that day.
I'd just keep them as accepted. As Ville stated, it's a very useful
utility, and it's probably be used mostly by people who understand these
nomenclature trade-offs and will get immediate benefits from these features=
..
2016-01-02 15:37 GMT-05:00 Ville Voutilainen <ville.voutilainen@gmail.com>:
> On 2 January 2016 at 22:02, Robert Ramey <ramey@rrsd.com> wrote:
> > I feel the same way about such discussions. But still, couldn't anyone
> do
> > better than:
> > // logical conjunction:
> > template<class... B> struct conjunction;
> > // logical disjunction:
> > template<class... B> struct disjunction;
> > // logical negation:
> > template<class B> struct negation;
>
>
> Personally, I found it more important to have the facility than
> waiting for it to be agreed
> on with an optimal name.
>
> --
>
> ---
> 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
> https://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--94eb2c07701a0ba44405286080c8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I was at the table when we discussed this and there was a =
small number of options put before us. We retained the one that seemed the =
best of the lot in our eyes; I think we all knew the names we retained were=
imperfect in a sense, but they seemed Ok enough and did not clash with oth=
er well-known facilities we were aware of.<br><br>When we went back in full=
LEWG meeting, this =C2=ABwe need it, and these names are Ok even though th=
ey're not amazingly good=C2=BB impression seemed to meet the general se=
ntiment in the room, and I did not hear anything much better in terms of na=
ming that day.<br><br>I'd just keep them as accepted. As Ville stated, =
it's a very useful utility, and it's probably be used mostly by peo=
ple who understand these nomenclature trade-offs and will get immediate ben=
efits from these features.<br></div><div class=3D"gmail_extra"><br><div cla=
ss=3D"gmail_quote">2016-01-02 15:37 GMT-05:00 Ville Voutilainen <span dir=
=3D"ltr"><<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blan=
k">ville.voutilainen@gmail.com</a>></span>:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><span class=3D"">On 2 January 2016 at 22:02, Robert Ramey <<a href=
=3D"mailto:ramey@rrsd.com">ramey@rrsd.com</a>> wrote:<br>
> I feel the same way about such discussions.=C2=A0 But still, couldn=
9;t anyone do<br>
> better than:<br>
> // logical conjunction:<br>
> template<class... B> struct conjunction;<br>
> // logical disjunction:<br>
> template<class... B> struct disjunction;<br>
> // logical negation:<br>
> template<class B> struct negation;<br>
<br>
<br>
</span>Personally, I found it more important to have the facility than<br>
waiting for it to be agreed<br>
on with an optimal name.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/" rel=3D"noreferrer" target=3D"_blank">https://groups.google=
..com/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--94eb2c07701a0ba44405286080c8--
.
Author: Bo Persson <bop@gmb.dk>
Date: Sat, 2 Jan 2016 22:51:42 +0100
Raw View
On 2016-01-02 21:02, Robert Ramey wrote:
> On 1/2/16 11:13 AM, Nevin Liber wrote:
> That being said, while naming is extremely important, I don't find most
>> of the bike shedding of names during committee meetings to be a good use
>> of my time, so I wouldn't stand in the way if enough other committee
>> members felt differently.
>
> I feel the same way about such discussions. But still, couldn't anyone
> do better than:
>
> // logical conjunction:
> template<class... B> struct conjunction;
>
> // logical disjunction:
> template<class... B> struct disjunction;
Guess I will not use these much, as I don't understand what it means. :-(
>
> // logical negation:
> template<class B> struct negation;
>
> I know you're going to ask me why I don't suggest something. I don't
> have any really great response. But even something stupid like
>
> logical_and
> logical_or
> logical_not
>
> would be easier to read and understand
>
Yes, unfortunately those names are also already taken...
Bo Persson
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Sat, 2 Jan 2016 22:56:51 +0100
Raw View
--001a1147dc9817eb90052860f760
Content-Type: text/plain; charset=UTF-8
meta_and
meta_or
meta_not
On Sat, Jan 2, 2016 at 10:51 PM, Bo Persson <bop@gmb.dk> wrote:
> On 2016-01-02 21:02, Robert Ramey wrote:
>
>> On 1/2/16 11:13 AM, Nevin Liber wrote:
>> That being said, while naming is extremely important, I don't find most
>>
>>> of the bike shedding of names during committee meetings to be a good use
>>> of my time, so I wouldn't stand in the way if enough other committee
>>> members felt differently.
>>>
>>
>> I feel the same way about such discussions. But still, couldn't anyone
>> do better than:
>>
>> // logical conjunction:
>> template<class... B> struct conjunction;
>>
>> // logical disjunction:
>> template<class... B> struct disjunction;
>>
>
>
> Guess I will not use these much, as I don't understand what it means. :-(
>
>
>> // logical negation:
>> template<class B> struct negation;
>>
>> I know you're going to ask me why I don't suggest something. I don't
>> have any really great response. But even something stupid like
>>
>> logical_and
>> logical_or
>> logical_not
>>
>> would be easier to read and understand
>>
>>
>
> Yes, unfortunately those names are also already taken...
>
>
>
> Bo Persson
>
>
>
>
> --
>
> --- 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
> https://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a1147dc9817eb90052860f760
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">meta_and<div>meta_or</div><div>meta_not</div></div><div cl=
ass=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sat, Jan 2, 2016 at 1=
0:51 PM, Bo Persson <span dir=3D"ltr"><<a href=3D"mailto:bop@gmb.dk" tar=
get=3D"_blank">bop@gmb.dk</a>></span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><span class=3D"">On 2016-01-02 21:02, Robert Ramey wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On 1/2/16 11:13 AM, Nevin Liber wrote:<br>
=C2=A0 That being said, while naming is extremely important, I don't fi=
nd most<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
of the bike shedding of names during committee meetings to be a good use<br=
>
of my time, so I wouldn't stand in the way if enough other committee<br=
>
members felt differently.<br>
</blockquote>
<br>
I feel the same way about such discussions.=C2=A0 But still, couldn't a=
nyone<br>
do better than:<br>
<br>
// logical conjunction:<br>
template<class... B> struct conjunction;<br>
<br>
// logical disjunction:<br>
template<class... B> struct disjunction;<br>
</blockquote>
<br>
<br></span>
Guess I will not use these much, as I don't understand what it means.=
=C2=A0 :-(<span class=3D""><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<br>
// logical negation:<br>
template<class B> struct negation;<br>
<br>
I know you're going to ask me why I don't suggest something.=C2=A0 =
I don't<br>
have any really great response.=C2=A0 But even something stupid like<br>
<br>
logical_and<br>
logical_or<br>
logical_not<br>
<br>
would be easier to read and understand<br>
<br>
</blockquote>
<br>
<br></span>
Yes, unfortunately those names are also already taken...<span class=3D"HOEn=
Zb"><font color=3D"#888888"><br>
<br>
<br>
<br>
=C2=A0 =C2=A0Bo Persson</font></span><div class=3D"HOEnZb"><div class=3D"h5=
"><br>
<br>
<br>
<br>
-- <br>
<br>
--- You received this message because you are subscribed to the Google Grou=
ps "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/" rel=3D"noreferrer" target=3D"_blank">https://groups.google=
..com/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--001a1147dc9817eb90052860f760--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sun, 3 Jan 2016 00:08:23 +0200
Raw View
On 2 January 2016 at 23:56, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
> meta_and
> meta_or
> meta_not
Have you already looked at https://issues.isocpp.org/show_bug.cgi?id=109,
or are you just throwing spaghetti at the wall, hoping that things
already discussed
and bike-shedded will stick differently? LEWG made its call, so
rehashes of names
already suggested will not change that call.
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Sat, 2 Jan 2016 23:33:02 +0100
Raw View
--047d7ba972228a59e90528617862
Content-Type: text/plain; charset=UTF-8
On Sat, Jan 2, 2016 at 11:08 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
> On 2 January 2016 at 23:56, Andrew Tomazos <andrewtomazos@gmail.com>
> wrote:
> > meta_and
> > meta_or
> > meta_not
>
> Have you already looked at https://issues.isocpp.org/show_bug.cgi?id=109,
> or are you just throwing spaghetti at the wall, hoping that things
> already discussed
> and bike-shedded will stick differently? LEWG made its call, so
> rehashes of names
> already suggested will not change that call.
Sorry, didnt know it had already been bike-shedded.
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7ba972228a59e90528617862
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Sat, Jan 2, 2016 at 11:08 PM, Ville Voutilainen <span dir=3D"ltr">&l=
t;<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.vo=
utilainen@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>On 2 January 2016 at 23:56, Andrew Tomazos <<a href=3D"mailto:andrewtom=
azos@gmail.com">andrewtomazos@gmail.com</a>> wrote:<br>
> meta_and<br>
> meta_or<br>
> meta_not<br>
<br>
Have you already looked at <a href=3D"https://issues.isocpp.org/show_bug.cg=
i?id=3D109" rel=3D"noreferrer" target=3D"_blank">https://issues.isocpp.org/=
show_bug.cgi?id=3D109</a>,<br>
or are you just throwing spaghetti at the wall, hoping that things<br>
already discussed<br>
and bike-shedded will stick differently? LEWG made its call, so<br>
rehashes of names<br>
already suggested will not change that call.</blockquote><div><br></div><di=
v>Sorry, didnt know it had already been bike-shedded.</div><div>=C2=A0</div=
></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--047d7ba972228a59e90528617862--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 2 Jan 2016 16:41:23 -0800 (PST)
Raw View
------=_Part_1_1421022355.1451781683869
Content-Type: multipart/alternative;
boundary="----=_Part_2_654987071.1451781683872"
------=_Part_2_654987071.1451781683872
Content-Type: text/plain; charset=UTF-8
On Saturday, January 2, 2016 at 5:08:27 PM UTC-5, Ville Voutilainen wrote:
>
> On 2 January 2016 at 23:56, Andrew Tomazos <andrew...@gmail.com
> <javascript:>> wrote:
> > meta_and
> > meta_or
> > meta_not
>
> Have you already looked at https://issues.isocpp.org/show_bug.cgi?id=109,
> or are you just throwing spaghetti at the wall, hoping that things
> already discussed
> and bike-shedded will stick differently?
You know, these conversations would be a bit less likely to happen if
isocpp.org actual advertised resources like that issues Bugzilla database
(this is the first I've heard of it). There's a whole category of pages
under "Standardization", and as far as I can tell, none of them link to
vital resources like:
* https://issues.isocpp.org - for following what went on in the discussion
of a particular paper
* https://cplusplus.github.io/EWG/ewg-active.html - Another way of
understanding where exactly a paper is within the process.
* http://www.open-std.org/JTC1/SC22/WG21/docs/papers/ - The list of all
papers.
* wg21.link - for easily linking to a paper if you know its number.
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_2_654987071.1451781683872
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Saturday, January 2, 2016 at 5:08:27 PM UTC-5, Ville Voutilainen wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;">On 2 January 2016 at 23:56, And=
rew Tomazos <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-ma=
ilto=3D"qCv2bG6NEgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'java=
script:';return true;" onclick=3D"this.href=3D'javascript:';ret=
urn true;">andrew...@gmail.com</a>> wrote:
<br>> meta_and
<br>> meta_or
<br>> meta_not
<br>
<br>Have you already looked at <a href=3D"https://issues.isocpp.org/show_bu=
g.cgi?id=3D109" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'https://www.google.com/url?q\75https%3A%2F%2Fissues.isocpp.org%2Fsh=
ow_bug.cgi%3Fid%3D109\46sa\75D\46sntz\0751\46usg\75AFQjCNES_RgH9CKL1dP-4LrZ=
ANAWEFV87g';return true;" onclick=3D"this.href=3D'https://www.googl=
e.com/url?q\75https%3A%2F%2Fissues.isocpp.org%2Fshow_bug.cgi%3Fid%3D109\46s=
a\75D\46sntz\0751\46usg\75AFQjCNES_RgH9CKL1dP-4LrZANAWEFV87g';return tr=
ue;">https://issues.isocpp.org/<wbr>show_bug.cgi?id=3D109</a>,
<br>or are you just throwing spaghetti at the wall, hoping that things
<br>already discussed
<br>and bike-shedded will stick differently?</blockquote><div><br>You know,=
these conversations would be a bit less likely to happen if isocpp.org act=
ual advertised resources like that issues Bugzilla database (this is the fi=
rst I've heard of it). There's a whole category of pages under &quo=
t;Standardization", and as far as I can tell, none of them link to vit=
al resources like:<br><br>* https://issues.isocpp.org - for following what =
went on in the discussion of a particular paper<br>* https://cplusplus.gith=
ub.io/EWG/ewg-active.html - Another way of understanding where exactly a pa=
per is within the process.<br>* http://www.open-std.org/JTC1/SC22/WG21/docs=
/papers/ - The list of all papers.<br>* wg21.link - for easily linking to a=
paper if you know its number.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_2_654987071.1451781683872--
------=_Part_1_1421022355.1451781683869--
.
Author: Zhihao Yuan <zy@miator.net>
Date: Sat, 2 Jan 2016 20:11:06 -0600
Raw View
On Sat, Jan 2, 2016 at 3:51 PM, Bo Persson <bop@gmb.dk> wrote:
>>
>> // logical conjunction:
>> template<class... B> struct conjunction;
>>
>> // logical disjunction:
>> template<class... B> struct disjunction;
>
> Guess I will not use these much, as I don't understand what it means. :-(
Am I the only person who reallY love those names?...
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4bsd
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Sun, 3 Jan 2016 13:43:22 -0800 (PST)
Raw View
------=_Part_11803_1443780061.1451857402960
Content-Type: multipart/alternative;
boundary="----=_Part_11804_332787516.1451857402960"
------=_Part_11804_332787516.1451857402960
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Saturday, January 2, 2016 at 6:11:11 PM UTC-8, Zhihao Yuan wrote:
>
> On Sat, Jan 2, 2016 at 3:51 PM, Bo Persson <b...@gmb.dk <javascript:>>=20
> wrote:=20
> >>=20
> >> // logical conjunction:=20
> >> template<class... B> struct conjunction;=20
> >>=20
> >> // logical disjunction:=20
> >> template<class... B> struct disjunction;=20
> >=20
> > Guess I will not use these much, as I don't understand what it means.=
=20
> :-(=20
>
> Am I the only person who reallY love those names?...=20
Like Patrice, I was in the room when the bikeshedding of these names=20
happened. My recollection of the discussion was that a lot of people were=
=20
in favor of C++'s acquiring a whole "meta" library, basically by adopting=
=20
MPL or Hana or something along those lines. This would be named something=
=20
like
- std::meta::plus
- std::meta::minus
- std::meta::multiplies
- std::meta::divides
- std::meta::logical_and <=3D=3D HERE
- std::meta::logical_or <=3D=3D HERE
- std::meta::bit_and
- std::meta::bit_or
- std::meta::bit_xor
....
defined in such a way that for example std::is_same<=20
std::meta::plus<std::integral_constant<int, 1>, std::integral_constant<int,=
=20
2>>, std::integral_constant<int, 3> >::value =3D=3D true.
"HERE" are the two functions whose names we were bikeshedding.
However, there was (and is) no proposal on the table for such a=20
comprehensive "meta" library.
So the basic question was, do we want to start such a library right this=20
instant by standardizing meta::logical_and and meta::logical_or without any=
=20
of the rest of it, or do we want to punt on the larger question (awaiting a=
=20
proposal) and just standardize the tools people are asking for today, under=
=20
names that definitely won't get in the way of any future "meta::"=20
standardization efforts?
Given that C++ has already standardized "if_" under the name=20
"std::conditional", it seems pretty reasonable to me to standardize "and_"=
=20
as "std::conjunction" and "or_" as "std::disjunction". Anyone who seriously=
=20
wants to use these metafunctions will certainly do something like
template<typename... T> using and_ =3D std::conjunction<T...>;
template<typename... T> using or_ =3D std::disjunction<T...>;
anyway, so it's not getting in the way of real library programmers. The=20
obscure-sounding name also keeps it out of the hands of programmers who=20
*don't* need or want it. This family of types is not on the same level of=
=20
"new-programmer-usefulness" as std::less =E2=80=94 not even on the same lev=
el as=20
std::plus =E2=80=94 not even on the same level as std::conditional, IMHO =
=E2=80=94 and=20
therefore it's almost a feature, not a bug, that its name is so forbidding.
=E2=80=93Arthur
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
------=_Part_11804_332787516.1451857402960
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Saturday, January 2, 2016 at 6:11:11 PM UTC-8, =
Zhihao Yuan wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Sat, Jan =
2, 2016 at 3:51 PM, Bo Persson <<a href=3D"javascript:" target=3D"_blank=
" gdf-obfuscated-mailto=3D"q9CGYK2aEgAJ" rel=3D"nofollow" onmousedown=3D"th=
is.href=3D'javascript:';return true;" onclick=3D"this.href=3D'j=
avascript:';return true;">b...@gmb.dk</a>> wrote:
<br>>>
<br>>> // logical conjunction:
<br>>> template<class... B> struct conjunction;
<br>>>
<br>>> // logical disjunction:
<br>>> template<class... B> struct disjunction;
<br>>
<br>> Guess I will not use these much, as I don't understand what it=
means. =C2=A0:-(
<br>
<br>Am I the only person who reallY love those names?...=C2=A0</blockquote>=
<div><br></div><div>Like Patrice, I was in the room when the bikeshedding o=
f these names happened. My recollection of the discussion was that a lot of=
people were in favor of C++'s acquiring a whole "meta" libra=
ry, basically by adopting MPL or Hana or something along those lines. This =
would be named something like</div><div>- std::meta::plus<br></div><div>- s=
td::meta::minus</div><div>- std::meta::multiplies</div><div>- std::meta::di=
vides</div><div>- std::meta::logical_and =C2=A0<=3D=3D HERE<br></div><di=
v>- std::meta::logical_or =C2=A0<=3D=3D HERE<br></div><div>- std::meta::=
bit_and<br></div><div>- std::meta::bit_or</div><div><div>- std::meta::bit_x=
or</div></div><div>...</div><div><br></div><div>defined in such a way that =
for example std::is_same< std::meta::plus<std::integral_constant<i=
nt, 1>, std::integral_constant<int, 2>>, std::integral_constant=
<int, 3> >::value =3D=3D true.</div><div><br></div><div>"HERE=
" are the two functions whose names we were bikeshedding.</div><div>Ho=
wever, there was (and is) no proposal on the table for such a comprehensive=
"meta" library.</div><div><br></div><div>So the basic question w=
as, do we want to start such a library right this instant by standardizing =
meta::logical_and and meta::logical_or without any of the rest of it, or do=
we want to punt on the larger question (awaiting a proposal) and just stan=
dardize the tools people are asking for today, under names that definitely =
won't get in the way of any future "meta::" standardization e=
fforts?</div><div><br></div><div>Given that C++ has already standardized &q=
uot;if_" under the name "std::conditional", it seems pretty =
reasonable to me to standardize "and_" as "std::conjunction&=
quot; and "or_" as "std::disjunction". Anyone who serio=
usly wants to use these metafunctions will certainly do something like</div=
><div><br></div><div><div>template<typename... T> using and_ =3D std:=
:conjunction<T...>;</div></div><div><div>template<typename... T>=
; using or_ =3D std::disjunction<T...>;</div></div><div><br></div><di=
v>anyway, so it's not getting in the way of real library programmers. T=
he obscure-sounding name also keeps it out of the hands of programmers who =
*don't* need or want it. This family of types is not on the same level =
of "new-programmer-usefulness" as std::less =E2=80=94 not even on=
the same level as std::plus =E2=80=94 not even on the same level as std::c=
onditional, IMHO =E2=80=94 and therefore it's almost a feature, not a b=
ug, that its name is so forbidding.</div><div><br></div><div>=E2=80=93Arthu=
r</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_11804_332787516.1451857402960--
------=_Part_11803_1443780061.1451857402960--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Sun, 03 Jan 2016 18:30:06 -0500
Raw View
<html><head></head><body lang=3D"en-US" style=3D"background-color: rgb(255,=
255, 255); line-height: initial;"> =
<div style=3D"width: 100%; fo=
nt-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif=
; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, =
255, 255);">My recollection is the same, and that's pretty much exactly the=
email I was typing when I saw yours. </div> =
=
<div style=3D"width: 100%; font-size: initial; f=
ont-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73=
, 125); text-align: initial; background-color: rgb(255, 255, 255);"><br sty=
le=3D"display:initial"></div> =
=
<=
div style=3D"font-size: initial; font-family: Calibri, 'Slate Pro', sans-se=
rif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-c=
olor: rgb(255, 255, 255);">Sent from my BlackBerry port=
able Babbage Device</div> =
=
<table width=
=3D"100%" style=3D"background-color:white;border-spacing:0px;"> <tbody><tr>=
<td colspan=3D"2" style=3D"font-size: initial; text-align: initial; backgro=
und-color: rgb(255, 255, 255);"> <div style=3D"bo=
rder-style: solid none none; border-top-color: rgb(181, 196, 223); border-t=
op-width: 1pt; padding: 3pt 0in 0in; font-family: Tahoma, 'BB Alpha Sans', =
'Slate Pro'; font-size: 10pt;"> <div><b>From: </b>Arthur O'Dwyer</div><div=
><b>Sent: </b>Sunday, January 3, 2016 4:43 PM</div><div><b>To: </b>ISO C++ =
Standard - Future Proposals</div><div><b>Reply To: </b>std-proposals@isocpp=
..org</div><div><b>Subject: </b>Re: [std-proposals] Re: comment on P0013R1 L=
ogical Operator Type Traits</div></div></td></tr></tbody></table><div style=
=3D"border-style: solid none none; border-top-color: rgb(186, 188, 209); bo=
rder-top-width: 1pt; font-size: initial; text-align: initial; background-co=
lor: rgb(255, 255, 255);"></div><br><div id=3D"_originalContent" style=3D""=
><div dir=3D"ltr"><br><br>On Saturday, January 2, 2016 at 6:11:11 PM UTC-8,=
Zhihao Yuan wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Sat, Jan=
2, 2016 at 3:51 PM, Bo Persson <<a href=3D"javascript:" target=3D"_blan=
k" gdf-obfuscated-mailto=3D"q9CGYK2aEgAJ" rel=3D"nofollow" onmousedown=3D"t=
his.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:'=
;return true;">b...@gmb.dk</a>> wrote:
<br>>>
<br>>> // logical conjunction:
<br>>> template<class... B> struct conjunction;
<br>>>
<br>>> // logical disjunction:
<br>>> template<class... B> struct disjunction;
<br>>
<br>> Guess I will not use these much, as I don't understand what it mea=
ns. :-(
<br>
<br>Am I the only person who reallY love those names?... </blockquote>=
<div><br></div><div>Like Patrice, I was in the room when the bikeshedding o=
f these names happened. My recollection of the discussion was that a lot of=
people were in favor of C++'s acquiring a whole "meta" library, basically =
by adopting MPL or Hana or something along those lines. This would be named=
something like</div><div>- std::meta::plus<br></div><div>- std::meta::minu=
s</div><div>- std::meta::multiplies</div><div>- std::meta::divides</div><di=
v>- std::meta::logical_and <=3D=3D HERE<br></div><div>- std::meta:=
:logical_or <=3D=3D HERE<br></div><div>- std::meta::bit_and<br></d=
iv><div>- std::meta::bit_or</div><div><div>- std::meta::bit_xor</div></div>=
<div>...</div><div><br></div><div>defined in such a way that for example st=
d::is_same< std::meta::plus<std::integral_constant<int, 1>, std=
::integral_constant<int, 2>>, std::integral_constant<int, 3>=
>::value =3D=3D true.</div><div><br></div><div>"HERE" are the two funct=
ions whose names we were bikeshedding.</div><div>However, there was (and is=
) no proposal on the table for such a comprehensive "meta" library.</div><d=
iv><br></div><div>So the basic question was, do we want to start such a lib=
rary right this instant by standardizing meta::logical_and and meta::logica=
l_or without any of the rest of it, or do we want to punt on the larger que=
stion (awaiting a proposal) and just standardize the tools people are askin=
g for today, under names that definitely won't get in the way of any future=
"meta::" standardization efforts?</div><div><br></div><div>Given that C++ =
has already standardized "if_" under the name "std::conditional", it seems =
pretty reasonable to me to standardize "and_" as "std::conjunction" and "or=
_" as "std::disjunction". Anyone who seriously wants to use these metafunct=
ions will certainly do something like</div><div><br></div><div><div>templat=
e<typename... T> using and_ =3D std::conjunction<T...>;</div></=
div><div><div>template<typename... T> using or_ =3D std::disjunction&=
lt;T...>;</div></div><div><br></div><div>anyway, so it's not getting in =
the way of real library programmers. The obscure-sounding name also keeps i=
t out of the hands of programmers who *don't* need or want it. This family =
of types is not on the same level of "new-programmer-usefulness" as std::le=
ss =E2=80=94 not even on the same level as std::plus =E2=80=94 not even on =
the same level as std::conditional, IMHO =E2=80=94 and therefore it's almos=
t a feature, not a bug, that its name is so forbidding.</div><div><br></div=
><div>=E2=80=93Arthur</div></div>
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br>
<br><!--end of _originalContent --></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
.
Author: Robert Ramey <ramey@rrsd.com>
Date: Sun, 3 Jan 2016 15:50:56 -0800
Raw View
On 1/3/16 1:43 PM, Arthur O'Dwyer wrote:
>
>
> On Saturday, January 2, 2016 at 6:11:11 PM UTC-8, Zhihao Yuan wrote:
>
> Am I the only person who reallY love those names?... d
hmmm - is it possible that you are the only person in
the discussion who speaks chinese?
> Like Patrice, I was in the room when the bikeshedding of these names
> happened. My recollection of the discussion was that a lot of people
> were in favor of C++'s acquiring a whole "meta" library, basically by
> adopting MPL or Hana or something along those lines. This would be named
> something like
> - std::meta::plus
> - std::meta::minus
> - std::meta::multiplies
> - std::meta::divides
> - std::meta::logical_and <=3D=3D HERE
> - std::meta::logical_or <=3D=3D HERE
> - std::meta::bit_and
> - std::meta::bit_or
> - std::meta::bit_xor
> ...
Actually, this points to another thing that will be coming up soon -
the std namespace. Seems to me that we'll need some more space.
We're adding ranges, and asio etc. Seems that some people like meta
doesn't this suggest that we'll need some sub namespaces inside of std?
I don't have much to say her other than just ask the question
> defined in such a way that for example std::is_same<
> std::meta::plus<std::integral_constant<int, 1>,
> std::integral_constant<int, 2>>, std::integral_constant<int, 3> >::value
> =3D=3D true.
It's not clear to me that we need plus/minus, etc anymore now that
we have constexpr which seems to me to have made these obsolete.
What am I missing here?
> Given that C++ has already standardized "if_" under the name
> "std::conditional", it seems pretty reasonable to me to standardize
> "and_" as "std::conjunction" and "or_" as "std::disjunction".
LOL - I never heard of "std::conditional" and I've been working
exclusively in metaprogramming for a year! I've been using boost::if.
I was wondering when boost::if would be available in the standard
library. Now I see it's been in there since C++11. And I see it's
in the lasted (1400 page) book on my shelf. Perhaps C++ is just
getting too big?
Anyone who
> seriously wants to use these metafunctions will certainly do something li=
ke
>
> template<typename... T> using and_ =3D std::conjunction<T...>;
> template<typename... T> using or_ =3D std::disjunction<T...>;
aaaa - that sounds like an argument against rather than for the
current names.
> anyway, so it's not getting in the way of real library programmers. The
> obscure-sounding name also keeps it out of the hands of programmers who
> *don't* need or want it. This family of types is not on the same level
> of "new-programmer-usefulness" as std::less =E2=80=94 not even on the sam=
e level
> as std::plus =E2=80=94 not even on the same level as std::conditional, IM=
HO =E2=80=94
> and therefore it's almost a feature, not a bug, that its name is so
> forbidding.
By that criteria, you guys have done a hell of a job! Maybe you
can pursue this to the point that one can only use the language
if he's on the committee!
Robert Ramey
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Mon, 4 Jan 2016 01:15:20 +0100
Raw View
Le 04/01/2016 00:50, Robert Ramey a =C3=A9crit :
> On 1/3/16 1:43 PM, Arthur O'Dwyer wrote:
>>
>>
>> On Saturday, January 2, 2016 at 6:11:11 PM UTC-8, Zhihao Yuan wrote:
>>
>> Am I the only person who reallY love those names?... d
> hmmm - is it possible that you are the only person in
> the discussion who speaks chinese?
>
I don't speak Chinese and I like them :)
Vicente
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 4 Jan 2016 03:17:45 +0200
Raw View
On 3 January 2016 at 23:43, Arthur O'Dwyer <arthur.j.odwyer@gmail.com> wrot=
e:
> Like Patrice, I was in the room when the bikeshedding of these names
> happened. My recollection of the discussion was that a lot of people were=
in
> favor of C++'s acquiring a whole "meta" library, basically by adopting MP=
L
> or Hana or something along those lines. This would be named something lik=
e
> - std::meta::plus
> - std::meta::minus
> - std::meta::multiplies
> - std::meta::divides
> - std::meta::logical_and <=3D=3D HERE
> - std::meta::logical_or <=3D=3D HERE
> - std::meta::bit_and
> - std::meta::bit_or
> - std::meta::bit_xor
> ...
>
> defined in such a way that for example std::is_same<
> std::meta::plus<std::integral_constant<int, 1>, std::integral_constant<in=
t,
> 2>>, std::integral_constant<int, 3> >::value =3D=3D true.
>
> "HERE" are the two functions whose names we were bikeshedding.
> However, there was (and is) no proposal on the table for such a
> comprehensive "meta" library.
>
> So the basic question was, do we want to start such a library right this
> instant by standardizing meta::logical_and and meta::logical_or without a=
ny
> of the rest of it, or do we want to punt on the larger question (awaiting=
a
> proposal) and just standardize the tools people are asking for today, und=
er
> names that definitely won't get in the way of any future "meta::"
> standardization efforts?
>
> Given that C++ has already standardized "if_" under the name
> "std::conditional", it seems pretty reasonable to me to standardize "and_=
"
> as "std::conjunction" and "or_" as "std::disjunction". Anyone who serious=
ly
> wants to use these metafunctions will certainly do something like
>
> template<typename... T> using and_ =3D std::conjunction<T...>;
> template<typename... T> using or_ =3D std::disjunction<T...>;
>
> anyway, so it's not getting in the way of real library programmers. The
> obscure-sounding name also keeps it out of the hands of programmers who
> *don't* need or want it. This family of types is not on the same level of
Sounds like a very plausible explanation, and I suppose my reaction for all=
of
that is "ok then". :)
> "new-programmer-usefulness" as std::less =E2=80=94 not even on the same l=
evel as
> std::plus =E2=80=94 not even on the same level as std::conditional, IMHO =
=E2=80=94 and
> therefore it's almost a feature, not a bug, that its name is so forbiddin=
g.
I don't know about "new-programmer usefulness", and why that comes up, beca=
use
that's not the audience of std::conjunction. In addition to providing
a very nice non-intrusive
solution to the problem "why is this and that trait variadic? should
we make them variadic?",
it also provides very handy shortcut semantics so that when it does
shortcut, the remaining
parameters are not even instantiated completely, let alone evaluated.
In certain metaprogramming
realms(*), that's incredibly useful. I have such facilities internal
to libstdc++, so just in case
other programmers find such facilities useful and want to use them
portably, I was plenty happy
to see a proposal to standardize them. At any rate, it's no novice
tool. It's a metaprogramming
building block, a building block far more capable than the other
things you mentioned. A building
block far more capable than its hang-around friends disjunction and
negation, which are there
hanging around just because it would've been daft to omit them when
providing their much more
capable friend.
(*) Just anecdotally, in those realms, std::less, std::plus and
std::conditional don't occur much
at all, whereas conjunctions and negations are everywhere.
Now, do I expect users to use std::conjunction often? No. In fact I'd
rather hope they don't,
especially for many cases where Concepts will provide saner
approaches. For the cases where
its use is deemed necessary, I think it's good to have it in the
standard, because reimplementing its
functionality from scratch is quite non-trivial. Its actual name in
the standard is far far less important
than having it portably available, as far as I am concerned.
Finally, to everybody who says "yes, but in boost::mpl and in other
metaprogramming libraries,
the facility has a much shorter/convenient name", do remember that
when boost::mpl and other
such libraries came about, C++ didn't have constexpr. There's a vast
amount of enable_if
cases that do not need a logical trait, they can just do enable_if_t<foo &&=
bar>
instead of using std::conjunction there, and there's a vast amount of
"yes, but I need a type"
cases where bool_constant<foo && bar> works just fine without any need
for std::conjunction
there either. There are cases where such techniques do NOT work, and
those cases are
a large part of the motivation for std::conjunction; it's NOT a mere
meta-spelling of a logical
and - it's ideally to be used when other similar-ish tools are not
sufficient, not just whenever
a user needs a logical and at compile-time.
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 4 Jan 2016 03:20:39 +0200
Raw View
On 4 January 2016 at 03:17, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> that's not the audience of std::conjunction. In addition to providing
> a very nice non-intrusive
> solution to the problem "why is this and that trait variadic? should
> we make them variadic?",
And yes, for what it's worth, that first occurrence of "variadic" is
missing a std::negation.
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Sam Kellett <samkellett@gmail.com>
Date: Mon, 4 Jan 2016 08:14:11 +0000
Raw View
--001a1142507eb1983705287db486
Content-Type: text/plain; charset=UTF-8
On 4 January 2016 at 01:17, Ville Voutilainen <ville.voutilainen@gmail.com>
wrote:
> [snip]
>
>
Finally, to everybody who says "yes, but in boost::mpl and in other
> metaprogramming libraries,
> the facility has a much shorter/convenient name", do remember that
> when boost::mpl and other
> such libraries came about, C++ didn't have constexpr. There's a vast
> amount of enable_if
> cases that do not need a logical trait, they can just do enable_if_t<foo
> && bar>
> instead of using std::conjunction there, and there's a vast amount of
> "yes, but I need a type"
> cases where bool_constant<foo && bar> works just fine without any need
> for std::conjunction
> there either. There are cases where such techniques do NOT work, and
> those cases are
> a large part of the motivation for std::conjunction; it's NOT a mere
> meta-spelling of a logical
> and - it's ideally to be used when other similar-ish tools are not
> sufficient, not just whenever
> a user needs a logical and at compile-time.
>
is there anything that std::conjunction and std::disjunction can do that
c++17's fold expressions can't do?
like... is this valid for example: std::bool_constant<std::is_same<int,
Ts>{} && ...> ?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a1142507eb1983705287db486
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 4 January 2016 at 01:17, Ville Voutilainen <span dir=3D=
"ltr"><<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">=
ville.voutilainen@gmail.com</a>></span> wrote:<br><div class=3D"gmail_ex=
tra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex">[snip]<br></blockquote><blockquote style=3D"margin:0px 0px 0px 0.8ex=
;border-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_qu=
ote"><div>=C2=A0</div></blockquote><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div>
Finally, to everybody who says "yes, but in boost::mpl and in other<br=
>
metaprogramming libraries,<br>
the facility has a much shorter/convenient name", do remember that<br>
when boost::mpl and other<br>
such libraries came about, C++ didn't have constexpr. There's a vas=
t<br>
amount of enable_if<br>
cases that do not need a logical trait, they can just do enable_if_t<foo=
&& bar><br>
instead of using std::conjunction there, and there's a vast amount of<b=
r>
"yes, but I need a type"<br>
cases where bool_constant<foo && bar> works just fine without=
any need<br>
for std::conjunction<br>
there either. There are cases where such techniques do NOT work, and<br>
those cases are<br>
a large part of the motivation for std::conjunction; it's NOT a mere<br=
>
meta-spelling of a logical<br>
and - it's ideally to be used when other similar-ish tools are not<br>
sufficient, not just whenever<br>
a user needs a logical and at compile-time.<br>
</div></blockquote><div><br></div><div>is there anything that std::conjunct=
ion and std::disjunction can do that c++17's fold expressions can't=
do?<br><br></div><div>like... is this valid for example: std::bool_constan=
t<std::is_same<int, Ts>{} && ...> ? <br></div></div><br=
></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--001a1142507eb1983705287db486--
.
Author: =?UTF-8?Q?Agust=c3=adn_K-ballo_Berg=c3=a9?= <kaballo86@hotmail.com>
Date: Mon, 4 Jan 2016 09:44:47 -0300
Raw View
On 1/4/2016 5:14 AM, Sam Kellett wrote:
> On 4 January 2016 at 01:17, Ville Voutilainen
> <ville.voutilainen@gmail.com <mailto:ville.voutilainen@gmail.com>> wrote:
>
> [snip]
>
> Finally, to everybody who says "yes, but in boost::mpl and in other
> metaprogramming libraries,
> the facility has a much shorter/convenient name", do remember that
> when boost::mpl and other
> such libraries came about, C++ didn't have constexpr. There's a vast
> amount of enable_if
> cases that do not need a logical trait, they can just do
> enable_if_t<foo && bar>
> instead of using std::conjunction there, and there's a vast amount of
> "yes, but I need a type"
> cases where bool_constant<foo && bar> works just fine without any nee=
d
> for std::conjunction
> there either. There are cases where such techniques do NOT work, and
> those cases are
> a large part of the motivation for std::conjunction; it's NOT a mere
> meta-spelling of a logical
> and - it's ideally to be used when other similar-ish tools are not
> sufficient, not just whenever
> a user needs a logical and at compile-time.
>
>
> is there anything that std::conjunction and std::disjunction can do that
> c++17's fold expressions can't do?
They will short-circuit (template instantiations), as the the email you=20
are replying to says (you cut too much). Check out the design decisions=20
section of the paper for more details:=20
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0013r1.html#design
> like... is this valid for example: std::bool_constant<std::is_same<int,
> Ts>{} && ...> ?
No, you need parens: std::bool_constant<(std::is_same<int, Ts>{} && ...)>
This does not, however, look like a place were you'd want to use=20
`conjunction` at all. There are no requirements in `std::is_same`, and=20
its instantiation should be really cheap (just an alias, with just one=20
trivial template specialization, no `Ts` is ever instantiated).
As Ville said, `conjunction` is not intended as a mere wrapped logical=20
operator. There would be no point in that, if you can do with a logical=20
operator, like above, then just use a logical operator.
Regards,
--=20
Agust=C3=ADn K-ballo Berg=C3=A9.-
http://talesofcpp.fusionfenix.com
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
.
Author: Sam Kellett <samkellett@gmail.com>
Date: Mon, 4 Jan 2016 13:51:42 +0000
Raw View
--047d7b34318ac053870528826b77
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 4 January 2016 at 12:44, Agust=C3=ADn K-ballo Berg=C3=A9 <kaballo86@hotm=
ail.com>
wrote:
> On 1/4/2016 5:14 AM, Sam Kellett wrote:
>
>> On 4 January 2016 at 01:17, Ville Voutilainen
>> <ville.voutilainen@gmail.com <mailto:ville.voutilainen@gmail.com>> wrote=
:
>>
>> [snip]
>>
>> Finally, to everybody who says "yes, but in boost::mpl and in other
>> metaprogramming libraries,
>> the facility has a much shorter/convenient name", do remember that
>> when boost::mpl and other
>> such libraries came about, C++ didn't have constexpr. There's a vast
>> amount of enable_if
>> cases that do not need a logical trait, they can just do
>> enable_if_t<foo && bar>
>> instead of using std::conjunction there, and there's a vast amount o=
f
>> "yes, but I need a type"
>> cases where bool_constant<foo && bar> works just fine without any ne=
ed
>> for std::conjunction
>> there either. There are cases where such techniques do NOT work, and
>> those cases are
>> a large part of the motivation for std::conjunction; it's NOT a mere
>> meta-spelling of a logical
>> and - it's ideally to be used when other similar-ish tools are not
>> sufficient, not just whenever
>> a user needs a logical and at compile-time.
>>
>>
>> is there anything that std::conjunction and std::disjunction can do that
>> c++17's fold expressions can't do?
>>
>
> They will short-circuit (template instantiations), as the the email you
> are replying to says (you cut too much). Check out the design decisions
> section of the paper for more details:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0013r1.html#desi=
gn
>
right thanks for letting me know.
> like... is this valid for example: std::bool_constant<std::is_same<int,
>> Ts>{} && ...> ?
>>
>
> No, you need parens: std::bool_constant<(std::is_same<int, Ts>{} && ...)>
>
> This does not, however, look like a place were you'd want to use
> `conjunction` at all. There are no requirements in `std::is_same`, and it=
s
> instantiation should be really cheap (just an alias, with just one trivia=
l
> template specialization, no `Ts` is ever instantiated).
>
> As Ville said, `conjunction` is not intended as a mere wrapped logical
> operator. There would be no point in that, if you can do with a logical
> operator, like above, then just use a logical operator.
>
sorry i thought i was pulling that example from the paper but i've
obviously gotten it mashed up with ville's example without thinking. here's
what i meant (with your brackets added in):
// Accepts zero or more arguments of type int.
template <typename... Ts>
enable_if_t<(is_same<int, Ts> && ...)> >
func(Ts...)
{ }
adapted from the example in "Motivation and Scope" from P0013R1... but yeah
the short-circuiting comment still applies of course.
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--047d7b34318ac053870528826b77
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On 4 January 2016 at 12:44, Agust=C3=ADn K-ballo Berg=C3=A9 <span dir=
=3D"ltr"><<a href=3D"mailto:kaballo86@hotmail.com" target=3D"_blank">kab=
allo86@hotmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex"><span class=3D"">On 1/4/2016 5:14 AM, Sam Kellett wrote:=
<br>
</span><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=3D"">
On 4 January 2016 at 01:17, Ville Voutilainen<br></span><span class=3D"">
<<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.=
voutilainen@gmail.com</a> <mailto:<a href=3D"mailto:ville.voutilainen@gm=
ail.com" target=3D"_blank">ville.voutilainen@gmail.com</a>>> wrote:<b=
r>
<br>
=C2=A0 =C2=A0 [snip]<br>
<br>
=C2=A0 =C2=A0 Finally, to everybody who says "yes, but in boost::mpl a=
nd in other<br>
=C2=A0 =C2=A0 metaprogramming libraries,<br>
=C2=A0 =C2=A0 the facility has a much shorter/convenient name", do rem=
ember that<br>
=C2=A0 =C2=A0 when boost::mpl and other<br>
=C2=A0 =C2=A0 such libraries came about, C++ didn't have constexpr. The=
re's a vast<br>
=C2=A0 =C2=A0 amount of enable_if<br>
=C2=A0 =C2=A0 cases that do not need a logical trait, they can just do<br>
=C2=A0 =C2=A0 enable_if_t<foo && bar><br>
=C2=A0 =C2=A0 instead of using std::conjunction there, and there's a va=
st amount of<br>
=C2=A0 =C2=A0 "yes, but I need a type"<br>
=C2=A0 =C2=A0 cases where bool_constant<foo && bar> works jus=
t fine without any need<br>
=C2=A0 =C2=A0 for std::conjunction<br>
=C2=A0 =C2=A0 there either. There are cases where such techniques do NOT wo=
rk, and<br>
=C2=A0 =C2=A0 those cases are<br>
=C2=A0 =C2=A0 a large part of the motivation for std::conjunction; it's=
NOT a mere<br>
=C2=A0 =C2=A0 meta-spelling of a logical<br>
=C2=A0 =C2=A0 and - it's ideally to be used when other similar-ish tool=
s are not<br>
=C2=A0 =C2=A0 sufficient, not just whenever<br>
=C2=A0 =C2=A0 a user needs a logical and at compile-time.<br>
<br>
<br>
is there anything that std::conjunction and std::disjunction can do that<br=
>
c++17's fold expressions can't do?<br>
</span></blockquote>
<br>
They will short-circuit (template instantiations), as the the email you are=
replying to says (you cut too much). Check out the design decisions sectio=
n of the paper for more details: <a href=3D"http://www.open-std.org/jtc1/sc=
22/wg21/docs/papers/2015/p0013r1.html#design" rel=3D"noreferrer" target=3D"=
_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0013r1.htm=
l#design</a><span class=3D""><br></span></blockquote><div><br></div><div>ri=
ght thanks for letting me know. <br></div><div><br>=C2=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex"><span class=3D"">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">
like... is this valid for example: std::bool_constant<std::is_same<in=
t,<br>
Ts>{} && ...> ?<br>
</blockquote>
<br></span>
No, you need parens: std::bool_constant<(std::is_same<int, Ts>{} &=
amp;& ...)><br>
<br>
This does not, however, look like a place were you'd want to use `conju=
nction` at all. There are no requirements in `std::is_same`, and its instan=
tiation should be really cheap (just an alias, with just one trivial templa=
te specialization, no `Ts` is ever instantiated).<br>
<br>
As Ville said, `conjunction` is not intended as a mere wrapped logical oper=
ator. There would be no point in that, if you can do with a logical operato=
r, like above, then just use a logical operator.<br></blockquote><div><br><=
/div><div>sorry i thought i was pulling that example from the paper but i&#=
39;ve obviously gotten it mashed up with ville's example without thinki=
ng. here's what i meant (with your brackets added in):<br><br></div><di=
v>// Accepts zero or more arguments of type int.<br></div><div>template <=
;typename... Ts><br></div><div>=C2=A0 enable_if_t<(is_same<int, Ts=
> && ...)> ><br></div><div>=C2=A0 func(Ts...)<br>=C2=A0 { =
}<br><br></div><div>adapted from the example in "Motivation and Scope&=
quot; from P0013R1... but yeah the short-circuiting comment still applies o=
f course.<br><br></div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--047d7b34318ac053870528826b77--
.
Author: Morwenn <morwenn29@gmail.com>
Date: Mon, 4 Jan 2016 11:33:06 -0800 (PST)
Raw View
------=_Part_573_1171940804.1451935986278
Content-Type: multipart/alternative;
boundary="----=_Part_574_235634496.1451935986279"
------=_Part_574_235634496.1451935986279
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
If you ever need the opinion of more people: I like the chosen names. I=20
think those are the ones I prefer amongst all the proposed ones.
It probably has to do with the fact that I don't like standardized names=20
with a leading or trailing underscore.
Also, these names are easy to look for in a codebase and unambiguous.
Le samedi 2 janvier 2016 19:34:20 UTC+1, Robert Ramey a =C3=A9crit :
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0013r1.html=20
>
> Quoth Ville: "__and_, __or_ and __not_ as they are already available in=
=20
> libstdc++ are an absolute godsend, not just for a library writer, but=20
> for any user who needs to do metaprogramming with parameter packs.=20
> Boost.MPL has shipped similar facilities for a very long time, and it's=
=20
> high time we standardize these simple utilities."=20
>
> "The traits were originally proposed with the obvious names, "and", "or"=
=20
> and "not", adjusted to avoid clashing with the alternative tokens of the=
=20
> same names. Another option would have been static_and but the context=20
> and angle brackets should be enough to make it obvious these are=20
> templates that are evaluated at compile-time, and the shorter names are=
=20
> easier to read. LEWG discussed a number of names, and the eventual=20
> preference was for longer names, without a trailing underscore."=20
>
> Indeed these have been in Boost for a very long time. My question is=20
> why change the names at this point. Tons of code have and, or and not=20
> and now we're going to get a set of completely different names. It=20
> is some much more intuitive to replace current code=20
>
> boost::mpl::if_c<=20
> boost::mpl::and<=20
> ...=20
> >::value,=20
> ...,=20
> ...=20
> >=20
>
> with=20
>
> boost::mpl::if_c<=20
> std::and<=20
> ...=20
> >::value,=20
> ...,=20
> ...=20
> >=20
>
> Robert Ramey=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
------=_Part_574_235634496.1451935986279
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">If you ever need the opinion of more people: I like the ch=
osen names. I think those are the ones I prefer amongst all the proposed on=
es.<br>It probably has to do with the fact that I don't like standardiz=
ed names with a leading or trailing underscore.<br><br>Also, these names ar=
e easy to look for in a codebase and unambiguous.<br><br>Le samedi 2 janvie=
r 2016 19:34:20 UTC+1, Robert Ramey a =C3=A9crit=C2=A0:<blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/=
docs/papers/2015/p0013r1.html" target=3D"_blank" rel=3D"nofollow" onmousedo=
wn=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.open-=
std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fp0013r1.html\46sa\75D=
\46sntz\0751\46usg\75AFQjCNHrhD3oGJRVXphYJvzGExp6I3jexQ';return true;" =
onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.=
open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fp0013r1.html\46s=
a\75D\46sntz\0751\46usg\75AFQjCNHrhD3oGJRVXphYJvzGExp6I3jexQ';return tr=
ue;">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2015/<wbr>p001=
3r1.html</a>
<br>
<br>Quoth Ville: "__and_, __or_ and __not_ as they are already availab=
le in=20
<br>libstdc++ are an absolute godsend, not just for a library writer, but=
=20
<br>for any user who needs to do metaprogramming with parameter packs.=20
<br>Boost.MPL has shipped similar facilities for a very long time, and it&#=
39;s=20
<br>high time we standardize these simple utilities."
<br>
<br>"The traits were originally proposed with the obvious names, "=
;and", "or"=20
<br>and "not", adjusted to avoid clashing with the alternative to=
kens of the=20
<br>same names. Another option would have been static_and but the context=
=20
<br>and angle brackets should be enough to make it obvious these are=20
<br>templates that are evaluated at compile-time, and the shorter names are=
=20
<br>easier to read. LEWG discussed a number of names, and the eventual=20
<br>preference was for longer names, without a trailing underscore."
<br>
<br>Indeed these have been in Boost for a very long time. =C2=A0My question=
is
<br>why change the names at this point. =C2=A0Tons of code have and, or and=
not
<br>and now we're going to get a set of completely different names. =C2=
=A0It
<br>is some much more intuitive to replace current code
<br>
<br>boost::mpl::if_c<
<br>=C2=A0 =C2=A0 =C2=A0boost::mpl::and<
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...
<br>=C2=A0 =C2=A0 =C2=A0>::value,
<br>=C2=A0 =C2=A0 =C2=A0...,
<br>=C2=A0 =C2=A0 =C2=A0...
<br>=C2=A0>
<br>
<br>with
<br>
<br>boost::mpl::if_c<
<br>=C2=A0 =C2=A0 =C2=A0std::and<
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...
<br>=C2=A0 =C2=A0 =C2=A0>::value,
<br>=C2=A0 =C2=A0 =C2=A0...,
<br>=C2=A0 =C2=A0 =C2=A0...
<br>=C2=A0>
<br>
<br>Robert Ramey
<br>
<br>
<br>
<br></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_574_235634496.1451935986279--
------=_Part_573_1171940804.1451935986278--
.
Author: "'Jeffrey Yasskin' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Mon, 4 Jan 2016 14:22:40 -0800
Raw View
--047d7b4184034993cc0528899072
Content-Type: text/plain; charset=UTF-8
On Sun, Jan 3, 2016 at 1:43 PM, Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
wrote:
>
>
> On Saturday, January 2, 2016 at 6:11:11 PM UTC-8, Zhihao Yuan wrote:
>>
>> On Sat, Jan 2, 2016 at 3:51 PM, Bo Persson <b...@gmb.dk> wrote:
>> >>
>> >> // logical conjunction:
>> >> template<class... B> struct conjunction;
>> >>
>> >> // logical disjunction:
>> >> template<class... B> struct disjunction;
>> >
>> > Guess I will not use these much, as I don't understand what it means.
>> :-(
>>
>> Am I the only person who reallY love those names?...
>
>
> Like Patrice, I was in the room when the bikeshedding of these names
> happened. My recollection of the discussion was that a lot of people were
> in favor of C++'s acquiring a whole "meta" library, basically by adopting
> MPL or Hana or something along those lines. This would be named something
> like
> - std::meta::plus
> - std::meta::minus
> - std::meta::multiplies
> - std::meta::divides
> - std::meta::logical_and <== HERE
> - std::meta::logical_or <== HERE
> - std::meta::bit_and
> - std::meta::bit_or
> - std::meta::bit_xor
> ...
>
> defined in such a way that for example std::is_same<
> std::meta::plus<std::integral_constant<int, 1>, std::integral_constant<int,
> 2>>, std::integral_constant<int, 3> >::value == true.
>
> "HERE" are the two functions whose names we were bikeshedding.
> However, there was (and is) no proposal on the table for such a
> comprehensive "meta" library.
>
> So the basic question was, do we want to start such a library right this
> instant by standardizing meta::logical_and and meta::logical_or without any
> of the rest of it, or do we want to punt on the larger question (awaiting a
> proposal) and just standardize the tools people are asking for today, under
> names that definitely won't get in the way of any future "meta::"
> standardization efforts?
>
That's what I remember too, and I think Eric volunteered to write a paper
proposing the beginning of the meta:: library.
Jeffrey
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7b4184034993cc0528899072
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Jan 3, 2016 at 1:43 PM, Arthur O'Dwyer <span dir=3D"ltr"><<a hre=
f=3D"mailto:arthur.j.odwyer@gmail.com" target=3D"_blank" class=3D"cremed">a=
rthur.j.odwyer@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><br><br>On Saturday, January 2, 2016 at 6:11:11 PM U=
TC-8, Zhihao Yuan wrote:<span class=3D""><blockquote class=3D"gmail_quote" =
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left=
:1ex">On Sat, Jan 2, 2016 at 3:51 PM, Bo Persson <<a rel=3D"nofollow" cl=
ass=3D"cremed">b...@gmb.dk</a>> wrote:
<br>>>
<br>>> // logical conjunction:
<br>>> template<class... B> struct conjunction;
<br>>>
<br>>> // logical disjunction:
<br>>> template<class... B> struct disjunction;
<br>>
<br>> Guess I will not use these much, as I don't understand what it=
means. =C2=A0:-(
<br>
<br>Am I the only person who reallY love those names?...=C2=A0</blockquote>=
<div><br></div></span><div>Like Patrice, I was in the room when the bikeshe=
dding of these names happened. My recollection of the discussion was that a=
lot of people were in favor of C++'s acquiring a whole "meta"=
; library, basically by adopting MPL or Hana or something along those lines=
.. This would be named something like</div><div>- std::meta::plus<br></div><=
div>- std::meta::minus</div><div>- std::meta::multiplies</div><div>- std::m=
eta::divides</div><div>- std::meta::logical_and =C2=A0<=3D=3D HERE<br></=
div><div>- std::meta::logical_or =C2=A0<=3D=3D HERE<br></div><div>- std:=
:meta::bit_and<br></div><div>- std::meta::bit_or</div><div><div>- std::meta=
::bit_xor</div></div><div>...</div><div><br></div><div>defined in such a wa=
y that for example std::is_same< std::meta::plus<std::integral_consta=
nt<int, 1>, std::integral_constant<int, 2>>, std::integral_c=
onstant<int, 3> >::value =3D=3D true.</div><div><br></div><div>&qu=
ot;HERE" are the two functions whose names we were bikeshedding.</div>=
<div>However, there was (and is) no proposal on the table for such a compre=
hensive "meta" library.</div><div><br></div><div>So the basic que=
stion was, do we want to start such a library right this instant by standar=
dizing meta::logical_and and meta::logical_or without any of the rest of it=
, or do we want to punt on the larger question (awaiting a proposal) and ju=
st standardize the tools people are asking for today, under names that defi=
nitely won't get in the way of any future "meta::" standardiz=
ation efforts?</div></div></blockquote><div><br></div></div>That's what=
I remember too, and I think Eric volunteered to write a paper proposing th=
e beginning of the meta:: library.</div><div class=3D"gmail_extra"><br></di=
v><div class=3D"gmail_extra">Jeffrey</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--047d7b4184034993cc0528899072--
.