------=_Part_335_4389183.1362869914253
Content-Type: text/plain; charset=ISO-8859-1

Hello.

That's just an idea and I haven't found anything about it until now, but I
sometimes got the need to have some of the trait classes from the<type_traits>header variadic.
For example, I sometimes wanted to constrain multiple arguments of a
function to be integral, so I had to write:

template<typename T, typename U, typename = typename
std::enable_if<std::is_integral<T>::value && std::is_integral<U>::value,
void>::type>
auto dummy(T a, U b)
    -> typename std::common_type<T, U>::type;

....while having a variadic std::is_integral<> would have allowed me to
write:

template<typename T, typename U, typename = typename
std::enable_if<std::is_integral<T, U>::value, void>::type>
auto dummy(T a, U b)
    -> typename std::common_type<T, U>::type;

....which is shorter and not less expressive. It does not break any existing
code and just require a really simple library addition to overload the
traits (not sure it would be useful for all of them, but we never know).
Moreover, it would also allow to check if a parameter pack is just made of
integers or not at once and not only for a few values.

IMHO, it would be useful, simple to understand and simple to implement 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_335_4389183.1362869914253
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello.<br><br>That's just an idea and I haven't found anything about it unt=
il now, but I sometimes got the need to have some of the trait classes from=
 the<span style=3D"font-family: courier new,monospace;"> &lt;type_traits&gt=
;</span> header variadic.<br>For example, I sometimes wanted to constrain m=
ultiple arguments of a function to be integral, so I had to write:<br><br><=
span style=3D"font-family: courier new,monospace;">template&lt;typename T, =
typename U, typename =3D typename std::enable_if&lt;std::is_integral&lt;T&g=
t;::value &amp;&amp; std::is_integral&lt;U&gt;::value, void&gt;::type&gt;<b=
r>auto dummy(T a, U b)<br>&nbsp;&nbsp;&nbsp; -&gt; typename std::common_typ=
e&lt;T, U&gt;::type;</span><br><br>...while having a variadic <span style=
=3D"font-family: courier new,monospace;">std::is_integral&lt;&gt;</span> wo=
uld have allowed me to write:<br><br><span style=3D"font-family: courier ne=
w,monospace;">template&lt;typename T, typename U, typename =3D typename=20
std::enable_if&lt;std::is_integral&lt;T, U&gt;::value, void&gt;::type&gt;<b=
r>auto dummy(T a, U b)<br>&nbsp;&nbsp;&nbsp; -&gt; typename std::common_typ=
e&lt;T, U&gt;::type;</span><br><br>...which is shorter and not less express=
ive. It does not break any existing code and just require a really simple l=
ibrary addition to overload the traits (not sure it would be useful for all=
 of them, but we never know).<br>Moreover, it would also allow to check if =
a parameter pack is just made of integers or not at once and not only for a=
 few values.<br><br>IMHO, it would be useful, simple to understand and simp=
le to implement too :)<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_335_4389183.1362869914253--

.

This is a multi-part message in MIME format.
--------------030709010507050708050707
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

> Hello.
>
> That's just an idea and I haven't found anything about it until now,
> but I sometimes got the need to have some of the trait classes from
> the<type_traits> header variadic.

I see your use, but I wonder if making unary type trait functions
variadic is more confusing than useful.
They are ment to apply to single type, not like Binary type traits which
take two. Also how common is this kind of
use?

Not only that, current standard already allows these traits to take more
than one template argument,
so keeping it compatible is not that easy.


Mikael

--

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



--------------030709010507050708050707
Content-Type: text/html; charset=ISO-8859-1

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <blockquote
      cite="mid:1a8beeda-65f3-412c-a62c-97aadeafa413@isocpp.org"
      type="cite">Hello.<br>
      <br>
      That's just an idea and I haven't found anything about it until
      now, but I sometimes got the need to have some of the trait
      classes from the<span style="font-family: courier new,monospace;">
        &lt;type_traits&gt;</span> header variadic.<br>
    </blockquote>
    <br>
    I see your use, but I wonder if making unary type trait functions
    variadic is more confusing than useful.<br>
    They are ment to apply to single type, not like Binary type traits
    which take two. Also how common is this kind of<br>
    use?<br>
    <br>
    Not only that, current standard already allows these traits to take
    more than one template argument,<br>
    so keeping it compatible is not that easy.<br>
    <br>
    <br>
    Mikael<br>
  </body>
</html>

<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 email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
&nbsp;<br />
&nbsp;<br />

--------------030709010507050708050707--

.

------=_Part_725_9008111.1362872042695
Content-Type: text/plain; charset=ISO-8859-1

I did not see anyone using that actually. That does not mean nobody does,
but it's true that nobody might be using that :)

I was asking because I had to make variadic type traits for some of my
projects where I wanted quite a bit of restrictions
on types. I thought of other names (are_integral, etc...), but I did not
find is_integral confusing, even with more arguments.

I totally forgot about compilers rights to add more default template
arguments while proposing that. I don't see what they
would add to such traits though (seems GCC did not add anything, but I did
not check other compilers).

Well, there is at least one trait where a variadic version could be really
useful in my opinion, it's std::is_same. That would
allow to check whether a variadic function takes only arguments of one type
for example. Useful for diagnostics.

Anyway, I still don't know much about proposals and always forget about
some things they might imply. Sorry for that^^"

--

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

I did not see anyone using that actually. That does not mean nobody does, b=
ut it's true that nobody might be using that :)<br><br>I was asking because=
 I had to make variadic type traits for some of my projects where I wanted =
quite a bit of restrictions<br>on types. I thought of other names (are_inte=
gral, etc...), but I did not find is_integral confusing, even with more arg=
uments.<br><br>I totally forgot about compilers rights to add more default =
template arguments while proposing that. I don't see what they<br>would add=
 to such traits though (seems GCC did not add anything, but I did not check=
 other compilers).<br><br>Well, there is at least one trait where a variadi=
c version could be really useful in my opinion, it's std::is_same. That wou=
ld<br>allow to check whether a variadic function takes only arguments of on=
e type for example. Useful for diagnostics.<br><br>Anyway, I still don't kn=
ow much about proposals and always forget about some things they might impl=
y. Sorry for that^^"<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_725_9008111.1362872042695--

.

> I did not see anyone using that actually. That does not mean nobody
> does, but it's true that nobody might be using that :)
I don't know, but i would like to know how common it is.

>
> I was asking because I had to make variadic type traits for some of my
> projects where I wanted quite a bit of restrictions
> on types. I thought of other names (are_integral, etc...), but I did
> not find is_integral confusing, even with more arguments.
>
Along the lines of

template<template<typename...> class Trait, typename Head, typename... Args>
struct apply {
    static const bool value = Trait<Head>::value && apply<Trait,
Args...>::value;
};
template<template<typename...> class Trait, typename Head>
struct apply<Trait, Head> {
    static const bool value = Trait<Head>::value;
};

Just drafting, one would want to derive from std::integral_constant though.
Could even consider making 'and' template with bool... and applying the
pack to that with wanted trait.

> Well, there is at least one trait where a variadic version could be
> really useful in my opinion, it's std::is_same. That would
> allow to check whether a variadic function takes only arguments of one
> type for example. Useful for diagnostics.
>
Yes, that might be useful indeed.

> Anyway, I still don't know much about proposals and always forget
> about some things they might imply. Sorry for that^^"
No problem, feel free to propose what ever feels useful.


Mikael

--

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

On Sunday, March 10, 2013 12:35:39 AM UTC, Mikael Kilpel=E4inen wrote:
>
> >=20
> Along the lines of=20
>
> template<template<typename...> class Trait, typename Head, typename...=20
> Args>=20
> struct apply {=20
>     static const bool value =3D Trait<Head>::value && apply<Trait,=20
> Args...>::value;=20
> };=20
>

That requires the instantiation of apply<Trait, Args...>::value even if=20
Trait<Head>::value is true, whereas you can make it short-circuit:

template<template<typename...> class Trait, typename Head, typename...=20
Args>=20
struct apply : std::condition<Trait<Head>::value, apply<Trait, Args...>,=20
Trait<Head>>::type
{ };=20
=20

>
> Just drafting, one would want to derive from std::integral_constant=20
> though.=20
> Could even consider making 'and' template with bool... and applying the=
=20
> pack to that with wanted trait.=20
>


In my experience it's more useful to have a generic "and" template taking=
=20
arbitrary traits (not bools) rather than applying a single trait to many=20
arguments:

template<typename... Traits>
struct and_;
template<typename Trait>
struct and_<Trait> : Trait
{ };
template<typename Trait0, typename Trait1, typename... Traits>=20
struct and_<Trait0, Trait1, Traits...>
: std::condition<Trait0::value, and_<Trait1, Traits...>, Trait0>::type
{ };=20

The various options result in this usage:

std::is_integral<T, U>::value
apply<std::_is_integral, T, U>::value
and_<std::is_integral<T>, std::is_integral<U>>::value

Clearly the original suggestion is the shortest, but that's not the best=20
criterion for a proposal. The third one using "and_" is the most general=20
and can be used to implement the other two.

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

On Sunday, March 10, 2013 12:35:39 AM UTC, Mikael Kilpel=E4inen wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">&gt;
<br>Along the lines of
<br>
<br>template&lt;template&lt;typename...&gt; class Trait, typename Head, typ=
ename... Args&gt;
<br>struct apply {
<br>&nbsp; &nbsp; static const bool value =3D Trait&lt;Head&gt;::value &amp=
;&amp; apply&lt;Trait,=20
<br>Args...&gt;::value;
<br>};
<br></blockquote><div><br>That requires the instantiation of=20
apply&lt;Trait, Args...&gt;::value even if Trait&lt;Head&gt;::value is=20
true, whereas you can make it short-circuit:<br><br>template&lt;template&lt=
;typename...&gt; class Trait, typename Head, typename... Args&gt;
<br>struct apply : std::condition&lt;Trait&lt;Head&gt;::value, apply&lt;Tra=
it, Args...&gt;, Trait&lt;Head&gt;&gt;::type<br>{
};
<br></div>&nbsp;<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>Just drafting, one would want to derive from std::integral_constant tho=
ugh.
<br>Could even consider making 'and' template with bool... and applying the=
=20
<br>pack to that with wanted trait.
<br></blockquote><div><br><br>In my experience it's more useful to have a g=
eneric "and"=20
template taking arbitrary traits (not bools) rather than applying a single =
trait to many=20
arguments:<br><br>template&lt;typename... Traits&gt;<br>struct and_;<br>tem=
plate&lt;typename Trait&gt;<br>struct and_&lt;Trait&gt; : Trait<br>{ };<br>=
template&lt;typename Trait0, typename Trait1, typename... Traits&gt;
<br>struct and_&lt;Trait0, Trait1, Traits...&gt;<br>: std::condition&lt;Tra=
it0::value, and_&lt;Trait1, Traits...&gt;, Trait0&gt;::type<br>{
};
<br><br>The various options result in this usage:<br><br>std::is_integral&l=
t;T, U&gt;::value<br>apply&lt;std::_is_integral, T, U&gt;::value<br>and_&lt=
;std::is_integral&lt;T&gt;, std::is_integral&lt;U&gt;&gt;::value<br><br>Cle=
arly
 the original suggestion is the shortest, but that's not the best=20
criterion for a proposal. The third one using "and_" is the most general
 and can be used to implement the other two.<br><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_47_289365.1363094043156--

.

12.3.2013 14:14, Jonathan Wakely kirjoitti:
> That requires the instantiation of apply<Trait, Args...>::value even
> if Trait<Head>::value is true, whereas you can make it short-circuit:
>
Yes, of course. My version was purely meant to show it is already simple
and was in no way proposal for anything.

> In my experience it's more useful to have a generic "and" template
> taking arbitrary traits (not bools) rather than applying a single
> trait to many arguments:
>
> template<typename... Traits>
> struct and_;
> template<typename Trait>
> struct and_<Trait> : Trait
> { };
> template<typename Trait0, typename Trait1, typename... Traits>
> struct and_<Trait0, Trait1, Traits...>
> : std::condition<Trait0::value, and_<Trait1, Traits...>, Trait0>::type
> { };
>
> The various options result in this usage:
>
> std::is_integral<T, U>::value
> apply<std::_is_integral, T, U>::value
> and_<std::is_integral<T>, std::is_integral<U>>::value
>
> Clearly the original suggestion is the shortest, but that's not the
> best criterion for a proposal. The third one using "and_" is the most
> general and can be used to implement the other two.
I would certainly like to see something like this in the standard. I
like your integer sequence proposal a lot and this goes very much the
same direction.


Mikael

--

---
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_1574_33387304.1363136149752
Content-Type: text/plain; charset=ISO-8859-1

> The various options result in this usage:

> >
> > std::is_integral<T, U>::value
> > apply<std::_is_integral, T, U>::value
> > and_<std::is_integral<T>, std::is_integral<U>>::value
> >
> > Clearly the original suggestion is the shortest, but that's not the
> > best criterion for a proposal. The third one using "and_" is the most
> > general and can be used to implement the other two.


Well, you both have a good point about the genericity of the methods.
Between the two of them, I think my favourite
one is the one using apply since it allows to apply the same trait to a
whole range of types at once, and remains easy
to use and short. It also allows to use write apply<std::is_same, Args...>
which could be pretty useful.

and_ is also a good idea, but serves a different purpose IMO. While apply
is good to apply one constraint, _and would
be the short way to apply multiple constraints to multiple parameters.

I still love how you guy can be both creative and efficient to deal with
that kind of problems :)

--

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

&gt; The various options result in this usage:
<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">&gt;
<br>&gt; std::is_integral&lt;T, U&gt;::value
<br>&gt; apply&lt;std::_is_integral, T, U&gt;::value
<br>&gt; and_&lt;std::is_integral&lt;T&gt;, std::is_integral&lt;U&gt;&gt;::=
value
<br>&gt;
<br>&gt; Clearly the original suggestion is the shortest, but that's not th=
e=20
<br>&gt; best criterion for a proposal. The third one using "and_" is the m=
ost=20
<br>&gt; general and can be used to implement the other two.
</blockquote><div>&nbsp;<br>Well, you both have a good point about the gene=
ricity of the methods. Between the two of them, I think my favourite<br></d=
iv><div>one is the one using apply since it allows to apply the same trait =
to a whole range of types at once, and remains easy<br>to use and short. It=
 also allows to use write apply&lt;std::is_same, Args...&gt; which could be=
 pretty useful.<br><br>and_ is also a good idea, but serves a different pur=
pose IMO. While apply is good to apply one constraint, _and would<br>be the=
 short way to apply multiple constraints to multiple parameters.<br><br>I s=
till love how you guy can be both creative and efficient to deal with that =
kind of problems :)<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_1574_33387304.1363136149752--

.

This is a multi-part message in MIME format.
--------------080506040108010301000303
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

13.3.2013 1:55, morwenn29@gmail.com kirjoitti:
> > The various options result in this usage:
>
>     >
>     > std::is_integral<T, U>::value
>     > apply<std::_is_integral, T, U>::value
>     > and_<std::is_integral<T>, std::is_integral<U>>::value
>     >
>     > Clearly the original suggestion is the shortest, but that's not the
>     > best criterion for a proposal. The third one using "and_" is the
>     most
>     > general and can be used to implement the other two.
>
>
> Well, you both have a good point about the genericity of the methods.
> Between the two of them, I think my favourite
> one is the one using apply since it allows to apply the same trait to
> a whole range of types at once, and remains easy
> to use and short. It also allows to use write apply<std::is_same,
> Args...> which could be pretty useful.
>
Notice that the is_same needs two arguments and hence doesn't work out
of the box.
One of the points with and_ is that it can handle range of types, say
with is_integral for example.. and_< std::is_integral<Args>... >.


Mikael

--

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



--------------080506040108010301000303
Content-Type: text/html; charset=ISO-8859-1

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    13.3.2013 1:55, <a class="moz-txt-link-abbreviated" href="mailto:morwenn29@gmail.com">morwenn29@gmail.com</a> kirjoitti:
    <blockquote
      cite="mid:0c8f5964-5312-44b9-ac4e-67bae9bb6280@isocpp.org"
      type="cite">&gt; The various options result in this usage:
      <br>
      <blockquote class="gmail_quote" style="margin: 0;margin-left:
        0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt;
        <br>
        &gt; std::is_integral&lt;T, U&gt;::value
        <br>
        &gt; apply&lt;std::_is_integral, T, U&gt;::value
        <br>
        &gt; and_&lt;std::is_integral&lt;T&gt;,
        std::is_integral&lt;U&gt;&gt;::value
        <br>
        &gt;
        <br>
        &gt; Clearly the original suggestion is the shortest, but that's
        not the <br>
        &gt; best criterion for a proposal. The third one using "and_"
        is the most <br>
        &gt; general and can be used to implement the other two.
      </blockquote>
      <div>&nbsp;<br>
        Well, you both have a good point about the genericity of the
        methods. Between the two of them, I think my favourite<br>
      </div>
      <div>one is the one using apply since it allows to apply the same
        trait to a whole range of types at once, and remains easy<br>
        to use and short. It also allows to use write
        apply&lt;std::is_same, Args...&gt; which could be pretty useful.<br>
        <br>
      </div>
    </blockquote>
    Notice that the is_same needs two arguments and hence doesn't work
    out of the box. <br>
    One of the points with and_ is that it can handle range of types,
    say with is_integral for example.. and_&lt;
    std::is_integral&lt;Args&gt;... &gt;.<br>
    <br>
    <br>
    Mikael<br>
  </body>
</html>

<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 email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
&nbsp;<br />
&nbsp;<br />

--------------080506040108010301000303--

.