Topic: A proposal to add swap traits to the standard library
Author: "Andrew C. Morrow" <andrew.c.morrow@gmail.com>
Date: Sat, 2 Feb 2013 11:37:04 -0500
Raw View
--f46d0401229f590b5704d4c078d6
Content-Type: text/plain; charset=ISO-8859-1
Hi all -
I'd like to propose the addition of two new type relationship traits to the
C++ standard library:
template<typename T, typename U = T>
struct std::is_swappable;
template<typename T, typename U = T>
struct std::is_nothrow_swappable;
The purpose of these two new traits is primarily to make it easier to
correctly query the noexcept status of swap when writing a noexcept
expression.
A draft of the proposal can be found here:
http://acmorrow.github.com/swap_traits/nXXXX.html
This is my first proposal, so it may need some work yet. I'd appreciate
your feedback and suggestions.
Thanks for your time,
Andrew
--
---
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.
--f46d0401229f590b5704d4c078d6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div style>Hi all -</div><div style><br></div><div sty=
le>I'd like to propose the addition of two new type relationship traits=
to the C++ standard library:</div><div style><br></div><div style><font fa=
ce=3D"courier new, monospace">template<typename T, typename U =3D T><=
/font></div>
<div style><font face=3D"courier new, monospace">struct std::is_swappable;<=
/font></div><div style><font face=3D"courier new, monospace"><br></font></d=
iv><div style><font face=3D"courier new, monospace">template<typename T,=
typename U =3D T></font></div>
<div style><font face=3D"courier new, monospace">struct std::is_nothrow_swa=
ppable;</font></div><div style><br></div><div style>The purpose of these tw=
o new traits is primarily to make it easier to correctly query the noexcept=
status of swap when writing a noexcept expression.</div>
<div style><br></div><div style>A draft of the proposal can be found here:=
=A0<a href=3D"http://acmorrow.github.com/swap_traits/nXXXX.html">http://acm=
orrow.github.com/swap_traits/nXXXX.html</a></div><div style><br></div><div =
style>
This is my first proposal, so it may need some work yet. I'd appreciate=
your feedback and suggestions.</div><div style><br></div><div style>Thanks=
for your time,</div><div style>Andrew</div><div style><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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--f46d0401229f590b5704d4c078d6--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 02 Feb 2013 19:53:16 +0200
Raw View
----- Original message -----
> Hi all -
>
> I'd like to propose the addition of two new type relationship traits to
> the C++ standard library:
>
> template<typename T, typename U = T>
> struct std::is_swappable;
>
> template<typename T, typename U = T>
> struct std::is_nothrow_swappable;
>
> The purpose of these two new traits is primarily to make it easier to
> correctly query the noexcept status of swap when writing a noexcept
> expression.
Just quickly, what's the issue with
noexcept(swap(x, y)) ?
--
---
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.
.
Author: Howard Hinnant <howard.hinnant@gmail.com>
Date: Sat, 2 Feb 2013 13:00:55 -0500
Raw View
On Feb 2, 2013, at 12:53 PM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
>
> ----- Original message -----
>> Hi all -
>>
>> I'd like to propose the addition of two new type relationship traits to
>> the C++ standard library:
>>
>> template<typename T, typename U = T>
>> struct std::is_swappable;
>>
>> template<typename T, typename U = T>
>> struct std::is_nothrow_swappable;
>>
>> The purpose of these two new traits is primarily to make it easier to
>> correctly query the noexcept status of swap when writing a noexcept
>> expression.
>
> Just quickly, what's the issue with
> noexcept(swap(x, y)) ?
Challenge: Make this code compile without a using directive or using declaration:
#include <algorithm>
template <class T>
void
foo(T& x, T& y) noexcept(noexcept(swap(x, y)));
struct A
{
A() = default;
A(const A&);
A& operator=(const A&);
};
void swap(A&, A&) noexcept;
int main()
{
int i;
A a;
static_assert(noexcept(foo(i, i)), "");
static_assert(noexcept(foo(a, a)), "");
}
Howard
--
---
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.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 2 Feb 2013 21:12:33 +0200
Raw View
On 2 February 2013 20:00, Howard Hinnant <howard.hinnant@gmail.com> wrote:
> On Feb 2, 2013, at 12:53 PM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
>> Just quickly, what's the issue with
>> noexcept(swap(x, y)) ?
> Challenge: Make this code compile without a using directive or using declaration:
Wow. I think "wtf". Utterly baffled. :) I didn't mean to say that this
proposal is
unnecessary, but your example seems to indicate it's definitely worth
considering.
In other words, I tried it quickly, and with all the expertise I have,
I don't want
to try further. Perhaps I'm missing something, but why doesn't it work?
--
---
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.
.
Author: =?ISO-8859-1?Q?Mikael_Kilpel=E4inen?=
Date: Sat, 02 Feb 2013 20:20:44 +0100
Raw View
2.2.2013 20:12, Ville Voutilainen kirjoitti:
> On 2 February 2013 20:00, Howard Hinnant <howard.hinnant@gmail.com> wrote:
>> On Feb 2, 2013, at 12:53 PM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
>>> Just quickly, what's the issue with
>>> noexcept(swap(x, y)) ?
>> Challenge: Make this code compile without a using directive or using declaration:
> Wow. I think "wtf". Utterly baffled. :) I didn't mean to say that this
> proposal is
> unnecessary, but your example seems to indicate it's definitely worth
> considering.
> In other words, I tried it quickly, and with all the expertise I have,
> I don't want
> to try further. Perhaps I'm missing something, but why doesn't it work?
>
Because you are calling the swap with ints.. so no ADL to find the
std::swap .. you can make it compile by having
void swap(int& a, int& b) noexcept {
std::swap(a, b);
}
before the foo.. Or am i totally mistaken here?
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.
.
Author: Howard Hinnant <howard.hinnant@gmail.com>
Date: Sat, 2 Feb 2013 14:24:06 -0500
Raw View
On Feb 2, 2013, at 2:12 PM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
> On 2 February 2013 20:00, Howard Hinnant <howard.hinnant@gmail.com> wrote:
>> On Feb 2, 2013, at 12:53 PM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
>>> Just quickly, what's the issue with
>>> noexcept(swap(x, y)) ?
>> Challenge: Make this code compile without a using directive or using declaration:
>
> Wow. I think "wtf". Utterly baffled. :) I didn't mean to say that this
> proposal is
> unnecessary, but your example seems to indicate it's definitely worth
> considering.
> In other words, I tried it quickly, and with all the expertise I have,
> I don't want
> to try further. Perhaps I'm missing something, but why doesn't it work?
Here is what the body of foo will presumably look like:
template <class T>
void
foo(T& x, T& y) noexcept(noexcept(swap(x, y)))
{
using std::swap;
swap(x, y);
}
I.e. we need to call swap unqualified to pick up A's swap, but std::swap needs to be in scope to swap ints. I don't see a way to put the logic of the body of foo into foo's noexcept spec without polluting foo's namespace with swap.
Here might be another way to code it:
template <class T>
void
foo(T& x, T& y) noexcept(noexcept((using std::swap, swap(x, y))))
{
using std::swap;
swap(x, y);
}
but my compiler gets grumpy when I try this.
I did finally get it to work this way:
#include <algorithm>
namespace details
{
using std::swap;
template <class T>
void
foo_imp(T& x, T& y) noexcept(noexcept(swap(x, y)))
{
swap(x, y);
}
}
template <class T>
void
foo(T& x, T& y) noexcept(noexcept(details::foo_imp(x, y)))
{
details::foo_imp(x, y);
}
struct A
{
A() = default;
A(const A&);
A& operator=(const A&);
};
void swap(A&, A&) noexcept;
int main()
{
int i;
A a;
static_assert(noexcept(foo(i, i)), "");
static_assert(noexcept(foo(a, a)), "");
}
Yay! I got the correct noexcept spec without polluting my namespace with std::swap. I've also come close to just implementing the proposed std::is_nothrow_swappable, except that I failed to make it reusable. ;-) It only works for foo. :-\
Howard
--
---
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.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 2 Feb 2013 21:55:03 +0200
Raw View
On 2 February 2013 21:24, Howard Hinnant <howard.hinnant@gmail.com> wrote:
> Yay! I got the correct noexcept spec without polluting my namespace with std::swap. I've also come close to just implementing the proposed std::is_nothrow_swappable, except that I failed to make it reusable. ;-) It only works for foo. :-\
No offense, but I have a litmus test; it says "if it takes Howard 50
lines to do and he claims it was 'not that
hard', there's a usability issue around." :D
--
---
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.
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Sat, 2 Feb 2013 14:15:36 -0600
Raw View
On Sat, Feb 2, 2013 at 1:24 PM, Howard Hinnant <howard.hinnant@gmail.com> wrote:
> foo(T& x, T& y) noexcept(noexcept((using std::swap, swap(x, y))))
I agree "is_nothrow_swappable" is a missing point. But,
like the imaginary code above, I think the problem is on
ADL, not swap itself.
For short, I want a `using` directive for a function, only, like
a function level `try` block.
void f(T& x, T& y) using std::swap noexcept(noexcept(swap(x, y)))
So that directive also works for the _trailing return types_.
Multiple `using`s should also be supported,
using namespace std, namespace boost
using std::cout, std::swap
or
using namespace std using namespace boost
using std::cout using std::swap
Whatever you like.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
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.
.
Author: Jeffrey Yasskin <jyasskin@googlers.com>
Date: Sat, 2 Feb 2013 21:52:24 -0800
Raw View
On Sat, Feb 2, 2013 at 10:00 AM, Howard Hinnant
<howard.hinnant@gmail.com> wrote:
> On Feb 2, 2013, at 12:53 PM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
>
>>
>> ----- Original message -----
>>> Hi all -
>>>
>>> I'd like to propose the addition of two new type relationship traits to
>>> the C++ standard library:
>>>
>>> template<typename T, typename U = T>
>>> struct std::is_swappable;
>>>
>>> template<typename T, typename U = T>
>>> struct std::is_nothrow_swappable;
>>>
>>> The purpose of these two new traits is primarily to make it easier to
>>> correctly query the noexcept status of swap when writing a noexcept
>>> expression.
>>
>> Just quickly, what's the issue with
>> noexcept(swap(x, y)) ?
>
> Challenge: Make this code compile without a using directive or using declaration:
>
> #include <algorithm>
>
> template <class T>
> void
> foo(T& x, T& y) noexcept(noexcept(swap(x, y)));
>
> struct A
> {
> A() = default;
> A(const A&);
> A& operator=(const A&);
> };
>
> void swap(A&, A&) noexcept;
>
> int main()
> {
> int i;
> A a;
> static_assert(noexcept(foo(i, i)), "");
> static_assert(noexcept(foo(a, a)), "");
> }
>
> Howard
:)
At one point, I think Dave suggested making ::std::begin(foo)
automatically delegate to ADL when that's possible. I forget exactly
how that worked, but if it's possible, we should consider doing it for
swap() as well.
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 http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sun, 03 Feb 2013 09:00:06 +0100
Raw View
Le 03/02/13 06:52, Jeffrey Yasskin a =E9crit :
> On Sat, Feb 2, 2013 at 10:00 AM, Howard Hinnant
> <howard.hinnant@gmail.com> wrote:
>> On Feb 2, 2013, at 12:53 PM, Ville Voutilainen <ville.voutilainen@gmail.=
com> wrote:
>>
>>> ----- Original message -----
>>>> Hi all -
>>>>
>>>> I'd like to propose the addition of two new type relationship traits t=
o
>>>> the C++ standard library:
>>>>
>>>> template<typename T, typename U =3D T>
>>>> struct std::is_swappable;
>>>>
>>>> template<typename T, typename U =3D T>
>>>> struct std::is_nothrow_swappable;
>>>>
>>>> The purpose of these two new traits is primarily to make it easier to
>>>> correctly query the noexcept status of swap when writing a noexcept
>>>> expression.
>>> Just quickly, what's the issue with
>>> noexcept(swap(x, y)) ?
>> Challenge: Make this code compile without a using directive or using de=
claration:
>>
>> #include <algorithm>
>>
>> template <class T>
>> void
>> foo(T& x, T& y) noexcept(noexcept(swap(x, y)));
>>
>> struct A
>> {
>> A() =3D default;
>> A(const A&);
>> A& operator=3D(const A&);
>> };
>>
>> void swap(A&, A&) noexcept;
>>
>> int main()
>> {
>> int i;
>> A a;
>> static_assert(noexcept(foo(i, i)), "");
>> static_assert(noexcept(foo(a, a)), "");
>> }
>>
>> Howard
> :)
>
> At one point, I think Dave suggested making ::std::begin(foo)
> automatically delegate to ADL when that's possible. I forget exactly
> how that worked, but if it's possible, we should consider doing it for
> swap() as well.
>
>
The following code based on the idea of boost::swap works with clang 3.2
"The template function boost::swap allows the values of two variables to=20
be swapped, using argument dependent lookup to select a specialized swap=20
function if available. If no specialized swap function is available,=20
std::swap is used."
namespace nstd_swap_impl
{
using std::swap;
template <class T>
void swap_impl(T& x, T& y) noexcept(noexcept(swap(x, y)))
{
swap(x, y);
}
}
namespace nstd
{
template<class T1, class T2>
void swap(T1& x, T2& y) noexcept(noexcept(::nstd_swap_impl::swap_impl(x,=
y)))
{
::nstd_swap_impl::swap_impl(x, y);
}
}
template <class T>
void
foo(T& x, T& y) noexcept(noexcept(nstd::swap(x, y)));
struct A
{
A() =3D default;
A(const A&);
A& operator=3D(const A&);
};
void swap(A&, A&) noexcept;
int main()
{
int i;
A a;
static_assert(noexcept(foo(i, i)), "");
static_assert(noexcept(foo(a, a)), "");
}
I don't know if Dave suggestion was related to this technique, but at least=
the nstd::swap is reusable.
Vicente
P.S. I needed to rename swap on for make working gcc
namespace nstd
{
template<class T1, class T2>
void swap2(T1& x, T2& y) noexcept(noexcept(::nstd_swap_impl::swap_impl(x=
, y)))
{
::nstd_swap_impl::swap_impl(x, y);
}
}
template <class T>
void
foo(T& x, T& y) noexcept(noexcept(nstd::swap2(x, y)));
as otherwise
.../example/swap_test.cpp:19:77: error: template instantiation depth exceeds=
maximum of 128 (use -ftemplate-depth=3D to increase the maximum) substitut=
ing =91template<class T> void nstd_swap_impl::swap_impl(T&, T&) [with T =3D=
<missing>]=92
void swap(T1& x, T2& y) noexcept(noexcept(::nstd_swap_impl::swap_impl(x=
, y)))
=
^
.../example/swap_test.cpp:19:77: required from =91void nstd::swap(T1&, T2&=
) [with T1 =3D int; T2 =3D int]=92
.../example/swap_test.cpp:27:50: required from =91void nstd_swap_impl::swa=
p_impl(T&, T&) [with T =3D int]=92
.../example/swap_test.cpp:19:77: required from =91void nstd::swap(T1&, T2&=
) [with T1 =3D int; T2 =3D int]=92
.../example/swap_test.cpp:27:50: required from =91void nstd_swap_impl::swa=
p_impl(T&, T&) [with T =3D int]=92
.../example/swap_test.cpp:19:77: required from =91void nstd::swap(T1&, T2&=
) [with T1 =3D int; T2 =3D int]=92
.../example/swap_test.cpp:27:50: [ skipping 118 instantiation contexts, us=
e -ftemplate-backtrace-limit=3D0 to disable ]
.../example/swap_test.cpp:27:50: required from =91void nstd_swap_impl::swa=
p_impl(T&, T&) [with T =3D int]=92
.../example/swap_test.cpp:19:77: required from =91void nstd::swap(T1&, T2&=
) [with T1 =3D int; T2 =3D int]=92
.../example/swap_test.cpp:27:50: required from =91void nstd_swap_impl::swa=
p_impl(T&, T&) [with T =3D int]=92
.../example/swap_test.cpp:19:77: required from =91void nstd::swap(T1&, T2&=
) [with T1 =3D int; T2 =3D int]=92
.../example/swap_test.cpp:27:50: required from =91void foo(T&, T&) [with T=
=3D int]=92
.../example/swap_test.cpp:42:36: required from here
--=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.
.
Author: Howard Hinnant <howard.hinnant@gmail.com>
Date: Sun, 3 Feb 2013 14:16:28 -0500
Raw View
On Feb 3, 2013, at 3:00 AM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
> The following code based on the idea of boost::swap works with clang 3.2
>
> "The template function boost::swap allows the values of two variables to be swapped, using argument dependent lookup to select a specialized swap function if available. If no specialized swap function is available, std::swap is used."
>
> namespace nstd_swap_impl
> {
> using std::swap;
>
> template <class T>
> void swap_impl(T& x, T& y) noexcept(noexcept(swap(x, y)))
> {
> swap(x, y);
> }
> }
>
> namespace nstd
> {
> template<class T1, class T2>
> void swap(T1& x, T2& y) noexcept(noexcept(::nstd_swap_impl::swap_impl(x, y)))
> {
> ::nstd_swap_impl::swap_impl(x, y);
> }
> }
>
> template <class T>
> void
> foo(T& x, T& y) noexcept(noexcept(nstd::swap(x, y)));
>
> struct A
> {
> A() = default;
> A(const A&);
> A& operator=(const A&);
> };
>
> void swap(A&, A&) noexcept;
>
> int main()
> {
> int i;
> A a;
> static_assert(noexcept(foo(i, i)), "");
> static_assert(noexcept(foo(a, a)), "");
> }
>
> I don't know if Dave suggestion was related to this technique, but at least the nstd::swap is reusable.
This gave me the idea that a simple solution would be to just slap a noexcept on std::iter_swap and use that:
#include <algorithm>
template <class T>
void
foo(T& x, T& y) noexcept(noexcept(std::iter_swap(&x, &y)))
{
std::iter_swap(&x, &y);
}
struct A
{
A() = default;
A(const A&);
A& operator=(const A&);
};
void swap(A&, A&) noexcept;
int main()
{
int i;
A a;
static_assert(noexcept(foo(i, i)), "");
static_assert(noexcept(foo(a, a)), "");
}
std::iter_swap (if it has a noexcept spec) serves the same purpose as Vicente's nstd::swap above.
Howard
--
---
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.
.
Author: =?ISO-8859-1?Q?Mikael_Kilpel=E4inen?=
Date: Sun, 03 Feb 2013 21:27:10 +0100
Raw View
3.2.2013 20:16, Howard Hinnant kirjoitti:
> This gave me the idea that a simple solution would be to just slap a
> noexcept on std::iter_swap and use that: #include <algorithm> template
> <class T> void foo(T& x, T& y) noexcept(noexcept(std::iter_swap(&x,
> &y))) { std::iter_swap(&x, &y); } struct A { A() = default; A(const
> A&); A& operator=(const A&); }; void swap(A&, A&) noexcept; int main()
> { int i; A a; static_assert(noexcept(foo(i, i)), "");
> static_assert(noexcept(foo(a, a)), ""); } std::iter_swap (if it has a
> noexcept spec) serves the same purpose as Vicente's nstd::swap above.
Nice idea, however std::iter_swap does not have noexcept specifier.. How
about using something else for the same job.. like say, tuple:
template<typename T>
void foo(T&, T&) noexcept(noexcept( std::tuple<T>().swap(
std::declval<std::tuple<T>&>() )));
Not quite as nice but maybe it works.
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.
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Sun, 3 Feb 2013 14:46:36 -0600
Raw View
On Sat, Feb 2, 2013 at 11:52 PM, Jeffrey Yasskin <jyasskin@googlers.com> wrote:
> At one point, I think Dave suggested making ::std::begin(foo)
> automatically delegate to ADL when that's possible. I forget exactly
> how that worked, but if it's possible, we should consider doing it for
> swap() as well.
Can you give me a link? I did not find it...
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
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.
.
Author: =?ISO-8859-1?Q?Mikael_Kilpel=E4inen?=
Date: Mon, 04 Feb 2013 06:23:54 +0100
Raw View
3.2.2013 21:27, Mikael Kilpel=E4inen kirjoitti:
>
> template<typename T>
> void foo(T&, T&) noexcept(noexcept( std::tuple<T>().swap(=20
> std::declval<std::tuple<T>&>() )));
>
>
Seems i was already sleeping when i wrote that, as obviously this=20
imposes some restrictions for T but maybe the concept works as a dirty=20
workaround.
So lets summarise most of the thread :
- Problem exists with free functions and lookup if wanted to use in=20
noexcept, trailing return
- Having is_swappable traits (as proposed) fixes it for one of the most=20
common cases, and i do agree it feels like those type traits are missing.
- We might be able to fix this for most std free functions by making=20
them first to perform ADL like pointed out by Yasskin. I wonder how many=20
swap relies on calling the std::swap directly though and possibly=20
recursing then.
The problem itself it generic, but is it worth "fixing"? Is there much=20
similar usage with other than std library that would benefit from it?
Mikael
--=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.
.
Author: Nikolay Ivchenkov <tsoae@mail.ru>
Date: Tue, 5 Feb 2013 14:22:02 -0800 (PST)
Raw View
------=_Part_578_4819155.1360102922592
Content-Type: text/plain; charset=ISO-8859-1
On Saturday, February 2, 2013 8:37:04 PM UTC+4, Andrew Morrow wrote:
>
> A draft of the proposal can be found here:
> http://acmorrow.github.com/swap_traits/nXXXX.html
>
1. IMO, the expression should be swap(declval<T>(), declval<U>()) rather
than swap(declval<T&>(), declval<U&>()), so we could test lvalues and
rvalues.
2. The wording "The set of swaps considered for resolution must include
std::swap as well as swap overloads available via argument dependent
lookup" isn't precise enough, at least because there are several templates
with name 'swap' in std.
3. An implementation of is_swappable and is_nothrow_swappable could be more
simple:
namespace std
{
template <bool _B>
using __bool_constant = integral_constant<bool, _B>;
template <class _T, class _U, class = void>
struct __is_swappable_test : false_type
{
using __nothrow_swappable = false_type;
};
template <class _T, class _U>
struct __is_swappable_test<_T, _U,
decltype((void)swap(declval<_T>(), declval<_U>()))> : true_type
{
using __nothrow_swappable =
__bool_constant<noexcept(swap(declval<_T>(), declval<_U>()))>;
};
template <class _T, class _U = _T>
struct is_swappable :
__is_swappable_test<_T, _U> {};
template <class _T, class _U = _T>
struct is_nothrow_swappable :
__is_swappable_test<_T, _U>::__nothrow_swappable {};
}
On Sunday, February 3, 2013 12:15:36 AM UTC+4, Zhihao Yuan wrote:
>
> But,
> like the imaginary code above, I think the problem is on
> ADL, not swap itself.
>
> For short, I want a `using` directive for a function, only, like
> a function level `try` block.
>
> void f(T& x, T& y) using std::swap noexcept(noexcept(swap(x, y)))
>
IMO, such code looks terrible. I would prefer noexcept(auto) instead.
--
---
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_578_4819155.1360102922592
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Saturday, February 2, 2013 8:37:04 PM UTC+4, Andrew Morrow wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">A draft of the propo=
sal can be found here: <a href=3D"http://acmorrow.github.com/swap_trai=
ts/nXXXX.html" target=3D"_blank">http://acmorrow.github.<wbr>com/swap_trait=
s/nXXXX.html</a></div></blockquote><div><br>1. IMO, the expression should b=
e <tt>swap(declval<T>(), declval<U>())</tt> rather than <tt>swa=
p(declval<T&>(), declval<U&>())</tt>, so we could test =
lvalues and rvalues.<br><br>2. The wording "The set of swaps considered for=
resolution must include <tt>std::swap</tt> as
well as swap overloads available via argument dependent looku=
p" isn't precise enough, at least because there are several templates with =
name 'swap' in std.<br><br>3. An implementation of is_swappable and is_noth=
row_swappable could be more simple:<br><br>namespace std<br>{<br> &nbs=
p; template <bool _B><br> &n=
bsp; using __bool_constant =3D integral_constant<bool, _B>;<br><br>&n=
bsp; template <class _T, class _U, class =3D void><br>&nb=
sp; struct __is_swappable_test : false_=
type<br> {<br> =
using __nothrow_swappable =3D false_type;<br> };<br><br>&=
nbsp; template <class _T, class _U><br> =
struct __is_swappable_test<_T, _U,<br> &nb=
sp; decltype((void)sw=
ap(declval<_T>(), declval<_U>()))> : true_type<br> &nbs=
p; {<br> using __nothrow_sw=
appable =3D<br> =
__bool_constant<noexcept(swap(declval<_T>(), declval<_U&=
gt;()))>;<br> };<br><br> template &l=
t;class _T, class _U =3D _T><br> &nbs=
p; struct is_swappable :<br>  =
; __is_swappable_test<_T, _U> {};<br> &n=
bsp; template <class _T, class _U =3D _T><br> =
struct is_nothrow_swappable :<br>  =
; __is_swappable_test<_T, _U&g=
t;::__nothrow_swappable {};<br>}<br><br><br>On Sunday, February 3, 2013 12:=
15:36 AM UTC+4, Zhihao Yuan wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">But,
<br>like the imaginary code above, I think the problem is on
<br>ADL, not swap itself.
<br>
<br>For short, I want a `using` directive for a function, only, like
<br>a function level `try` block.
<br>
<br>void f(T& x, T& y) using std::swap noexcept(noexcept(swap(x, y)=
))<br></blockquote><div><br>IMO, such code looks terrible. I would prefer n=
oexcept(auto) instead.<br></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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_578_4819155.1360102922592--
.
Author: =?ISO-8859-1?Q?Mikael_Kilpel=E4inen?=
Date: Wed, 06 Feb 2013 10:51:57 +0100
Raw View
5.2.2013 23:22, Nikolay Ivchenkov kirjoitti:
> 1. IMO, the expression should be swap(declval<T>(), declval<U>())
> rather than swap(declval<T&>(), declval<U&>()), so we could test
> lvalues and rvalues.
>
So that in the common case you need to use is_swappable<A&> ? What is
the use for swap functions taking rvalues?
As the normal swap taking lvalues you cannot call with declval<T>() when
T is not reference.
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.
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Wed, 6 Feb 2013 02:34:34 -0800 (PST)
Raw View
------=_Part_401_4838259.1360146874472
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
W dniu poniedzia=C5=82ek, 4 lutego 2013 06:23:54 UTC+1 u=C5=BCytkownik Mika=
el=20
Kilpel=C3=A4inen napisa=C5=82:
>
> 3.2.2013 21:27, Mikael Kilpel=C3=AF=C2=BF=C2=BDinen kirjoitti:=20
> >=20
> > template<typename T>=20
> > void foo(T&, T&) noexcept(noexcept( std::tuple<T>().swap(=20
> > std::declval<std::tuple<T>&>() )));=20
> >=20
> >=20
> Seems i was already sleeping when i wrote that, as obviously this=20
> imposes some restrictions for T but maybe the concept works as a dirty=20
> workaround.=20
>
> So lets summarise most of the thread :=20
>
> - Problem exists with free functions and lookup if wanted to use in=20
> noexcept, trailing return=20
> - Having is_swappable traits (as proposed) fixes it for one of the most=
=20
> common cases, and i do agree it feels like those type traits are missing.=
=20
> - We might be able to fix this for most std free functions by making=20
> them first to perform ADL like pointed out by Yasskin. I wonder how many=
=20
> swap relies on calling the std::swap directly though and possibly=20
> recursing then.=20
>
> The problem itself it generic, but is it worth "fixing"? Is there much=20
> similar usage with other than std library that would benefit from it?=20
>
If the problem is primarily about std::swap, and swap is so very special,=
=20
perhaps defining or aliasing it in the global namespace would solve the=20
problem?=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_401_4838259.1360146874472
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu poniedzia=C5=82ek, 4 lutego 2013 06:23:54 UTC+1 u=C5=BCytkow=
nik Mikael Kilpel=C3=A4inen napisa=C5=82:<blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;">3.2.2013 21:27, Mikael Kilpel=C3=AF=C2=BF=C2=BDinen kirjoitti:
<br>>
<br>> template<typename T>
<br>> void foo(T&, T&) noexcept(noexcept( std::tuple<T>().=
swap(=20
<br>> std::declval<std::tuple<T>&>() )));
<br>>
<br>>
<br>Seems i was already sleeping when i wrote that, as obviously this=20
<br>imposes some restrictions for T but maybe the concept works as a dirty=
=20
<br>workaround.
<br>
<br>So lets summarise most of the thread :
<br>
<br>- Problem exists with free functions and lookup if wanted to use in=20
<br>noexcept, trailing return
<br>- Having is_swappable traits (as proposed) fixes it for one of the most=
=20
<br>common cases, and i do agree it feels like those type traits are missin=
g.
<br>- We might be able to fix this for most std free functions by making=20
<br>them first to perform ADL like pointed out by Yasskin. I wonder how man=
y=20
<br>swap relies on calling the std::swap directly though and possibly=20
<br>recursing then.
<br>
<br>The problem itself it generic, but is it worth "fixing"? Is there much=
=20
<br>similar usage with other than std library that would benefit from it?
<br></blockquote><div><br>If the problem is primarily about std::swap, and =
swap is so very special, perhaps defining or aliasing it in the global name=
space would solve the problem? <br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_401_4838259.1360146874472--
.
Author: Nikolay Ivchenkov <tsoae@mail.ru>
Date: Wed, 6 Feb 2013 05:47:57 -0800 (PST)
Raw View
------=_Part_510_23340759.1360158477992
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Wednesday, February 6, 2013 1:51:57 PM UTC+4, Mikael Kilpel=E4inen wrote=
:
>
> 5.2.2013 23:22, Nikolay Ivchenkov kirjoitti:=20
> > 1. IMO, the expression should be swap(declval<T>(), declval<U>())=20
> > rather than swap(declval<T&>(), declval<U&>()), so we could test=20
> > lvalues and rvalues.=20
> >=20
> So that in the common case you need to use is_swappable<A&> ?
I don't know what common case you have in mind. I can imagine an=20
application like this:
is_swappable<decltype(*declval<dereferenceable_type>())>
where the result of the dereferencing could be a prvalue of a proxy type.
--=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_510_23340759.1360158477992
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Wednesday, February 6, 2013 1:51:57 PM UTC+4, Mikael Kilpel=E4inen wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;">5.2.2013 23:22, Nikolay Ivche=
nkov kirjoitti:
<br>> 1. IMO, the expression should be swap(declval<T>(), declval&=
lt;U>())=20
<br>> rather than swap(declval<T&>(), declval<U&>())=
, so we could test=20
<br>> lvalues and rvalues.
<br>>
<br>So that in the common case you need to use is_swappable<A&> ?=
</blockquote><div><br>I don't know what common case you have in mind. I can=
imagine an application like this:<br><br> is_swappable&l=
t;decltype(*declval<dereferenceable_type>())><br><br>where the res=
ult of the dereferencing could be a prvalue of a proxy type.</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_510_23340759.1360158477992--
.
Author: Nikolay Ivchenkov <tsoae@mail.ru>
Date: Wed, 6 Feb 2013 06:14:31 -0800 (PST)
Raw View
------=_Part_120_2341925.1360160071337
Content-Type: text/plain; charset=ISO-8859-1
On Wednesday, February 6, 2013 2:22:02 AM UTC+4, Nikolay Ivchenkov wrote:
>
>
> 2. The wording "The set of swaps considered for resolution must include
> std::swap as well as swap overloads available via argument dependent
> lookup" isn't precise enough, at least because there are several templates
> with name 'swap' in std.
>
> 3. An implementation of is_swappable and is_nothrow_swappable could be
> more simple:
>
I forgot to say that we have to constrain std::swap defined in <utility>
then:
template <class T> auto
swap(T &a, T &b) noexcept(
is_nothrow_move_constructible<T>{} &&
is_nothrow_move_assignable<T>{})
-> typename std::enable_if
<
is_move_constructible<T>{} && is_move_assignable<T>{}
>::type;
otherwise our is_swappable would be useless:
int const x = 1;
using type = decltype(std::swap(x, x));
Here the unevaluated call to std::swap is well-formed, while x is not
swappable.
--
---
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_120_2341925.1360160071337
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Wednesday, February 6, 2013 2:22:02 AM UTC+4, Nikolay Ivchenkov wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div><br>2. The wording "The set=
of swaps considered for resolution must include <tt>std::swap</tt> as
well as swap overloads available via argument dependent looku=
p" isn't precise enough, at least because there are several templates with =
name 'swap' in std.<br><br>3. An implementation of is_swappable and is_noth=
row_swappable could be more simple:<br></div></blockquote><div><br>I forgot=
to say that we have to constrain std::swap defined in <utility> then=
:<br><br> template <class T> auto<br> &n=
bsp; swap(T &a, T &b) noexcept(<br> &n=
bsp;  =
; is_nothrow_move_constructible<T>{} &&<br> =
&nb=
sp; is_nothrow_move_assignable<T>{})<br>  =
; -> typename std::enable_if<br>&nbs=
p; &=
nbsp; <<br> &=
nbsp; is_move_constru=
ctible<T>{} && is_move_assignable<T>{}<br> &=
nbsp; &nbs=
p; >::type;<br><br>otherwise our is_swappable would be useless:<br><br>&=
nbsp; int const x =3D 1;<br> using type =3D d=
ecltype(std::swap(x, x));<br><br>Here the unevaluated call to std::swap is =
well-formed, while x is not swappable.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_120_2341925.1360160071337--
.
Author: =?ISO-8859-1?Q?Mikael_Kilpel=E4inen?=
Date: Wed, 06 Feb 2013 16:01:52 +0100
Raw View
This is a multi-part message in MIME format.
--------------060703000607040307070108
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
6.2.2013 14:47, Nikolay Ivchenkov kirjoitti:
> On Wednesday, February 6, 2013 1:51:57 PM UTC+4, Mikael Kilpel=E4inen=20
> wrote:
>
> 5.2.2013 23:22, Nikolay Ivchenkov kirjoitti:
> > 1. IMO, the expression should be swap(declval<T>(), declval<U>())
> > rather than swap(declval<T&>(), declval<U&>()), so we could test
> > lvalues and rvalues.
> >
> So that in the common case you need to use is_swappable<A&> ?
>
>
> I don't know what common case you have in mind. I can imagine an=20
> application like this:
>
My "common" case..
template<typename T>
void foo( T& ) noexcept( is_nothrow_swappable<T> );
which would require is_nothrow_swappable<T&> to pick up swap(T&, T&).
> is_swappable<decltype(*declval<dereferenceable_type>())>
>
> where the result of the dereferencing could be a prvalue of a proxy type.
I see, so the point is to interoperate with decltype. For me this proxy=20
case seems rather special but valid point.
I don't think people usually use swap like that though (to have swap for=20
rvalue references, or is it?) as it makes harder to
write generic code with specialised swaps. I am all for make it more=20
general but is it surprising? Is it easy to make mistake
and forget the & for example?
I have to say more I think about it, the more I am turning to want what=20
you said.
Mostly because what does swappable type mean? Is the lvalue of it=20
swappable or rvalue or something else?
One option would be to have special case for the plain type..
Btw, 17.6.3.2/2 has the symmetry contraint for swappable .. swap(t, u)=20
and swap(u, t) must be valid. Should we consider this as well?
But I guess that is not quite so important.
Mikael
--=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.
--------------060703000607040307070108
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">
6.2.2013 14:47, Nikolay Ivchenkov kirjoitti:
<blockquote
cite="mid:536643f8-e7bd-447c-8515-6829c42f8425@isocpp.org"
type="cite">On Wednesday, February 6, 2013 1:51:57 PM UTC+4,
Mikael Kilpeläinen wrote:
<blockquote class="gmail_quote" style="margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">5.2.2013
23:22, Nikolay Ivchenkov kirjoitti:
<br>
> 1. IMO, the expression should be swap(declval<T>(),
declval<U>()) <br>
> rather than swap(declval<T&>(),
declval<U&>()), so we could test <br>
> lvalues and rvalues.
<br>
>
<br>
So that in the common case you need to use
is_swappable<A&> ?</blockquote>
<div><br>
I don't know what common case you have in mind. I can imagine an
application like this:<br>
<br>
</div>
</blockquote>
My "common" case..<br>
<br>
template<typename T><br>
void foo( T& ) noexcept( is_nothrow_swappable<T> );<br>
<br>
which would require is_nothrow_swappable<T&> to pick up
swap(T&, T&).<br>
<br>
<blockquote
cite="mid:536643f8-e7bd-447c-8515-6829c42f8425@isocpp.org"
type="cite">
<div>
is_swappable<decltype(*declval<dereferenceable_type>())><br>
<br>
where the result of the dereferencing could be a prvalue of a
proxy type.</div>
</blockquote>
I see, so the point is to interoperate with decltype. For me this
proxy case seems rather special but valid point.<br>
I don't think people usually use swap like that though (to have swap
for rvalue references, or is it?) as it makes harder to <br>
write generic code with specialised swaps. I am all for make it more
general but is it surprising? Is it easy to make mistake<br>
and forget the & for example?<br>
<br>
I have to say more I think about it, the more I am turning to want
what you said. <br>
Mostly because what does swappable type mean? Is the lvalue of it
swappable or rvalue or something else?<br>
One option would be to have special case for the plain type..<br>
<br>
Btw, 17.6.3.2/2 has the symmetry contraint for swappable .. swap(t,
u) and swap(u, t) must be valid. Should we consider this as well?<br>
But I guess that is not quite so important.<br>
<br>
<br>
Mikael<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
<br />
<br />
--------------060703000607040307070108--
.
Author: Nikolay Ivchenkov <tsoae@mail.ru>
Date: Wed, 6 Feb 2013 08:32:51 -0800 (PST)
Raw View
------=_Part_685_28282860.1360168371865
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Wednesday, February 6, 2013 7:01:52 PM UTC+4, Mikael Kilpel=E4inen wrote=
:
>
> My "common" case..
>
> template<typename T>
> void foo( T& ) noexcept( is_nothrow_swappable<T> );
>
> which would require is_nothrow_swappable<T&> to pick up swap(T&, T&).
>
I don't see problems with is_nothrow_swappable<T&>.
is_swappable<decltype(*declval<dereferenceable_type>())>
>
> where the result of the dereferencing could be a prvalue of a proxy type.
>
> I see, so the point is to interoperate with decltype. For me this proxy=
=20
> case seems rather special but valid point.
> I don't think people usually use swap like that though (to have swap for=
=20
> rvalue references, or is it?) as it makes harder to=20
> write generic code with specialised swaps.
>
Well, cases where left and right arguments for swap have different types=20
are also rare, but the proposal tends to support such rare applications,=20
right?
=20
> I am all for make it more general but is it surprising?
>
Is the definition of std::is_assignable surprising? How often do we use=20
rvalues as the left operand of assignment operator? Wouldn't different=20
conventions about interpretation of template arguments for=20
std::is_assignable and std::is_swappable be surprising for people?
=20
> Is it easy to make mistake and forget the & for example?
>
I dunno.
I have to say more I think about it, the more I am turning to want what you=
=20
> said.=20
> Mostly because what does swappable type mean? Is the lvalue of it=20
> swappable or rvalue or something else?
>
There may be different definitions.
=20
> One option would be to have special case for the plain type..
>
Do you mean something like this?
// general version
template <class T, class U =3D T>
struct is_swappable_with;
template <class T>
struct is_swappable :
is_swappable_with
<
typename add_lvalue_reference<T>::type,
typename add_lvalue_reference<T>::type
> {};
=20
I think, it would be acceptable.
Btw, 17.6.3.2/2 has the symmetry contraint for swappable .. swap(t, u) and=
=20
> swap(u, t) must be valid. Should we consider this as well?
>
Perhaps.
--=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_685_28282860.1360168371865
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Wednesday, February 6, 2013 7:01:52 PM UTC+4, Mikael Kilpel=E4inen wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
My "common" case..<br>
<br>
template<typename T><br>
void foo( T& ) noexcept( is_nothrow_swappable<T> );<br>
<br>
which would require is_nothrow_swappable<T&> to pick up
swap(T&, T&).<br></div></blockquote><div><br> I don't see =
problems with is_nothrow_swappable<T&>.<br><br></div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF" text=3D"#000000">
=20
<blockquote type=3D"cite">
<div>
is_swappable<decltype(*<wbr>declval<dereferenceable_type>(=
<wbr>))><br>
<br>
where the result of the dereferencing could be a prvalue of a
proxy type.</div>
</blockquote>
I see, so the point is to interoperate with decltype. For me this
proxy case seems rather special but valid point.<br>
I don't think people usually use swap like that though (to have swap
for rvalue references, or is it?) as it makes harder to <br>
write generic code with specialised swaps.</div></blockquote><div><br>W=
ell, cases where left and right arguments for swap have different types are=
also rare, but the proposal tends to support such rare applications, right=
?<br> </div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div bgcolor=
=3D"#FFFFFF" text=3D"#000000"> I am all for make it more
general but is it surprising?</div></blockquote><div><br>Is the definit=
ion of std::is_assignable surprising? How often do we use rvalues as the le=
ft operand of assignment operator? Wouldn't different conventions about int=
erpretation of template arguments for std::is_assignable and std::is_swappa=
ble be surprising for people?<br> </div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div bgcolor=3D"#FFFFFF" text=3D"#000000"> Is it easy to mak=
e mistake and forget the & for example?<br></div></blockquote><div><br>=
I dunno.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div bgc=
olor=3D"#FFFFFF" text=3D"#000000">
=20
I have to say more I think about it, the more I am turning to want
what you said. <br>
Mostly because what does swappable type mean? Is the lvalue of it
swappable or rvalue or something else?<br></div></blockquote><div><br>T=
here may be different definitions.<br> </div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;"><div bgcolor=3D"#FFFFFF" text=3D"#000000">
One option would be to have special case for the plain type..<br></div>=
</blockquote><div><br>Do you mean something like this?<br><br> &=
nbsp; // general version<br> template <class T, class =
U =3D T><br> struct is_swappab=
le_with;<br><br> template <class T><br> =
struct is_swappable :<br> &=
nbsp; is_swappable_with<br> =
<<br> =
&nb=
sp; typename add_lvalue_reference<T>::type,<br> &nbs=
p; =
typename add_lvalue_reference<T>::type<br> &nb=
sp; > {};<br> <br>I think, it w=
ould be acceptable.<br><br></div><blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;"><div bgcolor=3D"#FFFFFF" text=3D"#000000">
=20
Btw, <a href=3D"http://17.6.3.2/2" target=3D"_blank">17.6.3.2/2</a> has=
the symmetry contraint for swappable .. swap(t,
u) and swap(u, t) must be valid. Should we consider this as well?<br></=
div></blockquote><div><br>Perhaps.</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_685_28282860.1360168371865--
.
Author: Howard Hinnant <howard.hinnant@gmail.com>
Date: Fri, 8 Feb 2013 18:36:03 -0500
Raw View
On Feb 6, 2013, at 11:32 AM, Nikolay Ivchenkov <tsoae@mail.ru> wrote:
>> I see, so the point is to interoperate with decltype. For me this proxy case seems rather special but valid point.
>> I don't think people usually use swap like that though (to have swap for rvalue references, or is it?) as it makes harder to
>> write generic code with specialised swaps.
>>
> Well, cases where left and right arguments for swap have different types are also rare, but the proposal tends to support such rare applications, right?
For me here is the poster-child for heterogeneous swap:
#include <vector>
#include <iostream>
int main()
{
std::vector<bool> v(1);
bool b = true;
swap(b, v[0]);
std::cout << v[0] << '\n';
}
The standard doesn't say this should work, but imho the standard is broken in that regard. It works in libc++ just as a personal expression of defiance. :-) Not sure if/where else.
That being said, if generic code were trying to tell if code like this was going to work, I would expect it to look like:
std::is_swappable<bool>::value
or
std::is_swappable<std::vector<bool>::value_type>::value
or
std::is_swappable<std::vector<bool>::reference>::value
I don't know of a case where a heterogeneous swap is useful for being explicitly heterogeneous. It is usually useful as trying to masquerade as a homogeneous swap.
Howard
--
---
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.
.
Author: =?ISO-8859-1?Q?Mikael_Kilpel=E4inen?=
Date: Sat, 09 Feb 2013 01:11:48 +0100
Raw View
This is a multi-part message in MIME format.
--------------040901020605020603010308
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
6.2.2013 17:32, Nikolay Ivchenkov kirjoitti:
>
> which would require is_nothrow_swappable<T&> to pick up swap(T&, T&).
>
> I don't see problems with is_nothrow_swappable<T&>.
>
First i want to say that i am sorry, I got your respond now.. gotta love
gmail.
Yes, indeed, there is no problem, as long as you don't expect it to be
without &
> Well, cases where left and right arguments for swap have different
> types are also rare, but the proposal tends to support such rare
> applications, right?
Indeed, it does, and that is good thing. First i had the idea of making
it simple as possible, but you already convinced me that should not be
the case,
and this is just part of it.
>
> Is the definition of std::is_assignable surprising? How often do we
> use rvalues as the left operand of assignment operator? Wouldn't
> different conventions about interpretation of template arguments for
> std::is_assignable and std::is_swappable be surprising for people?
I don't think it is valid argument to find something as surprising in
the standard.. yes, we have many surprising things, we ought to minimise
those. But like said earlier,
it is not quite that easy, and maybe having the generic solution just
benefits more of us.
>
> I have to say more I think about it, the more I am turning to want
> what you said.
> Mostly because what does swappable type mean? Is the lvalue of it
> swappable or rvalue or something else?
>
>
> There may be different definitions.
Indeed, and that is the point. Your way seems to make least confusion,
at least after little thought.. as it applies to the exact "expression"
you are giving.
> One option would be to have special case for the plain type..
>
>
> Do you mean something like this?
>
> // general version
> template <class T, class U = T>
> struct is_swappable_with;
>
> template <class T>
> struct is_swappable :
> is_swappable_with
> <
> typename add_lvalue_reference<T>::type,
> typename add_lvalue_reference<T>::type
> > {};
>
> I think, it would be acceptable.
>
Yes, that is along the lines i was suggesting...
> Btw, 17.6.3.2/2 <http://17.6.3.2/2> has the symmetry contraint for
> swappable .. swap(t, u) and swap(u, t) must be valid. Should we
> consider this as well?
>
>
> Perhaps.
Perhaps indeed, on the other hand you might want to see if the exact
expression is okey.. but then again the _swappable_ seems to be
something else in standard.
So it might be conflicting.
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.
--------------040901020605020603010308
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">
<div class="moz-cite-prefix">6.2.2013 17:32, Nikolay Ivchenkov
kirjoitti:<br>
</div>
<blockquote
cite="mid:f8e4cfdd-2ece-45a5-82cc-bf9f15549663@isocpp.org"
type="cite"><br>
<div bgcolor="#FFFFFF" text="#000000">which would require
is_nothrow_swappable<T&> to pick up swap(T&,
T&).<br>
</div>
<div><br>
I don't see problems with is_nothrow_swappable<T&>.<br>
<br>
</div>
</blockquote>
First i want to say that i am sorry, I got your respond now.. gotta
love gmail.<br>
<br>
Yes, indeed, there is no problem, as long as you don't expect it to
be without &<br>
<br>
<blockquote
cite="mid:f8e4cfdd-2ece-45a5-82cc-bf9f15549663@isocpp.org"
type="cite">
<div>Well, cases where left and right arguments for swap have
different types are also rare, but the proposal tends to support
such rare applications, right?<br>
</div>
</blockquote>
Indeed, it does, and that is good thing. First i had the idea of
making it simple as possible, but you already convinced me that
should not be the case,<br>
and this is just part of it.<br>
<br>
<blockquote
cite="mid:f8e4cfdd-2ece-45a5-82cc-bf9f15549663@isocpp.org"
type="cite"><br>
<div>Is the definition of std::is_assignable surprising? How often
do we use rvalues as the left operand of assignment operator?
Wouldn't different conventions about interpretation of template
arguments for std::is_assignable and std::is_swappable be
surprising for people?<br>
</div>
</blockquote>
I don't think it is valid argument to find something as surprising
in the standard.. yes, we have many surprising things, we ought to
minimise those. But like said earlier,<br>
it is not quite that easy, and maybe having the generic solution
just benefits more of us.<br>
<br>
<blockquote
cite="mid:f8e4cfdd-2ece-45a5-82cc-bf9f15549663@isocpp.org"
type="cite"><br>
<blockquote class="gmail_quote" style="margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor="#FFFFFF" text="#000000"> I have to say more I
think about it, the more I am turning to want what you said. <br>
Mostly because what does swappable type mean? Is the lvalue of
it swappable or rvalue or something else?<br>
</div>
</blockquote>
<div><br>
There may be different definitions.<br>
</div>
</blockquote>
Indeed, and that is the point. Your way seems to make least
confusion, at least after little thought.. as it applies to the
exact "expression" you are giving.<br>
<br>
<blockquote
cite="mid:f8e4cfdd-2ece-45a5-82cc-bf9f15549663@isocpp.org"
type="cite">
<div> </div>
<blockquote class="gmail_quote" style="margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor="#FFFFFF" text="#000000"> One option would be to
have special case for the plain type..<br>
</div>
</blockquote>
<div><br>
Do you mean something like this?<br>
<br>
// general version<br>
template <class T, class U = T><br>
struct is_swappable_with;<br>
<br>
template <class T><br>
struct is_swappable :<br>
is_swappable_with<br>
<<br>
typename add_lvalue_reference<T>::type,<br>
typename add_lvalue_reference<T>::type<br>
> {};<br>
<br>
I think, it would be acceptable.<br>
<br>
</div>
</blockquote>
Yes, that is along the lines i was suggesting...<br>
<br>
<blockquote
cite="mid:f8e4cfdd-2ece-45a5-82cc-bf9f15549663@isocpp.org"
type="cite">
<blockquote class="gmail_quote" style="margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor="#FFFFFF" text="#000000"> Btw, <a
moz-do-not-send="true" href="http://17.6.3.2/2"
target="_blank">17.6.3.2/2</a> has the symmetry contraint
for swappable .. swap(t, u) and swap(u, t) must be valid.
Should we consider this as well?<br>
</div>
</blockquote>
<div><br>
Perhaps.</div>
</blockquote>
<br>
Perhaps indeed, on the other hand you might want to see if the exact
expression is okey.. but then again the _swappable_ seems to be
something else in standard.<br>
So it might be conflicting.<br>
<br>
<br>
Mikael<br>
<br>
<br>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
<br />
<br />
--------------040901020605020603010308--
.
Author: =?ISO-8859-1?Q?Mikael_Kilpel=E4inen?=
Date: Sat, 09 Feb 2013 01:29:47 +0100
Raw View
9.2.2013 0:36, Howard Hinnant kirjoitti:
> For me here is the poster-child for heterogeneous swap:
>
> #include <vector>
> #include <iostream>
>
> int main()
> {
> std::vector<bool> v(1);
> bool b = true;
> swap(b, v[0]);
> std::cout << v[0] << '\n';
> }
>
> The standard doesn't say this should work, but imho the standard is broken in that regard. It works in libc++ just as a personal expression of defiance. :-) Not sure if/where else.
I agree something like this should work, but vector<bool> is rather
special anyhow. The fix seems quite trivial for this specific case
though, did you have some more generic
problem in mind which i just failed to see?
>
> I don't know of a case where a heterogeneous swap is useful for being explicitly heterogeneous. It is usually useful as trying to masquerade as a homogeneous swap.
>
I think so too. Can you think of other "common" examples than vector<bool>?
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.
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Fri, 8 Feb 2013 23:43:43 -0500
Raw View
On Fri, Feb 8, 2013 at 7:29 PM, Mikael Kilpel=E4inen
<mikael.kilpelainen@gmail.com> wrote:
> 9.2.2013 0:36, Howard Hinnant kirjoitti:
>
>> For me here is the poster-child for heterogeneous swap:
>>
>> #include <vector>
>> #include <iostream>
>>
>> int main()
>> {
>> std::vector<bool> v(1);
>> bool b =3D true;
>> swap(b, v[0]);
>> std::cout << v[0] << '\n';
>> }
>>
>> The standard doesn't say this should work, but imho the standard is brok=
en
>> in that regard. It works in libc++ just as a personal expression of
>> defiance. :-) Not sure if/where else.
>
> I agree something like this should work, but vector<bool> is rather speci=
al
> anyhow. The fix seems quite trivial for this specific case though, did yo=
u
> have some more generic
> problem in mind which i just failed to see?
>
>
>>
>> I don't know of a case where a heterogeneous swap is useful for being
>> explicitly heterogeneous. It is usually useful as trying to masquerade =
as a
>> homogeneous swap.
>>
> I think so too. Can you think of other "common" examples than vector<bool=
>?
>
>
> Mikael
>
If I can write (or similar):
T t;
U u;
// swap them:
T tmp =3D t;
t =3D u;
u =3D tmp; // or std::move(tmp)
Then shouldn't I be able to swap them?
Tony
--=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.
.
Author: Howard Hinnant <howard.hinnant@gmail.com>
Date: Sat, 9 Feb 2013 11:15:29 -0500
Raw View
On Feb 8, 2013, at 11:43 PM, Tony V E <tvaneerd@gmail.com> wrote:
> On Fri, Feb 8, 2013 at 7:29 PM, Mikael Kilpel=E4inen
> <mikael.kilpelainen@gmail.com> wrote:
>> 9.2.2013 0:36, Howard Hinnant kirjoitti:
>>=20
>>> For me here is the poster-child for heterogeneous swap:
>>>=20
>>> #include <vector>
>>> #include <iostream>
>>>=20
>>> int main()
>>> {
>>> std::vector<bool> v(1);
>>> bool b =3D true;
>>> swap(b, v[0]);
>>> std::cout << v[0] << '\n';
>>> }
>>>=20
>>> The standard doesn't say this should work, but imho the standard is bro=
ken
>>> in that regard. It works in libc++ just as a personal expression of
>>> defiance. :-) Not sure if/where else.
>>=20
>> I agree something like this should work, but vector<bool> is rather spec=
ial
>> anyhow. The fix seems quite trivial for this specific case though, did y=
ou
>> have some more generic
>> problem in mind which i just failed to see?
>>=20
>>=20
>>>=20
>>> I don't know of a case where a heterogeneous swap is useful for being
>>> explicitly heterogeneous. It is usually useful as trying to masquerade=
as a
>>> homogeneous swap.
>>>=20
>> I think so too. Can you think of other "common" examples than vector<boo=
l>?
>>=20
>>=20
>> Mikael
>>=20
>=20
>=20
> If I can write (or similar):
>=20
> T t;
> U u;
> // swap them:
> T tmp =3D t;
> t =3D u;
> u =3D tmp; // or std::move(tmp)
>=20
> Then shouldn't I be able to swap them?
Yes, but only if T and U are the same type or if you've written a custom sw=
ap for T and U. The latter is how the swap(bool&, vector<bool>::reference)=
example works.
Howard
--=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.
.
Author: "Andrew C. Morrow" <andrew.c.morrow@gmail.com>
Date: Sat, 9 Feb 2013 13:52:08 -0500
Raw View
--e89a8f22beb94c9b3804d54f2cb8
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Thank you everyone for your comments, and I apologize for the week long
delay getting back to this thread. I'm going to try to summarize a bit and
I have several questions as well.
- As many pointed out, the underlying problem here is with ADL, not with
swap. If 'noexcept(auto)', or Jeffrey's thought to give special lookup
semantics to swap (or even all free functions in std), or some sort of
'using expression' were available, then std::is_swappable and
std::is_nothrow_swappable would be unnecessary. However, a language level
change will take some time. Is swap important enough to warrant special
handling in the short term via a library extension, even if the value of
is_[nothrow_]swappable is undermined by future language changes?
- declval<T> vs. declval<T&>: I think the argument in favor of declval<T>
was convincing to me. It does place some burden on the user , but I'd
imagine users of the type traits facilities are able to deal with that
burden. Unless there is a strong objection I will update my proposal along
these lines.
- Nikolay's comment on wording: I agree the wording is not sufficiently
precise, but I'm not familiar enough with the idioms of the standard to do
much better on my own so I did not attempt to perfect it. Suggestions on
how to improve wording anywhere it is weak in the proposal would be much
appreciated.
- Nikolay's alternative implementation: I like the compactness of it, but
the required changes to std::swap makes it less appealing to me. I do think
writing the proposed implementation as if it were within ::std is a good
idea, as it may reveal other problems, so I plan to update my proposal
similarly.
- Heterogeneous swap: My original implementation only handled homogeneous
swap. I added support for heterogeneous swap because of 17.6.3.2 paragraph
1 which sets up "swappable with" in terms of heterogeneous types. However,
20.2 only specifies homogeneous swap. Howard's example with vector<bool>
seems to make a case for supporting heterogeneous swap though. I'm happy to
follow guidance here from those who understand this area better.
- Symmetry for the heterogeneous case, assuming it is retained: If I'm
understanding correctly, I think the symmetry constraint can be enforced
easily for is_swappable: (ignoring possible declval<T> vs declval<T&>
changes here):
In is_swappable_test:
using test_type_tu =3D decltype(test<T, U>(std::declval<T&>(),
std::declval<U&>()));
using test_type_ut =3D decltype(test<U, T>(std::declval<U&>(),
std::declval<T&>()));
public:
static constexpr bool value =3D
!std::is_same<test_type_tu, swap_not_found_type>::value &&
!std::is_same<test_type_ut, swap_not_found_type>::value;
The proposal language would need to be updated to capture the symmetry
requirement as well but that seems straightforward.
I don't think any changes need to be made to is_nothrow_swappable: I don't
see that the standard says anything about the symmetrical overloads that
make types "swappable" sharing a noexcept status, so for that case I think
the argument order should be considered as provided by the caller.
Admittedly it seems strange to have one overload be noexcept and the other
not.
- Overall is there a general thought on whether this proposal has enough
merit to continue refining it?
Thanks,
Andrew
On Sat, Feb 9, 2013 at 11:15 AM, Howard Hinnant <howard.hinnant@gmail.com>w=
rote:
>
> On Feb 8, 2013, at 11:43 PM, Tony V E <tvaneerd@gmail.com> wrote:
>
> > On Fri, Feb 8, 2013 at 7:29 PM, Mikael Kilpel=E4inen
> > <mikael.kilpelainen@gmail.com> wrote:
> >> 9.2.2013 0:36, Howard Hinnant kirjoitti:
> >>
> >>> For me here is the poster-child for heterogeneous swap:
> >>>
> >>> #include <vector>
> >>> #include <iostream>
> >>>
> >>> int main()
> >>> {
> >>> std::vector<bool> v(1);
> >>> bool b =3D true;
> >>> swap(b, v[0]);
> >>> std::cout << v[0] << '\n';
> >>> }
> >>>
> >>> The standard doesn't say this should work, but imho the standard is
> broken
> >>> in that regard. It works in libc++ just as a personal expression of
> >>> defiance. :-) Not sure if/where else.
> >>
> >> I agree something like this should work, but vector<bool> is rather
> special
> >> anyhow. The fix seems quite trivial for this specific case though, did
> you
> >> have some more generic
> >> problem in mind which i just failed to see?
> >>
> >>
> >>>
> >>> I don't know of a case where a heterogeneous swap is useful for being
> >>> explicitly heterogeneous. It is usually useful as trying to
> masquerade as a
> >>> homogeneous swap.
> >>>
> >> I think so too. Can you think of other "common" examples than
> vector<bool>?
> >>
> >>
> >> Mikael
> >>
> >
> >
> > If I can write (or similar):
> >
> > T t;
> > U u;
> > // swap them:
> > T tmp =3D t;
> > t =3D u;
> > u =3D tmp; // or std::move(tmp)
> >
> > Then shouldn't I be able to swap them?
>
> Yes, but only if T and U are the same type or if you've written a custom
> swap for T and U. The latter is how the swap(bool&,
> vector<bool>::reference) example works.
>
> Howard
>
> --
>
> ---
> 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=3Den.
>
>
>
--=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.
--e89a8f22beb94c9b3804d54f2cb8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div style>Thank you everyone for your comments, and I=
apologize for the week long delay getting back to this thread. I'm goi=
ng to try to summarize a bit and I have several questions as well.</div><di=
v style>
<br></div><div style>- As many pointed out, the underlying problem here is =
with ADL, not with swap. If 'noexcept(auto)', or Jeffrey's thou=
ght to give special lookup semantics to swap (or even all free functions in=
std), or some sort of 'using expression' were available, then std:=
:is_swappable and std::is_nothrow_swappable would be=A0unnecessary. However=
, a language level change will take some time. Is swap important enough to =
warrant special handling in the short term via a library extension, even if=
the value of is_[nothrow_]swappable is undermined by future language chang=
es?</div>
<div style><br></div><div style>- declval<T> vs. declval<T&>=
;: I think the argument in favor of declval<T> was convincing to me. =
It does place some burden on the user , but I'd imagine users of the ty=
pe traits facilities are able to deal with that burden. Unless there is a s=
trong objection I will update my proposal along these lines.</div>
<div style><br></div><div style>- Nikolay's comment on wording: I agree=
the wording is not sufficiently precise, but I'm not familiar enough w=
ith the idioms of the standard to do much better on my own so I did not att=
empt to perfect it. Suggestions on how to improve wording anywhere it is we=
ak in the proposal would be much appreciated.</div>
<div style><br></div><div style>- Nikolay's alternative implementation:=
I like the compactness of it, but the required changes to std::swap makes =
it less appealing to me. I do think writing the proposed implementation as =
if it were within ::std is a good idea, as it may reveal other problems, so=
I plan to update my proposal similarly.</div>
<div style><br></div><div style>- Heterogeneous swap: My original implement=
ation only handled homogeneous swap. I added support for heterogeneous swap=
because of 17.6.3.2 paragraph 1 which sets up "swappable with" i=
n terms of heterogeneous types. However, 20.2 only specifies homogeneous sw=
ap. Howard's example with vector<bool> seems to make a case for s=
upporting heterogeneous swap though. I'm happy to follow guidance here =
from those who understand this area better.</div>
<div style><br></div><div style>- Symmetry for the heterogeneous case, assu=
ming it is retained: If I'm understanding correctly, I think the symmet=
ry constraint can be enforced easily for is_swappable: (ignoring possible d=
eclval<T> vs declval<T&> changes here):=A0</div>
<div style><br></div><div style>In is_swappable_test:</div><div style><br><=
/div><div style><div><font face=3D"courier new, monospace">=A0 =A0 =A0 =A0 =
=A0 =A0 using test_type_tu =3D decltype(test<T, U>(std::declval<T&=
amp;>(), std::declval<U&>()));</font></div>
<div><font face=3D"courier new, monospace">=A0 =A0 =A0 =A0 =A0 =A0 using te=
st_type_ut =3D decltype(test<U, T>(std::declval<U&>(), std:=
:declval<T&>()));</font></div><div><br></div><div><font face=3D"c=
ourier new, monospace">=A0 =A0 =A0 =A0 public:</font></div>
<div><font face=3D"courier new, monospace">=A0 =A0 =A0 =A0 =A0 =A0 static c=
onstexpr bool value =3D</font></div><div><font face=3D"courier new, monospa=
ce">=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 !std::is_same<test_type_tu, swap_not=
_found_type>::value &&</font></div>
<div><font face=3D"courier new, monospace">=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
!std::is_same<test_type_ut, swap_not_found_type>::value;</font></div>=
<div><br></div><div style>The proposal language would need to be updated to=
capture the symmetry requirement as well but that seems straightforward.</=
div>
<div><br></div></div>
<div style>I don't think any changes need to be made to is_nothrow_swap=
pable: I don't see that the standard says anything about the symmetrica=
l overloads that make types "swappable" sharing a noexcept status=
, so for that case I think the argument order should be considered as provi=
ded by the caller. Admittedly it seems strange to have one overload be noex=
cept and the other not.</div>
<div style><br></div><div style>- Overall is there a general thought on whe=
ther this proposal has enough merit to continue refining it?</div><div styl=
e><br></div><div style>Thanks,</div><div style>Andrew</div><div style><br>
</div><div style><br></div></div><div class=3D"gmail_extra"><br><br><div cl=
ass=3D"gmail_quote">On Sat, Feb 9, 2013 at 11:15 AM, Howard Hinnant <span d=
ir=3D"ltr"><<a href=3D"mailto:howard.hinnant@gmail.com" target=3D"_blank=
">howard.hinnant@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5"><br>
On Feb 8, 2013, at 11:43 PM, Tony V E <<a href=3D"mailto:tvaneerd@gmail.=
com">tvaneerd@gmail.com</a>> wrote:<br>
<br>
> On Fri, Feb 8, 2013 at 7:29 PM, Mikael Kilpel=E4inen<br>
> <<a href=3D"mailto:mikael.kilpelainen@gmail.com">mikael.kilpelainen=
@gmail.com</a>> wrote:<br>
>> 9.2.2013 0:36, Howard Hinnant kirjoitti:<br>
>><br>
>>> For me here is the poster-child for heterogeneous swap:<br>
>>><br>
>>> #include <vector><br>
>>> #include <iostream><br>
>>><br>
>>> int main()<br>
>>> {<br>
>>> =A0 =A0 std::vector<bool> v(1);<br>
>>> =A0 =A0 bool b =3D true;<br>
>>> =A0 =A0 swap(b, v[0]);<br>
>>> =A0 =A0 std::cout << v[0] << '\n';<br>
>>> }<br>
>>><br>
>>> The standard doesn't say this should work, but imho the st=
andard is broken<br>
>>> in that regard. =A0It works in libc++ just as a personal expre=
ssion of<br>
>>> defiance. :-) =A0Not sure if/where else.<br>
>><br>
>> I agree something like this should work, but vector<bool> is=
rather special<br>
>> anyhow. The fix seems quite trivial for this specific case though,=
did you<br>
>> have some more generic<br>
>> problem in mind which i just failed to see?<br>
>><br>
>><br>
>>><br>
>>> I don't know of a case where a heterogeneous swap is usefu=
l for being<br>
>>> explicitly heterogeneous. =A0It is usually useful as trying to=
masquerade as a<br>
>>> homogeneous swap.<br>
>>><br>
>> I think so too. Can you think of other "common" examples=
than vector<bool>?<br>
>><br>
>><br>
>> Mikael<br>
>><br>
><br>
><br>
> If I can write (or similar):<br>
><br>
> T t;<br>
> U u;<br>
> // swap them:<br>
> T tmp =3D t;<br>
> t =3D u;<br>
> u =3D tmp; =A0// or std::move(tmp)<br>
><br>
> Then shouldn't I be able to swap them?<br>
<br>
</div></div>Yes, but only if T and U are the same type or if you've wri=
tten a custom swap for T and U. =A0The latter is how the swap(bool&, ve=
ctor<bool>::reference) example works.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Howard<br>
</font></span><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"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den" target=3D"_blank">http://groups.google.com/a/isocpp=
..org/group/std-proposals/?hl=3Den</a>.<br>
<br>
<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--e89a8f22beb94c9b3804d54f2cb8--
.
Author: Nikolay Ivchenkov <mk.ivchenkov@gmail.com>
Date: Sat, 9 Feb 2013 14:13:14 -0800 (PST)
Raw View
------=_Part_113_29458836.1360447994470
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Saturday, February 9, 2013 10:52:08 PM UTC+4, Andrew Morrow wrote:
>
> - Nikolay's comment on wording: I agree the wording is not sufficiently=
=20
> precise, but I'm not familiar enough with the idioms of the standard to d=
o=20
> much better on my own so I did not attempt to perfect it. Suggestions on=
=20
> how to improve wording anywhere it is weak in the proposal would be much=
=20
> appreciated.=20
>
First, I think that Table 49 would be more appropriate place for describing=
=20
is_swappable an is_nothrow_swappable.
You can specify conditions and preconditions similarly to=20
std::is_assignable and std::is_nothrow_assignable (see N3485 - =A7 20.9.4.3=
-=20
Table 49). For is_swappable trait the expression declval<T>() =3D=20
declval<U>() would be replaced with two expressions swap(declval<T>(),=20
declval<U>()) and swap(declval<U>(), declval<T>()), with the following=20
addition:
The context in which the aforementioned expressions are considered=20
shall ensure that a candidate set for "swap" consists of the two swap=20
function templates defined in <utility> (20.2) and the lookup set produced=
=20
by argument-dependent lookup (3.4.2).
- Nikolay's alternative implementation: I like the compactness of it,
>
It could be much more compact if we would have a proper core language=20
support:
is_well_formed ( expression )
is_well_formed ( type-id )=20
is_well_formed compound-statement
is_nothrow_well_formed ( expression )
is_nothrow_well_formed compound-statement
-----------------------------------------------------------
namespace std
{
template <bool C>
using bool_constant =3D integral_constant<bool, C>;
template <class T, class U>
struct is_swappable :
bool_constant
<
is_well_formed(swap(declval<T>(), declval<U>())) &&
is_well_formed(swap(declval<U>(), declval<T>()))
>
template <class T, class U>
struct is_nothrow_swappable :
bool_constant
<
is_swappable<T, U>{} &&
is_nothrow_well_formed(swap(declval<T>(), declval<U>()))
>
template <class T, class... Params>
struct is_constructible :
bool_constant
<
is_well_formed{ T t(declval<Params>()...); }
>
{};
template <class T, class... Params>
struct is_nothrow_constructible :
bool_constant
<
is_nothrow_well_formed{ T t(declval<Params>()...); }
>
{};
template <class T, class U>
struct is_affined :
is_same<T const volatile, U const volatile> {};
template <class From, class To>
struct is_nothrow_convertible :
bool_constant
<
is_affined<From, void>{} && is_affined<To, void>{} ||
is_nothrow_well_formed
{
void test(To) noexcept;
(test)(declval<From>());
}
> {};
}
-----------------------------------------------------------
=20
> but the required changes to std::swap makes it less appealing to me.
>
I don't see any solution that would be correct and more simple.
--=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_113_29458836.1360447994470
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Saturday, February 9, 2013 10:52:08 PM UTC+4, Andrew Morrow wrote:<block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">- Nikolay's comment=
on wording: I agree the wording is not sufficiently precise, but I'm not f=
amiliar enough with the idioms of the standard to do much better on my own =
so I did not attempt to perfect it. Suggestions on how to improve wording a=
nywhere it is weak in the proposal would be much appreciated.
</div></blockquote><div><br>First, I think that Table 49 would be more appr=
opriate place for describing is_swappable an is_nothrow_swappable.<br>You c=
an specify conditions and preconditions similarly to std::is_assignable and=
std::is_nothrow_assignable (see N3485 - =A7 20.9.4.3 - Table 49). For is_s=
wappable trait the expression declval<T>() =3D declval<U>() wou=
ld be replaced with two expressions swap(declval<T>(), declval<U&g=
t;()) and swap(declval<U>(), declval<T>()), with the following =
addition:<br><br> The context in which the aforementioned=
expressions are considered shall ensure that a candidate set for "swap" co=
nsists of the two swap function templates defined in <utility> (20.2)=
and the lookup set produced by argument-dependent lookup (3.4.2).<br><br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></d=
iv><div>- Nikolay's alternative implementation: I like the compactness of i=
t,</div></div></blockquote><div><br>It could be much more compact if we wou=
ld have a proper core language support:<br><br> is_well_f=
ormed ( expression )<br> is_well_formed ( type-id ) <br>&=
nbsp; is_well_formed compound-statement<br><br> &nbs=
p; is_nothrow_well_formed ( expression )<br> is_nothrow_w=
ell_formed compound-statement<br><br>--------------------------------------=
---------------------<br>namespace std<br>{<br> template =
<bool C><br> using bool_con=
stant =3D integral_constant<bool, C>;<br><br> templ=
ate <class T, class U><br> =
struct is_swappable :<br> &n=
bsp; bool_constant<br>  =
; <<br>  =
; is_well_formed(swap(declv=
al<T>(), declval<U>())) &&<br> &=
nbsp; is_well_f=
ormed(swap(declval<U>(), declval<T>()))<br> &n=
bsp; ><br><br> &nbs=
p; template <class T, class U><br>  =
; struct is_nothrow_swappable :<br> &nbs=
p; bool_constant<br> &=
nbsp; <<br> &=
nbsp; is_swappa=
ble<T, U>{} &&<br> &=
nbsp; is_nothrow_well_formed(swap=
(declval<T>(), declval<U>()))<br> =
><br><br> templat=
e <class T, class... Params><br> &=
nbsp; struct is_constructible :<br> &nbs=
p; bool_constant<br> &=
nbsp; <<br> &=
nbsp; is_well_formed{=
T t(declval<Params>()...); }<br> =
><br> {};<br><br> =
template <class T, class... Params><br>  =
; struct is_nothrow_constructible :<br> =
bool_constant<br>&nb=
sp; <<br>&nb=
sp; =
is_nothrow_well_formed{ T t(declval<Params>()...); }<br>=
><br>=
{};<br><br> template <class T, clas=
s U><br> struct is_affined :<b=
r> is_sam=
e<T const volatile, U const volatile> {};<br><br> t=
emplate <class From, class To><br>  =
; struct is_nothrow_convertible :<br> &n=
bsp; bool_constant<br>  =
; <<br>  =
; is_affi=
ned<From, void>{} && is_affined<To, void>{} ||<br> =
; &n=
bsp; is_nothrow_well_formed<br> &n=
bsp; {<br>  =
; &n=
bsp; void test(To) noexcept;<br> &=
nbsp; &nbs=
p; (test)(declval<From>());<br> &n=
bsp; }<br> =
; > {};<br>}=
<br>-----------------------------------------------------------<br> </=
div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div> but=
the required changes to std::swap makes it less appealing to me.</div></di=
v></blockquote><div><br>I don't see any solution that would be correct and =
more simple.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_113_29458836.1360447994470--
.
Author: "Andrew C. Morrow" <andrew.c.morrow@gmail.com>
Date: Sun, 3 Mar 2013 21:48:02 -0500
Raw View
--bcaec55553bcb4a27704d7106233
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Based on the feedback and discussion in this thread, I have updated my
proposal for the addition of std::is_swappable and
std::is_nothrow_swappable as follows:
- Changed from declval<T&> to declval<T>, and for U.
- Added the swap(t,u) swap(u, t) symmetry requirement for is_swappable.
- Switched from "type relationship" to "type properties"
- Proposed additions are now to Table 49, rather than table 51.
- Adopted Nikolay's proposed wording for table 49.
- Updated the example implementation as if it were actually being written
in 'namespace std' for a standard library header implementation.
The updated draft can be found here:
http://acmorrow.github.com/swap_traits/nXXXX.html
On Sat, Feb 9, 2013 at 5:13 PM, Nikolay Ivchenkov <mk.ivchenkov@gmail.com>w=
rote:
> On Saturday, February 9, 2013 10:52:08 PM UTC+4, Andrew Morrow wrote:
>>
>> - Nikolay's comment on wording: I agree the wording is not sufficiently
>> precise, but I'm not familiar enough with the idioms of the standard to =
do
>> much better on my own so I did not attempt to perfect it. Suggestions on
>> how to improve wording anywhere it is weak in the proposal would be much
>> appreciated.
>>
>
> First, I think that Table 49 would be more appropriate place for
> describing is_swappable an is_nothrow_swappable.
> You can specify conditions and preconditions similarly to
> std::is_assignable and std::is_nothrow_assignable (see N3485 - =A7 20.9.4=
..3 -
> Table 49). For is_swappable trait the expression declval<T>() =3D
> declval<U>() would be replaced with two expressions swap(declval<T>(),
> declval<U>()) and swap(declval<U>(), declval<T>()), with the following
> addition:
>
> The context in which the aforementioned expressions are considered
> shall ensure that a candidate set for "swap" consists of the two swap
> function templates defined in <utility> (20.2) and the lookup set produce=
d
> by argument-dependent lookup (3.4.2).
>
> - Nikolay's alternative implementation: I like the compactness of it,
>>
>
> It could be much more compact if we would have a proper core language
> support:
>
> is_well_formed ( expression )
> is_well_formed ( type-id )
> is_well_formed compound-statement
>
> is_nothrow_well_formed ( expression )
> is_nothrow_well_formed compound-statement
>
> -----------------------------------------------------------
> namespace std
> {
> template <bool C>
> using bool_constant =3D integral_constant<bool, C>;
>
>
> template <class T, class U>
> struct is_swappable :
> bool_constant
> <
> is_well_formed(swap(declval<T>(), declval<U>())) &&
> is_well_formed(swap(declval<U>(), declval<T>()))
>
> >
>
> template <class T, class U>
> struct is_nothrow_swappable :
> bool_constant
> <
> is_swappable<T, U>{} &&
> is_nothrow_well_formed(swap(declval<T>(), declval<U>()))
> >
>
> template <class T, class... Params>
> struct is_constructible :
> bool_constant
> <
> is_well_formed{ T t(declval<Params>()...); }
> >
> {};
>
> template <class T, class... Params>
> struct is_nothrow_constructible :
> bool_constant
> <
> is_nothrow_well_formed{ T t(declval<Params>()...); }
> >
> {};
>
>
> template <class T, class U>
> struct is_affined :
> is_same<T const volatile, U const volatile> {};
>
> template <class From, class To>
> struct is_nothrow_convertible :
> bool_constant
> <
> is_affined<From, void>{} && is_affined<To, void>{} ||
> is_nothrow_well_formed
> {
> void test(To) noexcept;
> (test)(declval<From>());
> }
> > {};
> }
> -----------------------------------------------------------
>
>
>> but the required changes to std::swap makes it less appealing to me.
>>
>
> I don't see any solution that would be correct and more simple.
>
> --
>
> ---
> 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=3Den.
>
>
>
--=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.
--bcaec55553bcb4a27704d7106233
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Based on the feedback and discussion in this thread, =
I have updated my proposal for the addition of <font face=3D"courier new, m=
onospace">std::is_swappable</font> and <font face=3D"courier new, monospace=
">std::is_nothrow_swappable=A0</font>as follows:<br>
</div><div><br></div><div style>- Changed from declval<T&> to dec=
lval<T>, and for U.</div><div style>- Added the swap(t,u) swap(u, t) =
symmetry requirement for is_swappable.</div><div style>- Switched from &quo=
t;type relationship" to "type properties"</div>
<div style>- Proposed additions are now to Table 49, rather than table 51.<=
/div><div style>- Adopted Nikolay's proposed wording for table 49.</div=
><div style>- Updated the example implementation as if it were actually bei=
ng written in 'namespace std' for a standard library header impleme=
ntation.</div>
<div><br></div><div><div style=3D"font-family:arial,sans-serif;font-size:13=
px">The updated draft can be found here:=A0<a href=3D"http://acmorrow.githu=
b.com/swap_traits/nXXXX.html" target=3D"_blank">http://acmorrow.github.com/=
swap_traits/nXXXX.html</a></div>
</div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">O=
n Sat, Feb 9, 2013 at 5:13 PM, Nikolay Ivchenkov <span dir=3D"ltr"><<a h=
ref=3D"mailto:mk.ivchenkov@gmail.com" target=3D"_blank">mk.ivchenkov@gmail.=
com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Saturday, February 9, 2=
013 10:52:08 PM UTC+4, Andrew Morrow wrote:<blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">
<div dir=3D"ltr">- Nikolay's comment on wording: I agree the wording is=
not sufficiently precise, but I'm not familiar enough with the idioms =
of the standard to do much better on my own so I did not attempt to perfect=
it. Suggestions on how to improve wording anywhere it is weak in the propo=
sal would be much appreciated.
</div></blockquote></div><div><br>First, I think that Table 49 would be mor=
e appropriate place for describing is_swappable an is_nothrow_swappable.<br=
>You can specify conditions and preconditions similarly to std::is_assignab=
le and std::is_nothrow_assignable (see N3485 - =A7 20.9.4.3 - Table 49). Fo=
r is_swappable trait the expression declval<T>() =3D declval<U>=
() would be replaced with two expressions swap(declval<T>(), declval&=
lt;U>()) and swap(declval<U>(), declval<T>()), with the foll=
owing addition:<br>
<br>=A0=A0=A0 The context in which the aforementioned expressions are consi=
dered shall ensure that a candidate set for "swap" consists of th=
e two swap function templates defined in <utility> (20.2) and the loo=
kup set produced by argument-dependent lookup (3.4.2).<br>
<br></div><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><div></div><div>- Nikolay's alternative implementation: I lik=
e the compactness of it,</div>
</div></blockquote></div><div><br>It could be much more compact if we would=
have a proper core language support:<br><br>=A0=A0=A0 is_well_formed ( exp=
ression )<br>=A0=A0=A0 is_well_formed ( type-id ) <br>=A0=A0=A0 is_well_for=
med compound-statement<br>
<br>=A0=A0=A0 is_nothrow_well_formed ( expression )<br>=A0=A0=A0 is_nothrow=
_well_formed compound-statement<br><br>------------------------------------=
-----------------------<br>namespace std<br>{<br>=A0=A0=A0 template <boo=
l C><br>=A0=A0=A0=A0=A0=A0=A0 using bool_constant =3D integral_constant&=
lt;bool, C>;<div class=3D"im">
<br><br>=A0=A0=A0 template <class T, class U><br></div>=A0=A0=A0=A0=
=A0=A0=A0 struct is_swappable :<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 bool_c=
onstant<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <<br>=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0 is_well_formed(swap(declval<T>(), declval<=
;U>())) &&<br>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 is_well_formed(swap(declval&l=
t;U>(), declval<T>()))<div class=3D"im"><br>=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 ><br><br>=A0=A0=A0 template <class T, class U><br></d=
iv>=A0=A0=A0=A0=A0=A0=A0 struct is_nothrow_swappable :<br>=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0 bool_constant<br>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 is_swappable<T, U>{} &&<br>=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0 is_nothrow_well_formed(swap(declval<T>(), de=
clval<U>()))<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ><br><br>=A0=A0=
=A0 template <class T, class... Params><br>
=A0=A0=A0=A0=A0=A0=A0 struct is_constructible :<br>=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0 bool_constant<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <<br>=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 is_well_formed{ T t(declval<Para=
ms>()...); }<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ><br>=A0=A0=A0 {};<=
br><br>=A0=A0=A0 template <class T, class... Params><br>
=A0=A0=A0=A0=A0=A0=A0 struct is_nothrow_constructible :<br>=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0 bool_constant<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <<=
br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 is_nothrow_well_formed{ T =
t(declval<Params>()...); }<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ><=
br>=A0=A0=A0 {};<div class=3D"im"><br><br>
=A0=A0=A0 template <class T, class U><br></div>=A0=A0=A0=A0=A0=A0=A0 =
struct is_affined :<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 is_same<T const=
volatile, U const volatile> {};<br><br>=A0=A0=A0 template <class Fro=
m, class To><br>=A0=A0=A0=A0=A0=A0=A0 struct is_nothrow_convertible :<br=
>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 bool_constant<br>=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0 <<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 is_affined&=
lt;From, void>{} && is_affined<To, void>{} ||<br>=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 is_nothrow_well_formed<br>=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 {<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 void test(To) noexcept;<br>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (test)(declval<=
;From>());<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 }<br>=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0 > {};<br>}<br>------------------------------=
-----------------------------<br>=A0</div><div class=3D"im"><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
solid;padding-left:1ex">
<div dir=3D"ltr"><div> but the required changes to std::swap makes it less =
appealing to me.</div></div></blockquote></div><div><br>I don't see any=
solution that would be correct and more simple.<br></div><div class=3D"HOE=
nZb">
<div class=3D"h5">
<p></p>
-- <br>
=A0<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" 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"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den" target=3D"_blank">http://groups.google.com/a/isocpp=
..org/group/std-proposals/?hl=3Den</a>.<br>
=A0<br>
=A0<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--bcaec55553bcb4a27704d7106233--
.
Author: =?ISO-8859-1?Q?Mikael_Kilpel=E4inen?=
Date: Mon, 04 Mar 2013 10:55:12 +0100
Raw View
This is a multi-part message in MIME format.
--------------090406080000030909090508
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Based on the feedback and discussion in this thread, I have updated my
> proposal for the addition of std::is_swappable and
> std::is_nothrow_swappable as follows:
>
> - Changed from declval<T&> to declval<T>, and for U.
> - Added the swap(t,u) swap(u, t) symmetry requirement for is_swappable.
> - Switched from "type relationship" to "type properties"
> - Proposed additions are now to Table 49, rather than table 51.
> - Adopted Nikolay's proposed wording for table 49.
> - Updated the example implementation as if it were actually being
> written in 'namespace std' for a standard library header implementation.
>
> The updated draft can be found here:
> http://acmorrow.github.com/swap_traits/nXXXX.html
>
Looking good, I will take closer look when I have time but small remark
now..
"The context in which the aforementioned expressions are considered
shall ensure that a candidate set for swap consists of the two swap
function templates defined in <utility> (20.2) and the lookup set
produced by argument-dependent lookup (3.4.2)."
I assume this means one has to explicitly include <utility> when ever
these traits are used.
Then the wording seems bit vague though, how do I ensure those swap
functions will be candidates if I don't know how it is implemented?
I would rather see something like "if the header <utility> is not
included prior to a use of these traits the program is ill-formed".
Another option would be to specify that the new header includes
<utility> which i think is fine, in which case that needs to be added to
the synopsis.
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.
--------------090406080000030909090508
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">
<br>
<blockquote
cite="mid:CA+Acj4ft_5NaSQQsksMRgfXAGW3e-sCLTHK-CaipWPdc6RxwQA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>Based on the feedback and discussion in this thread, I have
updated my proposal for the addition of <font face="courier
new, monospace">std::is_swappable</font> and <font
face="courier new, monospace">std::is_nothrow_swappable </font>as
follows:<br>
</div>
<div><br>
</div>
<div style="">- Changed from declval<T&> to
declval<T>, and for U.</div>
<div style="">- Added the swap(t,u) swap(u, t) symmetry
requirement for is_swappable.</div>
<div style="">- Switched from "type relationship" to "type
properties"</div>
<div style="">- Proposed additions are now to Table 49, rather
than table 51.</div>
<div style="">- Adopted Nikolay's proposed wording for table 49.</div>
<div style="">- Updated the example implementation as if it were
actually being written in 'namespace std' for a standard
library header implementation.</div>
<div><br>
</div>
<div>
<div style="font-family:arial,sans-serif;font-size:13px">The
updated draft can be found here: <a moz-do-not-send="true"
href="http://acmorrow.github.com/swap_traits/nXXXX.html"
target="_blank">http://acmorrow.github.com/swap_traits/nXXXX.html</a></div>
</div>
</div>
<div class="gmail_extra"><br>
</div>
</blockquote>
Looking good, I will take closer look when I have time but small
remark now..<br>
<br>
"The context in which the aforementioned expressions are considered
shall ensure that a candidate set for swap consists of the two swap
function templates defined in <utility> (20.2) and the lookup
set produced by argument-dependent lookup (3.4.2)."<br>
<br>
I assume this means one has to explicitly include <utility>
when ever these traits are used. <br>
Then the wording seems bit vague though, how do I ensure those swap
functions will be candidates if I don't know how it is implemented?<br>
I would rather see something like "if the header <utility> is
not included prior to a use of these traits the program is
ill-formed".<br>
<br>
Another option would be to specify that the new header includes
<utility> which i think is fine, in which case that needs to
be added to the synopsis.<br>
<br>
<br>
Mikael<br>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
<br />
<br />
--------------090406080000030909090508--
.
Author: "Andrew C. Morrow" <andrew.c.morrow@gmail.com>
Date: Wed, 6 Mar 2013 10:36:00 -0500
Raw View
--bcaec54eea70dba85004d7435858
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Mon, Mar 4, 2013 at 4:55 AM, Mikael Kilpel=E4inen <
mikael.kilpelainen@gmail.com> wrote:
>
> Looking good, I will take closer look when I have time but small
> remark now..
>
>
> "The context in which the aforementioned expressions are considered shall
> ensure that a candidate set for swap consists of the two swap function
> templates defined in <utility> (20.2) and the lookup set produced by
> argument-dependent lookup (3.4.2)."
>
> I assume this means one has to explicitly include <utility> when ever
> these traits are used.
> Then the wording seems bit vague though, how do I ensure those swap
> functions will be candidates if I don't know how it is implemented?
> I would rather see something like "if the header <utility> is not include=
d
> prior to a use of these traits the program is ill-formed".
>
> Another option would be to specify that the new header includes <utility>
> which i think is fine, in which case that needs to be added to the synops=
is.
>
>
> Mikael
>
>
Thanks Mikael.
Your suggestion to just specify that <utility> is included by the new
header seems better to me. The alternative just introduces yet another way
to write an ill-formed program. I've updated the <swap_traits> synopsis
accordingly.
While doing so I realized that some of the section references, names, and
titles were made incorrect after changing from Table 51 to Table 49, so
I've fixed those up too.
http://acmorrow.github.com/swap_traits/nXXXX.html
Andrew
--=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.
--bcaec54eea70dba85004d7435858
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Mon, Mar 4, 2013 at 4:55 AM, Mikael Kilpel=E4inen <span dir=3D"l=
tr"><<a href=3D"mailto:mikael.kilpelainen@gmail.com" target=3D"_blank">m=
ikael.kilpelainen@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000"><div class=3D"im"><br><blockquo=
te type=3D"cite">
<div dir=3D"ltr">
<div>
</div>
</div>
=20
</blockquote></div>
Looking good, I will take closer look when I have time but small
remark now..<div class=3D"im"><br>
<br>
"The context in which the aforementioned expressions are considere=
d
shall ensure that a candidate set for swap consists of the two swap
function templates defined in <utility> (20.2) and the lookup
set produced by argument-dependent lookup (3.4.2)."<br>
<br></div>
I assume this means one has to explicitly include <utility>
when ever these traits are used. <br>
Then the wording seems bit=A0 vague though, how do I ensure those swap
functions will be candidates if I don't know how it is implemented?=
<br>
I would rather see something like "if the header <utility> i=
s
not included prior to a use of these traits the program is
ill-formed".<br>
<br>
Another option would be to specify that the new header includes
<utility> which i think is fine, in which case that needs to
be added to the synopsis.<span class=3D""><font color=3D"#888888"><br>
<br>
<br>
Mikael<br>
<br>
</font></span></div>
</blockquote></div><br></div><div class=3D"gmail_extra"><div class=3D"gmail=
_extra">Thanks Mikael.</div><div class=3D"gmail_extra"><br></div><div class=
=3D"gmail_extra">Your suggestion to just specify that <utility> is in=
cluded by the new header seems better to me. The alternative just introduce=
s yet another way to write an ill-formed program. I've updated the <=
swap_traits> synopsis accordingly.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">While doing=
so I realized that some of the section references, names, and titles were =
made incorrect after changing from Table 51 to Table 49, so I've fixed =
those up too.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><a href=3D"=
http://acmorrow.github.com/swap_traits/nXXXX.html">http://acmorrow.github.c=
om/swap_traits/nXXXX.html</a></div><div class=3D"gmail_extra"><br></div><di=
v class=3D"gmail_extra">
Andrew</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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--bcaec54eea70dba85004d7435858--
.
Author: =?ISO-8859-1?Q?Mikael_Kilpel=E4inen?=
Date: Wed, 06 Mar 2013 18:19:17 +0100
Raw View
>
> http://acmorrow.github.com/swap_traits/nXXXX.html
>
a few more comments.
In the introduction:
"The former will derive from std::true_type if the expression
'swap(declval<T&>(), declval<U&>())' resolves"
You should remove the & like other places, also this is not exactly true
any more because of the symmetry requirement.
Constructors/Public Data:
- Do you need to say these here as the UnaryTypeTrait already sets
requirements. It seems those requirements might not
be exactly the same.
Alternative Designs:
"in the noexcept oeprator would"
Just a typo.
You forgot to update the heading as 20.9.4.3 is "Type properties" and
not "Relationships between types".
It seems to me that the is_nothrow_swappable should have the same
symmetry requirement.
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.
.
Author: "Andrew C. Morrow" <andrew.c.morrow@gmail.com>
Date: Sun, 10 Mar 2013 15:49:21 -0400
Raw View
--e89a8f22beb94f93da04d7975ac1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Wed, Mar 6, 2013 at 12:19 PM, Mikael Kilpel=E4inen <
mikael.kilpelainen@gmail.com> wrote:
>
>>
>> http://acmorrow.github.com/swap_traits/nXXXX.html
>>
> a few more comments.
Thanks! Replies inline below, and a new draft has been pushed.
>
> In the introduction:
> "The former will derive from std::true_type if the expression
> 'swap(declval<T&>(), declval<U&>())' resolves"
> You should remove the & like other places, also this is not exactly true
any
> more because of the symmetry requirement.
Done, I think.
>
> Constructors/Public Data:
> - Do you need to say these here as the UnaryTypeTrait already sets
> requirements. It seems those requirements might not
> be exactly the same.
Agreed it is redundant. I've removed it.
>
> Alternative Designs:
> "in the noexcept oeprator would"
> Just a typo.
Done.
>
> You forgot to update the heading as 20.9.4.3 is "Type properties" and not
> "Relationships between types".
Done.
>
> It seems to me that the is_nothrow_swappable should have the same symmetr=
y
> requirement.
I think I disagree. I don't see anything in 17.6.3.2 that requires two swap
implementations forming a heterogeneous swap pair to share a noexcept
status:
class Foo {};
class Bar {};
void swap(Foo& f, Bar& b) noexcept {
// ...
}
void swap(Bar& b, Foo& f) {
// ...
}
So is_swappable<Foo, Bar>::value and is_swappable<Bar, Foo>::value should
clearly both be true_type, along with is_nothrow_swappable<Foo, Bar>::value=
,
but I think is_nothrow_swappable<Bar, Foo>::value should still be false_typ=
e
..
Perhaps it would make sense to add noexcept status to the symmetry
constraints of 17.6.3.2, and then is_nothrow_swappable could be tightened
up, but given what is there now I don't think the symmetry requirement
which applies to std::is_swappable
propagates to std::is_nothrow_swappable.
--=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.
--e89a8f22beb94f93da04d7975ac1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wed, Mar 6, 2013 at 12:19 PM, Mikael Kilpel=E4i=
nen <<a href=3D"mailto:mikael.kilpelainen@gmail.com">mikael.kilpelainen@=
gmail.com</a>> wrote:<br>><br>>><br>>> <a href=3D"http://=
acmorrow.github.com/swap_traits/nXXXX.html">http://acmorrow.github.com/swap=
_traits/nXXXX.html</a><br>
>><br>> a few more comments.<div><br></div><div style>Thanks! Repl=
ies inline below, and a new draft has been pushed.</div><div><br>><br>&g=
t; In the introduction:<br>> "The former will derive from std::true=
_type if the expression<br>
> 'swap(declval<T&>(), declval<U&>())' resol=
ves"<br>> You should remove the & like other places, also this =
is not exactly true any<br>> more because of the symmetry requirement.<d=
iv>
<br></div><div>Done, I think.</div><div><br>><br>> Constructors/Publi=
c Data:<br>> - Do you need to say these here as the UnaryTypeTrait alrea=
dy sets<br>> requirements. It seems those requirements might not<br>
> be exactly the same.</div><div><br></div><div>Agreed it is redundant. =
I've removed it.</div><div><br>><br>> Alternative Designs:<br>>=
; "in the noexcept oeprator would"<br>> Just a typo.</div>
<div><br></div><div>Done.</div><div><br>><br>> You forgot to update t=
he heading as 20.9.4.3 is "Type properties" and not<br>> "=
;Relationships between types".</div><div><br></div><div>Done.</div>
<div><br>><br>> It seems to me that the is_nothrow_swappable should h=
ave the same symmetry<br>> requirement.</div><div><br></div><div>I think=
I disagree. I don't see anything in 17.6.3.2 that requires two swap im=
plementations forming a heterogeneous swap pair to share a noexcept status:=
</div>
<div><br></div><div><font face=3D"courier new, monospace">class Foo {};</fo=
nt></div><div><font face=3D"courier new, monospace">class Bar {};</font></d=
iv><div><font face=3D"courier new, monospace"><br></font></div><div><font f=
ace=3D"courier new, monospace">void swap(Foo& f, Bar& b) noexcept {=
</font></div>
<div><font face=3D"courier new, monospace">=A0 // ...</font></div><div><fon=
t face=3D"courier new, monospace">}</font></div><div><font face=3D"courier =
new, monospace"><br></font></div><div><font face=3D"courier new, monospace"=
>void swap(Bar& b, Foo& f) {</font></div>
<div><font face=3D"courier new, monospace">=A0 // ...</font></div><div><fon=
t face=3D"courier new, monospace">}</font></div><div><br></div><div>So <fon=
t face=3D"courier new, monospace">is_swappable<Foo, Bar>::value</font=
> and <font face=3D"courier new, monospace">is_swappable<Bar, Foo>::v=
alue</font> should clearly both be <font face=3D"courier new, monospace">tr=
ue_type</font>, along with <font face=3D"courier new, monospace">is_nothrow=
_swappable<Foo, Bar>::value</font>, but I think=A0<font face=3D"couri=
er new, monospace">is_nothrow_swappable<Bar, Foo>::value</font> shoul=
d still be <font face=3D"courier new, monospace">false_type</font>.</div>
<div><br></div><div style>Perhaps it would make sense to add noexcept statu=
s to the symmetry constraints of 17.6.3.2, and then=A0<font face=3D"courier=
new, monospace">is_nothrow_swappable=A0</font>could be tightened up, but g=
iven what is there now I don't think the symmetry requirement which app=
lies to <font face=3D"courier new, monospace">std::is_swappable</font></div=
>
<div style>propagates to <font face=3D"courier new, monospace">std::is_noth=
row_swappable</font>.</div></div><div style><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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--e89a8f22beb94f93da04d7975ac1--
.
Author: =?ISO-8859-1?Q?Mikael_Kilpel=E4inen?=
Date: Sun, 10 Mar 2013 23:08:43 +0100
Raw View
This is a multi-part message in MIME format.
--------------000104060603090708050907
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
10.3.2013 20:49, Andrew C. Morrow kirjoitti:
>
> I think I disagree. I don't see anything in 17.6.3.2 that requires two
> swap implementations forming a heterogeneous swap pair to share a
> noexcept status:
>
> class Foo {};
> class Bar {};
>
> void swap(Foo& f, Bar& b) noexcept {
> // ...
> }
>
> void swap(Bar& b, Foo& f) {
> // ...
> }
>
> So is_swappable<Foo, Bar>::value and is_swappable<Bar, Foo>::value
> should clearly both be true_type, along with is_nothrow_swappable<Foo,
> Bar>::value, but I think is_nothrow_swappable<Bar, Foo>::value should
> still be false_type.
>
Right, it just feels weird since the swappable itself has symmetry
constraint. Also since the symmetry constraint says the two swapping
expressions
produce the same outcome it would imply so, not forcing the noexcept
though. I am not sure how to interpret the 17.6.3.2/2
"An object t is swappable with an object u if and only if:
--- the expressions swap(t, u) and swap(u, t) are valid when
evaluated in the context described below,
and
--- these expressions have the following effects:
--- the object referred to by t has the value originally held
by u and
--- the object referred to by u has the value originally held
by t."
Now if I throw exception the last two sentences are not true any more.
So one could even read this that no exceptions can be thrown which seems
overly tight
and was not meant most likely. Am I missing something here?
Would having is_value_swappable make sense for convenience (per 17.6.3.2/5)?
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.
--------------000104060603090708050907
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">
<div class="moz-cite-prefix">10.3.2013 20:49, Andrew C. Morrow
kirjoitti:<br>
</div>
<br>
<blockquote
cite="mid:CA+Acj4eMWx1O-5H8yTt-8WVpcqods=Wi3eYM1WNtGsJzshfg6w@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
<div>I think I disagree. I don't see anything in 17.6.3.2 that
requires two swap implementations forming a heterogeneous
swap pair to share a noexcept status:</div>
<div><br>
</div>
<div><font face="courier new, monospace">class Foo {};</font></div>
<div><font face="courier new, monospace">class Bar {};</font></div>
<div><font face="courier new, monospace"><br>
</font></div>
<div><font face="courier new, monospace">void swap(Foo& f,
Bar& b) noexcept {</font></div>
<div><font face="courier new, monospace"> // ...</font></div>
<div><font face="courier new, monospace">}</font></div>
<div><font face="courier new, monospace"><br>
</font></div>
<div><font face="courier new, monospace">void swap(Bar& b,
Foo& f) {</font></div>
<div><font face="courier new, monospace"> // ...</font></div>
<div><font face="courier new, monospace">}</font></div>
<div><br>
</div>
<div>So <font face="courier new, monospace">is_swappable<Foo,
Bar>::value</font> and <font face="courier new,
monospace">is_swappable<Bar, Foo>::value</font>
should clearly both be <font face="courier new, monospace">true_type</font>,
along with <font face="courier new, monospace">is_nothrow_swappable<Foo,
Bar>::value</font>, but I think <font face="courier
new, monospace">is_nothrow_swappable<Bar,
Foo>::value</font> should still be <font face="courier
new, monospace">false_type</font>.</div>
<div><br>
</div>
</div>
</div>
</blockquote>
Right, it just feels weird since the swappable itself has symmetry
constraint. Also since the symmetry constraint says the two swapping
expressions<br>
produce the same outcome it would imply so, not forcing the noexcept
though. I am not sure how to interpret the 17.6.3.2/2<br>
<br>
"An object t is swappable with an object u if and only if:<br>
— the expressions swap(t, u) and swap(u, t) are valid when
evaluated in the context described below,<br>
and<br>
— these expressions have the following effects:<br>
— the object referred to by t has the value originally held
by u and<br>
— the object referred to by u has the value originally held
by t."<br>
<br>
Now if I throw exception the last two sentences are not true any
more. So one could even read this that no exceptions can be thrown
which seems overly tight<br>
and was not meant most likely. Am I missing something here?<br>
<br>
Would having is_value_swappable make sense for convenience (per
17.6.3.2/5)?<br>
<br>
<br>
Mikael<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
<br />
<br />
--------------000104060603090708050907--
.
Author: "Andrew C. Morrow" <andrew.c.morrow@gmail.com>
Date: Mon, 11 Mar 2013 10:55:41 -0400
Raw View
--14dae9d7121eea1fe404d7a75d3b
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
On Sun, Mar 10, 2013 at 6:08 PM, Mikael Kilpel=E4inen <
mikael.kilpelainen@gmail.com> wrote:
>
> "An object t is swappable with an object u if and only if:
> =97 the expressions swap(t, u) and swap(u, t) are valid when evaluate=
d
> in the context described below,
> and
> =97 these expressions have the following effects:
> =97 the object referred to by t has the value originally held by =
u
> and
> =97 the object referred to by u has the value originally held by =
t."
>
> Now if I throw exception the last two sentences are not true any more. So
> one could even read this that no exceptions can be thrown which seems
> overly tight
> and was not meant most likely. Am I missing something here?
>
That is an interesting point: it does seem like the language here forbids
throwing swaps, but I think that must be unintentional, or that we are
misreading it, or that another section provides an escape. See 20.2.2,
which defines the noexcept status of the default std::swap template, which
would be pointless if swap were meant to be forbidden from throwing. So
perhaps the language in 17.6.3.2 needs to be clarified, but that is
independent of my proposal. I suppose if it were determined that throwing
swaps were in fact forbidden that is_nothrow_swappable would become useless=
..
>
> Would having is_value_swappable make sense for convenience (per 17.6.3.2/=
5
> )?
>
Perhaps, but I think this proposal as written is close to complete (and
thank you for your help getting it there), so I'm not sure I want to open
another front. I saw in another post that the deadline for submission to
the LWG chair for the next mailing is this week, and I'd like to make that
deadline if possible. Do you think the current draft is sufficiently
polished to submit?
--=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.
--14dae9d7121eea1fe404d7a75d3b
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Sun, Mar 10, 2013 at 6:08 PM, Mikael Kilpel=E4inen <span dir=3D"=
ltr"><<a href=3D"mailto:mikael.kilpelainen@gmail.com" target=3D"_blank">=
mikael.kilpelainen@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div><br></div>
"An object t is swappable with an object u if and only if:<br>
=A0=A0=A0 =97 the expressions swap(t, u) and swap(u, t) are valid when
evaluated in the context described below,<br>
=A0=A0=A0 and<br>
=A0=A0=A0 =97 these expressions have the following effects:<br>
=A0=A0=A0 =A0=A0=A0 =97 the object referred to by t has the value origi=
nally held
by u and<br>
=A0=A0=A0 =A0=A0=A0 =97 the object referred to by u has the value origi=
nally held
by t."<br>
<br>
Now if I throw exception the last two sentences are not true any
more. So one could even read this that no exceptions can be thrown
which seems overly tight<br>
and was not meant most likely. Am I missing something here?<br></div></=
blockquote><div><br></div><div style>That is an interesting point: it does =
seem like the language here forbids throwing swaps, but I think that must b=
e unintentional, or that we are misreading it, or that another section prov=
ides an escape. See 20.2.2, which defines the noexcept status of the defaul=
t std::swap template, which would be pointless if swap were meant to be for=
bidden from throwing. So perhaps the language in 17.6.3.2 needs to be clari=
fied, but that is independent of my proposal. I suppose if it were determin=
ed that throwing swaps were in fact forbidden that <font face=3D"courier ne=
w, monospace">is_nothrow_swappable</font> would become useless.</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div text=3D"#000000" bgcolor=
=3D"#FFFFFF">
<br>
Would having is_value_swappable make sense for convenience (per
<a href=3D"http://17.6.3.2/5" target=3D"_blank">17.6.3.2/5</a>)?</div><=
/blockquote><div><br></div><div style>Perhaps, but I think this proposal as=
written is close to complete (and thank you for your help getting it there=
), so I'm not sure I want to open another front. I saw in another post =
that the deadline for submission to the LWG chair for the next mailing is t=
his week, and I'd like to make that deadline if possible. Do you think =
the current draft is sufficiently polished to submit?</div>
<div style><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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--14dae9d7121eea1fe404d7a75d3b--
.
Author: =?windows-1252?Q?Mikael_Kilpel=E4inen?=
Date: Mon, 11 Mar 2013 23:12:07 +0100
Raw View
This is a multi-part message in MIME format.
--------------030104000600050709060505
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
11.3.2013 15:55, Andrew C. Morrow kirjoitti:
>
>
> That is an interesting point: it does seem like the language here
> forbids throwing swaps, but I think that must be unintentional, or
> that we are misreading it, or that another section provides an escape.
> See 20.2.2, which defines the noexcept status of the default std::swap
> template, which would be pointless if swap were meant to be forbidden
> from throwing. So perhaps the language in 17.6.3.2 needs to be
> clarified, but that is independent of my proposal. I suppose if it
> were determined that throwing swaps were in fact forbidden that
> is_nothrow_swappable would become useless.
Yes, it is independent, just something I noticed :)
>
> Would having is_value_swappable make sense for convenience (per
> 17.6.3.2/5 <http://17.6.3.2/5>)?
>
>
> Perhaps, but I think this proposal as written is close to complete
> (and thank you for your help getting it there), so I'm not sure I want
> to open another front. I saw in another post that the deadline for
> submission to the LWG chair for the next mailing is this week, and I'd
> like to make that deadline if possible. Do you think the current draft
> is sufficiently polished to submit?
>
I agree. I think the draft is good enough to be submitted. The deadline
is friday.
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.
--------------030104000600050709060505
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dwindows-1252"
http-equiv=3D"Content-Type">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<div class=3D"moz-cite-prefix">11.3.2013 15:55, Andrew C. Morrow
kirjoitti:<br>
</div>
<blockquote
cite=3D"mid:CA+Acj4dEPYsxiPeY6vy6GXDz3r1_Sa82cfkwRk4pRM8HqOVK3w@mail.gmail.=
com"
type=3D"cite">
<div dir=3D"ltr"><br>
<div class=3D"gmail_extra">
<div class=3D"gmail_quote"><br>
<div style=3D"">That is an interesting point: it does seem
like the language here forbids throwing swaps, but I think
that must be unintentional, or that we are misreading it,
or that another section provides an escape. See 20.2.2,
which defines the noexcept status of the default std::swap
template, which would be pointless if swap were meant to
be forbidden from throwing. So perhaps the language in
17.6.3.2 needs to be clarified, but that is independent of
my proposal. I suppose if it were determined that throwing
swaps were in fact forbidden that <font face=3D"courier
new, monospace">is_nothrow_swappable</font> would become
useless.</div>
</div>
</div>
</div>
</blockquote>
Yes, it is independent, just something I noticed :)<br>
<br>
<blockquote
cite=3D"mid:CA+Acj4dEPYsxiPeY6vy6GXDz3r1_Sa82cfkwRk4pRM8HqOVK3w@mail.gmail.=
com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<div>=A0</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text=3D"#000000" bgcolor=3D"#FFFFFF"> <br>
Would having is_value_swappable make sense for
convenience (per <a moz-do-not-send=3D"true"
href=3D"http://17.6.3.2/5" target=3D"_blank">17.6.3.2/5</=
a>)?</div>
</blockquote>
<div><br>
</div>
<div style=3D"">Perhaps, but I think this proposal as written
is close to complete (and thank you for your help getting
it there), so I'm not sure I want to open another front. I
saw in another post that the deadline for submission to
the LWG chair for the next mailing is this week, and I'd
like to make that deadline if possible. Do you think the
current draft is sufficiently polished to submit?</div>
<div style=3D""><br>
</div>
</div>
</div>
</div>
</blockquote>
I agree. I think the draft is good enough to be submitted. The
deadline is friday.<br>
<br>
<br>
Mikael<br>
</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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--------------030104000600050709060505--
.
Author: Nikolay Ivchenkov <mk.ivchenkov@gmail.com>
Date: Tue, 12 Mar 2013 14:55:58 -0700 (PDT)
Raw View
------=_Part_460_8867683.1363125358156
Content-Type: text/plain; charset=ISO-8859-1
I still don't see any useful applications of such is_swappable. It doesn't
answer whether the provided argument(s) is/are swappable, even roughly. A
call to the general unconstrained version of std::swap, where both
arguments are lvalues of the same type, will be always well-formed. If you
don't want to change the declaration of std::swap, you can introduce some
constrained surrogate for it and construct the candidate set from the
surrogate and versions found by ADL:
namespace impl
{
// constrained surrogate
template <class T>
typename enable_if
<
is_move_constructible<T>{} && is_move_assignable<T>{}
>::type
swap(T &, T &) noexcept(
is_nothrow_move_constructible<T>{} &&
is_nothrow_move_assignable<T>{});
DEF_EXPRESSION_PATTERN(
pattern_swap,
(class T, class U),
swap(declval<T>(), declval<U>()));
}
template <class T, class U = T>
struct is_swappable :
is_valid_expression<impl::pattern_swap, T, U> {};
template <class T, class U = T>
struct is_nothrow_swappable :
is_valid_nothrow_expression<impl::pattern_swap, T, U> {};
http://liveworkspace.org/code/3jUdM0$0
--
---
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_460_8867683.1363125358156
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
I still don't see any useful applications of such is_swappable. It doesn't =
answer whether the provided argument(s) is/are swappable, even roughly. A c=
all to the general unconstrained version of std::swap, where both arguments=
are lvalues of the same type, will be always well-formed. If you don't wan=
t to change the declaration of std::swap, you can introduce some constraine=
d surrogate for it and construct the candidate set from the surrogate and v=
ersions found by ADL:<br><br> namespace impl<br> &nb=
sp; {<br> // constrained su=
rrogate<br> template <class T&=
gt;<br> t=
ypename enable_if<br> =
<<br> =
&nb=
sp; is_move_constructible<T>{} && is_move_assignable<=
;T>{}<br> &nb=
sp; >::type<br> &nb=
sp; swap(T &, T &) noexcept(<br> =
; &n=
bsp; is_nothrow_move_constructible<T>{} &&<br> &nb=
sp; =
is_nothrow_move_assignable<T>{});<br><br> &nb=
sp; DEF_EXPRESSION_PATTERN(<br> &n=
bsp; pattern_swap,<br>  =
; (class T, class U),<br>&n=
bsp; swap(declv=
al<T>(), declval<U>()));<br> }<br>  =
; template <class T, class U =3D T><br> =
struct is_swappable :<br> &=
nbsp; is_valid_expression<impl::pattern_swap, T, U>=
{};<br> template <class T, class U =3D T><br> =
; struct is_nothrow_swappable :<br> &nbs=
p; is_valid_nothrow_express=
ion<impl::pattern_swap, T, U> {};<br><br>http://liveworkspace.org/cod=
e/3jUdM0$0<br>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_460_8867683.1363125358156--
.
Author: Nikolay Ivchenkov <mk.ivchenkov@gmail.com>
Date: Tue, 12 Mar 2013 15:22:37 -0700 (PDT)
Raw View
------=_Part_1463_25037184.1363126957095
Content-Type: text/plain; charset=ISO-8859-1
On Wednesday, March 13, 2013 1:55:58 AM UTC+4, Nikolay Ivchenkov wrote:
>
> I still don't see any useful applications of such is_swappable. It doesn't
> answer whether the provided argument(s) is/are swappable, even roughly. A
> call to the general unconstrained version of std::swap, where both
> arguments are lvalues of the same type, will be always well-formed. If you
> don't want to change the declaration of std::swap, you can introduce some
> constrained surrogate for it and construct the candidate set from the
> surrogate and versions found by ADL:
>
Sorry, I didn't consider this idea properly. Such implementation isn't
correct, because the general std::swap can conflict with such surrogate
(e.g. we will get value false on std::string *&). Any other surrogate, that
would be less specialized than the general std::swap, can potentially
conflict with a user-defined template. So, I see only one viable solution:
the general std::swap should be constrained.
--
---
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_1463_25037184.1363126957095
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Wednesday, March 13, 2013 1:55:58 AM UTC+4, Nikolay Ivchenkov wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;">I still don't see any useful appli=
cations of such is_swappable. It doesn't answer whether the provided argume=
nt(s) is/are swappable, even roughly. A call to the general unconstrained v=
ersion of std::swap, where both arguments are lvalues of the same type, wil=
l be always well-formed. If you don't want to change the declaration of std=
::swap, you can introduce some constrained surrogate for it and construct t=
he candidate set from the surrogate and versions found by ADL:<br></blockqu=
ote><div><br>Sorry, I didn't consider this idea properly. Such implementati=
on isn't correct, because the general std::swap can conflict with such surr=
ogate (e.g. we will get value false on std::string *&). Any other surro=
gate, that would be less specialized than the general std::swap, can potent=
ially conflict with a user-defined template. So, I see only one viable solu=
tion: the general std::swap should be constrained.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_1463_25037184.1363126957095--
.
Author: "Andrew C. Morrow" <andrew.c.morrow@gmail.com>
Date: Tue, 12 Mar 2013 20:16:46 -0400
Raw View
--e89a8f22beb951c5a904d7c352b4
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Mar 12, 2013 at 6:22 PM, Nikolay Ivchenkov
<mk.ivchenkov@gmail.com>wrote:
> On Wednesday, March 13, 2013 1:55:58 AM UTC+4, Nikolay Ivchenkov wrote:
>>
>> I still don't see any useful applications of such is_swappable. It
>> doesn't answer whether the provided argument(s) is/are swappable, even
>> roughly. A call to the general unconstrained version of std::swap, where
>> both arguments are lvalues of the same type, will be always well-formed. If
>> you don't want to change the declaration of std::swap, you can introduce
>> some constrained surrogate for it and construct the candidate set from the
>> surrogate and versions found by ADL:
>>
>
> Sorry, I didn't consider this idea properly. Such implementation isn't
> correct, because the general std::swap can conflict with such surrogate
> (e.g. we will get value false on std::string *&). Any other surrogate, that
> would be less specialized than the general std::swap, can potentially
> conflict with a user-defined template. So, I see only one viable solution:
> the general std::swap should be constrained.
>
> --
>
>
You raise a good point. I think I had not really grasped what you were
saying the first time. You are correct that is_swappable is flawed in that
it will sometimes return true_type, even though the swap expression
wouldn't actually compile, unless std::swap is constrained as well. Your
'y1' type in your linked example demonstrates that. I actually hadn't
noticed while experimenting with it because libc++ does in fact constrain
its swap.
However, I still need something that tells me "the expression 'swap(a,b)'
is legal when unevaluated", because I need to avoid building that
expression if it is illegal when I am trying to query for the noexcept
status in the implementation of is_nothrow_swappable. And I think there is
agreement that is_nothrow_swappable is useful. Also, is_swappable does
capture some useful information, such as the symmetry requirement for
heterogeneous swap.
But clearly this is bad in the case where swap is not constrained:
#include <swap_traits>
struct X {
X& operator=(X const&) = delete;
};
static if (std::is_swappable<X>::value) {
X x1, x2;
using std::swap;
// may confusingly fail to compile if swap is unconstrained
swap(x1, x2);
}
Would renaming it to something with weaker implications improve the
situation?
std::is_swap_expressible<T, U=T>?
std::has_swap_overloads<T, U=T>?
Another option would be to eliminate std::is_swappable entirely and only
retain std::is_nothrow_swappable, which is the true goal of the proposal
anyway.
Also, while working with your test code, I realized there was an issue in
my example implementation. My version of std::is_swappable<int, int> (note
the lack of '&') derived from true_type, rather than false_type as it
should, due to:
template<typename __V1, typename __V2>
static auto __test(__V1 __v1, __V2 __v2) -> decltype(swap(__v1, __v2));
I believe the correct implementation is
template<typename __V1, typename __V2>
static auto __test(__V1&& __v1, __V2&& __v2) ->
decltype(swap(std::forward<__V1>(__v1), std::forward<__V2>(__v2)));
I've pushed an update to the proposal with this change. Latest revision is
here:
http://acmorrow.github.com/cpp-proposals/swap_traits.html
Given that the submission deadline is Friday, any thoughts on how to
resolve the issues with std::is_swappable or comments on the above change
to the example implementation would be much appreciated.
--
---
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.
--e89a8f22beb951c5a904d7c352b4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Tue, Mar 12, 2013 at 6:22 PM, Nikolay Ivchenkov <span dir=3D"ltr">&l=
t;<a href=3D"mailto:mk.ivchenkov@gmail.com" target=3D"_blank">mk.ivchenkov@=
gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div class=3D"im">On Wednesday, March 13, 2013 1:55:58 AM =
UTC+4, Nikolay Ivchenkov wrote:<blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204=
,204);border-left-style:solid;padding-left:1ex">
I still don't see any useful applications of such is_swappable. It does=
n't answer whether the provided argument(s) is/are swappable, even roug=
hly. A call to the general unconstrained version of std::swap, where both a=
rguments are lvalues of the same type, will be always well-formed. If you d=
on't want to change the declaration of std::swap, you can introduce som=
e constrained surrogate for it and construct the candidate set from the sur=
rogate and versions found by ADL:<br>
</blockquote></div><div><br>Sorry, I didn't consider this idea properly=
.. Such implementation isn't correct, because the general std::swap can =
conflict with such surrogate (e.g. we will get value false on std::string *=
&). Any other surrogate, that would be less specialized than the genera=
l std::swap, can potentially conflict with a user-defined template. So, I s=
ee only one viable solution: the general std::swap should be constrained.<b=
r>
</div><div class=3D""><div class=3D"h5">
<p></p>
-- <br>
=A0<br></div></div></blockquote><div><br></div><div style>You raise a good =
point. I think I had not really grasped what you were saying the first time=
.. You are correct that <font face=3D"courier new, monospace">is_swappable</=
font> is flawed in that it will sometimes return true_type, even though the=
swap expression wouldn't actually compile, unless std::swap is constra=
ined as well. Your 'y1' type in your linked example demonstrates th=
at. I actually hadn't noticed while experimenting with it because libc+=
+ does in fact constrain its swap.</div>
<div style><br></div><div style>However, I still need something that tells =
me "the expression 'swap(a,b)' is legal when unevaluated"=
, because I need to avoid building that expression if it is illegal when I =
am trying to query for the noexcept status in the implementation of <font f=
ace=3D"courier new, monospace">is_nothrow_swappable</font>. And I think the=
re is agreement that <font face=3D"courier new, monospace">is_nothrow_swapp=
able</font> is useful. Also, <font face=3D"courier new, monospace">is_swapp=
able</font> does capture some useful information, such as the symmetry requ=
irement for heterogeneous swap.</div>
<div style><br></div><div style>But clearly this is bad in the case where s=
wap is not constrained:</div><div style><br></div><div style><font face=3D"=
courier new, monospace">#include <swap_traits></font></div><div style=
>
<font face=3D"courier new, monospace"><br></font></div><div style><font fac=
e=3D"courier new, monospace">struct X {</font></div><div style><font face=
=3D"courier new, monospace">=A0 X& operator=3D(X const&) =3D delete=
;</font></div>
<div style><font face=3D"courier new, monospace">};</font></div><div style>=
<font face=3D"courier new, monospace"><br></font></div><div style><font fac=
e=3D"courier new, monospace">static if (std::is_swappable<X>::value) =
{</font></div>
<div style><font face=3D"courier new, monospace">=A0 X x1, x2;</font></div>=
<div style><font face=3D"courier new, monospace">=A0 using std::swap;</font=
></div><div style><font face=3D"courier new, monospace">=A0 // may confusin=
gly fail to compile if swap is unconstrained</font></div>
<div style><font face=3D"courier new, monospace">=A0 swap(x1, x2);<br>}</fo=
nt></div><div style><br></div><div style>Would renaming it to something wit=
h weaker implications improve the situation?</div><div style><br></div><div=
style>
std::is_swap_expressible<T, U=3DT>?</div><div style>std::has_swap_ove=
rloads<T, U=3DT>?</div><div style><br></div><div style>Another option=
would be to eliminate std::is_swappable entirely and only retain std::is_n=
othrow_swappable, which is the true goal of the proposal anyway.</div>
<div style><br></div><div style>Also, while working with your test code, I =
realized there was an issue in my example implementation. My version of std=
::is_swappable<int, int> (note the lack of '&') derived f=
rom true_type, rather than false_type as it should, due to:</div>
<div style><br></div><div style><div><font face=3D"courier new, monospace">=
=A0 =A0 template<typename __V1, typename __V2></font></div><div><font=
face=3D"courier new, monospace">=A0 =A0 static auto __test(__V1 __v1, __V2=
__v2) -> decltype(swap(__v1,=A0</font><span style=3D"font-family:'c=
ourier new',monospace">__v2));</span></div>
</div><div style><br></div><div style>I believe the correct implementation =
is</div><div style><br></div><div style><div><font face=3D"courier new, mon=
ospace">=A0 =A0 template<typename __V1, typename __V2></font></div><d=
iv>
<font face=3D"courier new, monospace">=A0 =A0 static auto __test(__V1&&=
amp; __v1, __V2&& __v2) -> decltype(swap(std::forward<__V1>=
;(__v1),=A0</font><span style=3D"font-family:'courier new',monospac=
e">std::forward<__V2>(__v2)));</span></div>
<div><br></div><div style>I've pushed an update to the proposal with th=
is change. Latest revision is here:</div><div style><br></div><div style><a=
href=3D"http://acmorrow.github.com/cpp-proposals/swap_traits.html">http://=
acmorrow.github.com/cpp-proposals/swap_traits.html</a><br>
</div><div style><br></div><div style>Given that the submission deadline is=
Friday, any thoughts on how to resolve the issues with std::is_swappable o=
r comments on the above change to the example implementation would be much =
appreciated.=A0</div>
</div><div style><br></div><div><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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--e89a8f22beb951c5a904d7c352b4--
.
Author: "Andrew C. Morrow" <andrew.c.morrow@gmail.com>
Date: Thu, 14 Mar 2013 15:50:33 -0400
Raw View
--f46d044284f8f40a4904d7e7d5ca
Content-Type: text/plain; charset=ISO-8859-1
Mikael and Nikolay -
Any suggestions about how to repair this proposal given the problems with
is_swappable?
On Tue, Mar 12, 2013 at 8:16 PM, Andrew C. Morrow <andrew.c.morrow@gmail.com
> wrote:
>
>
> On Tue, Mar 12, 2013 at 6:22 PM, Nikolay Ivchenkov <mk.ivchenkov@gmail.com
> > wrote:
>
>> On Wednesday, March 13, 2013 1:55:58 AM UTC+4, Nikolay Ivchenkov wrote:
>>>
>>> I still don't see any useful applications of such is_swappable. It
>>> doesn't answer whether the provided argument(s) is/are swappable, even
>>> roughly. A call to the general unconstrained version of std::swap, where
>>> both arguments are lvalues of the same type, will be always well-formed. If
>>> you don't want to change the declaration of std::swap, you can introduce
>>> some constrained surrogate for it and construct the candidate set from the
>>> surrogate and versions found by ADL:
>>>
>>
>> Sorry, I didn't consider this idea properly. Such implementation isn't
>> correct, because the general std::swap can conflict with such surrogate
>> (e.g. we will get value false on std::string *&). Any other surrogate, that
>> would be less specialized than the general std::swap, can potentially
>> conflict with a user-defined template. So, I see only one viable solution:
>> the general std::swap should be constrained.
>>
>> --
>>
>>
>
> You raise a good point. I think I had not really grasped what you were
> saying the first time. You are correct that is_swappable is flawed in
> that it will sometimes return true_type, even though the swap expression
> wouldn't actually compile, unless std::swap is constrained as well. Your
> 'y1' type in your linked example demonstrates that. I actually hadn't
> noticed while experimenting with it because libc++ does in fact constrain
> its swap.
>
> However, I still need something that tells me "the expression 'swap(a,b)'
> is legal when unevaluated", because I need to avoid building that
> expression if it is illegal when I am trying to query for the noexcept
> status in the implementation of is_nothrow_swappable. And I think there
> is agreement that is_nothrow_swappable is useful. Also, is_swappable does
> capture some useful information, such as the symmetry requirement for
> heterogeneous swap.
>
> But clearly this is bad in the case where swap is not constrained:
>
> #include <swap_traits>
>
> struct X {
> X& operator=(X const&) = delete;
> };
>
> static if (std::is_swappable<X>::value) {
> X x1, x2;
> using std::swap;
> // may confusingly fail to compile if swap is unconstrained
> swap(x1, x2);
> }
>
> Would renaming it to something with weaker implications improve the
> situation?
>
> std::is_swap_expressible<T, U=T>?
> std::has_swap_overloads<T, U=T>?
>
> Another option would be to eliminate std::is_swappable entirely and only
> retain std::is_nothrow_swappable, which is the true goal of the proposal
> anyway.
>
> Also, while working with your test code, I realized there was an issue in
> my example implementation. My version of std::is_swappable<int, int> (note
> the lack of '&') derived from true_type, rather than false_type as it
> should, due to:
>
> template<typename __V1, typename __V2>
> static auto __test(__V1 __v1, __V2 __v2) -> decltype(swap(__v1,
> __v2));
>
> I believe the correct implementation is
>
> template<typename __V1, typename __V2>
> static auto __test(__V1&& __v1, __V2&& __v2) ->
> decltype(swap(std::forward<__V1>(__v1), std::forward<__V2>(__v2)));
>
> I've pushed an update to the proposal with this change. Latest revision is
> here:
>
> http://acmorrow.github.com/cpp-proposals/swap_traits.html
>
> Given that the submission deadline is Friday, any thoughts on how to
> resolve the issues with std::is_swappable or comments on the above change
> to the example implementation would be much appreciated.
>
>
>
--
---
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.
--f46d044284f8f40a4904d7e7d5ca
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div style>Mikael and Nikolay -</div><div style><br></=
div><div style>Any suggestions about how to repair this proposal given the =
problems with is_swappable?</div><div style><br></div></div><div class=3D"g=
mail_extra">
<br><br><div class=3D"gmail_quote">On Tue, Mar 12, 2013 at 8:16 PM, Andrew =
C. Morrow <span dir=3D"ltr"><<a href=3D"mailto:andrew.c.morrow@gmail.com=
" target=3D"_blank">andrew.c.morrow@gmail.com</a>></span> wrote:<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te"><div class=3D"im">On Tue, Mar 12, 2013 at 6:22 PM, Nikolay Ivchenkov <s=
pan dir=3D"ltr"><<a href=3D"mailto:mk.ivchenkov@gmail.com" target=3D"_bl=
ank">mk.ivchenkov@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div>On Wednesday, March 13, 2013 1:55:58 AM UTC+4, Nikola=
y Ivchenkov wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-=
left-style:solid;padding-left:1ex">
I still don't see any useful applications of such is_swappable. It does=
n't answer whether the provided argument(s) is/are swappable, even roug=
hly. A call to the general unconstrained version of std::swap, where both a=
rguments are lvalues of the same type, will be always well-formed. If you d=
on't want to change the declaration of std::swap, you can introduce som=
e constrained surrogate for it and construct the candidate set from the sur=
rogate and versions found by ADL:<br>
</blockquote></div><div><br>Sorry, I didn't consider this idea properly=
.. Such implementation isn't correct, because the general std::swap can =
conflict with such surrogate (e.g. we will get value false on std::string *=
&). Any other surrogate, that would be less specialized than the genera=
l std::swap, can potentially conflict with a user-defined template. So, I s=
ee only one viable solution: the general std::swap should be constrained.<b=
r>
</div><div><div>
<p></p>
-- <br>
=A0<br></div></div></blockquote><div><br></div></div><div>You raise a good =
point. I think I had not really grasped what you were saying the first time=
.. You are correct that <font face=3D"courier new, monospace">is_swappable</=
font> is flawed in that it will sometimes return true_type, even though the=
swap expression wouldn't actually compile, unless std::swap is constra=
ined as well. Your 'y1' type in your linked example demonstrates th=
at. I actually hadn't noticed while experimenting with it because libc+=
+ does in fact constrain its swap.</div>
<div><br></div><div>However, I still need something that tells me "the=
expression 'swap(a,b)' is legal when unevaluated", because I =
need to avoid building that expression if it is illegal when I am trying to=
query for the noexcept status in the implementation of <font face=3D"couri=
er new, monospace">is_nothrow_swappable</font>. And I think there is agreem=
ent that <font face=3D"courier new, monospace">is_nothrow_swappable</font> =
is useful. Also, <font face=3D"courier new, monospace">is_swappable</font> =
does capture some useful information, such as the symmetry requirement for =
heterogeneous swap.</div>
<div><br></div><div>But clearly this is bad in the case where swap is not c=
onstrained:</div><div><br></div><div><font face=3D"courier new, monospace">=
#include <swap_traits></font></div><div>
<font face=3D"courier new, monospace"><br></font></div><div><font face=3D"c=
ourier new, monospace">struct X {</font></div><div><font face=3D"courier ne=
w, monospace">=A0 X& operator=3D(X const&) =3D delete;</font></div>
<div><font face=3D"courier new, monospace">};</font></div><div><font face=
=3D"courier new, monospace"><br></font></div><div><font face=3D"courier new=
, monospace">static if (std::is_swappable<X>::value) {</font></div>
<div><font face=3D"courier new, monospace">=A0 X x1, x2;</font></div><div><=
font face=3D"courier new, monospace">=A0 using std::swap;</font></div><div>=
<font face=3D"courier new, monospace">=A0 // may confusingly fail to compil=
e if swap is unconstrained</font></div>
<div><font face=3D"courier new, monospace">=A0 swap(x1, x2);<br>}</font></d=
iv><div><br></div><div>Would renaming it to something with weaker implicati=
ons improve the situation?</div><div><br></div><div>
std::is_swap_expressible<T, U=3DT>?</div><div>std::has_swap_overloads=
<T, U=3DT>?</div><div><br></div><div>Another option would be to elimi=
nate std::is_swappable entirely and only retain std::is_nothrow_swappable, =
which is the true goal of the proposal anyway.</div>
<div><br></div><div>Also, while working with your test code, I realized the=
re was an issue in my example implementation. My version of std::is_swappab=
le<int, int> (note the lack of '&') derived from true_typ=
e, rather than false_type as it should, due to:</div>
<div><br></div><div><div><font face=3D"courier new, monospace">=A0 =A0 temp=
late<typename __V1, typename __V2></font></div><div><font face=3D"cou=
rier new, monospace">=A0 =A0 static auto __test(__V1 __v1, __V2 __v2) ->=
decltype(swap(__v1,=A0</font><span style=3D"font-family:'courier new&#=
39;,monospace">__v2));</span></div>
</div><div><br></div><div>I believe the correct implementation is</div><div=
><br></div><div><div><font face=3D"courier new, monospace">=A0 =A0 template=
<typename __V1, typename __V2></font></div><div>
<font face=3D"courier new, monospace">=A0 =A0 static auto __test(__V1&&=
amp; __v1, __V2&& __v2) -> decltype(swap(std::forward<__V1>=
;(__v1),=A0</font><span style=3D"font-family:'courier new',monospac=
e">std::forward<__V2>(__v2)));</span></div>
<div><br></div><div>I've pushed an update to the proposal with this cha=
nge. Latest revision is here:</div><div><br></div><div><a href=3D"http://ac=
morrow.github.com/cpp-proposals/swap_traits.html" target=3D"_blank">http://=
acmorrow.github.com/cpp-proposals/swap_traits.html</a><br>
</div><div><br></div><div>Given that the submission deadline is Friday, any=
thoughts on how to resolve the issues with std::is_swappable or comments o=
n the above change to the example implementation would be much appreciated.=
=A0</div>
</div><div><br></div><div><br></div></div></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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--f46d044284f8f40a4904d7e7d5ca--
.
Author: =?ISO-8859-1?Q?Mikael_Kilpel=E4inen?=
Date: Thu, 14 Mar 2013 21:54:34 +0100
Raw View
14.3.2013 20:50, Andrew C. Morrow kirjoitti:
>
> Any suggestions about how to repair this proposal given the problems
> with is_swappable?
>
Not really. Sorry.
I was experimenting with a version that has swap(...) that hides the
std::swap to see if there is anything that matches via
ADL and if not, use qualified std::swap and some more constraints. This
works in normal cases fine, but
of course there is this small gap between the template std::swap and the
swap(...) where the adl version might match
and hence you get wrong results again (you cannot hide the std::swap
with same signature as it is as it gets pulled in by adl anyhow
and it is ambigious, like Nikolay already noted).
So I can only conclude, since you need the is_swappable for the main
purpose, namely is_swappale_nothrow. Keep it there, explain
the current problems with it and mention that something should probably
be done about it (ie. constrain swap or ..) and let committee give feedback.
And make sure that the nothrow version is the main purpose of this proposal.
Of course we should continue thinking how to solve this but...
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.
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Fri, 15 Mar 2013 00:59:24 -0700 (PDT)
Raw View
------=_Part_974_10406188.1363334364028
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu czwartek, 14 marca 2013 21:54:34 UTC+1 u=BFytkownik Mikael Kilpel=E4=
inen=20
napisa=B3:
>
> 14.3.2013 20:50, Andrew C. Morrow kirjoitti:=20
> >=20
> > Any suggestions about how to repair this proposal given the problems=20
> > with is_swappable?=20
> >=20
>
> Not really. Sorry.=20
>
> I was experimenting with a version that has swap(...) that hides the=20
> std::swap to see if there is anything that matches via=20
> ADL and if not, use qualified std::swap and some more constraints. This=
=20
> works in normal cases fine, but=20
> of course there is this small gap between the template std::swap and the=
=20
> swap(...) where the adl version might match=20
> and hence you get wrong results again (you cannot hide the std::swap=20
> with same signature as it is as it gets pulled in by adl anyhow=20
> and it is ambigious, like Nikolay already noted).=20
>
> So I can only conclude, since you need the is_swappable for the main=20
> purpose, namely is_swappale_nothrow. Keep it there, explain=20
> the current problems with it and mention that something should probably=
=20
> be done about it (ie. constrain swap or ..) and let committee give=20
> feedback.=20
> And make sure that the nothrow version is the main purpose of this=20
> proposal.=20
>
> Of course we should continue thinking how to solve this but...=20
> Mikael=20
>
Sorry, if my suggestion is dumb (I am not entirely following the details),=
=20
but it looked like you have a problem with implementing the proposed traits=
=20
within the C++ language, rather than with the proposal itself. Did you=20
consider proposing a requirement that is not implementable within C++ but=
=20
could be provided by the vendors by some intrinsics or compiler magic (much=
=20
like other traits)?
Regards,
&rzej =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_974_10406188.1363334364028
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu czwartek, 14 marca 2013 21:54:34 UTC+1 u=BFytkownik Mikael K=
ilpel=E4inen napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">14.3.20=
13 20:50, Andrew C. Morrow kirjoitti:
<br>>
<br>> Any suggestions about how to repair this proposal given the proble=
ms=20
<br>> with is_swappable?
<br>>
<br>
<br>Not really. Sorry.
<br>
<br>I was experimenting with a version that has swap(...) that hides the=20
<br>std::swap to see if there is anything that matches via
<br>ADL and if not, use qualified std::swap and some more constraints. This=
=20
<br>works in normal cases fine, but
<br>of course there is this small gap between the template std::swap and th=
e=20
<br>swap(...) where the adl version might match
<br>and hence you get wrong results again (you cannot hide the std::swap=20
<br>with same signature as it is as it gets pulled in by adl anyhow
<br>and it is ambigious, like Nikolay already noted).
<br>
<br>So I can only conclude, since you need the is_swappable for the main=20
<br>purpose, namely is_swappale_nothrow. Keep it there, explain
<br>the current problems with it and mention that something should probably=
=20
<br>be done about it (ie. constrain swap or ..) and let committee give feed=
back.
<br>And make sure that the nothrow version is the main purpose of this prop=
osal.
<br>
<br>Of course we should continue thinking how to solve this but...
<br>Mikael
<br></blockquote><div><br>Sorry, if my suggestion is dumb (I am not entirel=
y following the details), but it looked like you have a problem with implem=
enting the proposed traits within the C++ language, rather than with the pr=
oposal itself. Did you consider proposing a requirement that is not impleme=
ntable within C++ but could be provided by the vendors by some intrinsics o=
r compiler magic (much like other traits)?<br><br>Regards,<br>&rzej &nb=
sp; <br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_974_10406188.1363334364028--
.
Author: "Andrew C. Morrow" <andrew.c.morrow@gmail.com>
Date: Fri, 15 Mar 2013 11:26:15 -0400
Raw View
--e89a8f22beb9969c5c04d7f8428c
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
On Fri, Mar 15, 2013 at 3:59 AM, Andrzej Krzemie=F1ski <akrzemi1@gmail.com>=
wrote:
>
>
> W dniu czwartek, 14 marca 2013 21:54:34 UTC+1 u=BFytkownik Mikael
> Kilpel=E4inen napisa=B3:
>
>> 14.3.2013 20:50, Andrew C. Morrow kirjoitti:
>> >
>> > Any suggestions about how to repair this proposal given the problems
>> > with is_swappable?
>> >
>>
>> Not really. Sorry.
>>
>> I was experimenting with a version that has swap(...) that hides the
>> std::swap to see if there is anything that matches via
>> ADL and if not, use qualified std::swap and some more constraints. This
>> works in normal cases fine, but
>> of course there is this small gap between the template std::swap and the
>> swap(...) where the adl version might match
>> and hence you get wrong results again (you cannot hide the std::swap
>> with same signature as it is as it gets pulled in by adl anyhow
>> and it is ambigious, like Nikolay already noted).
>>
>> So I can only conclude, since you need the is_swappable for the main
>> purpose, namely is_swappale_nothrow. Keep it there, explain
>> the current problems with it and mention that something should probably
>> be done about it (ie. constrain swap or ..) and let committee give
>> feedback.
>> And make sure that the nothrow version is the main purpose of this
>> proposal.
>>
>> Of course we should continue thinking how to solve this but...
>> Mikael
>>
>
> Sorry, if my suggestion is dumb (I am not entirely following the details)=
,
> but it looked like you have a problem with implementing the proposed trai=
ts
> within the C++ language, rather than with the proposal itself. Did you
> consider proposing a requirement that is not implementable within C++ but
> could be provided by the vendors by some intrinsics or compiler magic (mu=
ch
> like other traits)?
>
>
No, I don't think it is dumb at all. I've adopted your suggestion, included
in a section following Mikael's advice to document the issues with the
proposal hoping for feedback.
Given that the deadline is today, I've submitted this proposal.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
--e89a8f22beb9969c5c04d7f8428c
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Fri, Mar 15, 2013 at 3:59 AM, Andrzej Krzemie=F1ski <span dir=3D=
"ltr"><<a href=3D"mailto:akrzemi1@gmail.com" target=3D"_blank">akrzemi1@=
gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br><br>W dniu czwartek, 14 marca 2013 21:54=
:34 UTC+1 u=BFytkownik Mikael Kilpel=E4inen napisa=B3:<div><div class=3D"h5=
"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">
14.3.2013 20:50, Andrew C. Morrow kirjoitti:
<br>>
<br>> Any suggestions about how to repair this proposal given the proble=
ms=20
<br>> with is_swappable?
<br>>
<br>
<br>Not really. Sorry.
<br>
<br>I was experimenting with a version that has swap(...) that hides the=20
<br>std::swap to see if there is anything that matches via
<br>ADL and if not, use qualified std::swap and some more constraints. This=
=20
<br>works in normal cases fine, but
<br>of course there is this small gap between the template std::swap and th=
e=20
<br>swap(...) where the adl version might match
<br>and hence you get wrong results again (you cannot hide the std::swap=20
<br>with same signature as it is as it gets pulled in by adl anyhow
<br>and it is ambigious, like Nikolay already noted).
<br>
<br>So I can only conclude, since you need the is_swappable for the main=20
<br>purpose, namely is_swappale_nothrow. Keep it there, explain
<br>the current problems with it and mention that something should probably=
=20
<br>be done about it (ie. constrain swap or ..) and let committee give feed=
back.
<br>And make sure that the nothrow version is the main purpose of this prop=
osal.
<br>
<br>Of course we should continue thinking how to solve this but...
<br>Mikael
<br></blockquote></div></div><div><br>Sorry, if my suggestion is dumb (I am=
not entirely following the details), but it looked like you have a problem=
with implementing the proposed traits within the C++ language, rather than=
with the proposal itself. Did you consider proposing a requirement that is=
not implementable within C++ but could be provided by the vendors by some =
intrinsics or compiler magic (much like other traits)?<br>
<br></div></blockquote><div><br></div><div style>No, I don't think it i=
s dumb at all. I've adopted your suggestion, included in a section foll=
owing Mikael's advice to document the issues with the proposal hoping f=
or feedback.</div>
<div style><br></div><div style>Given that the deadline is today, I've =
submitted this proposal.</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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--e89a8f22beb9969c5c04d7f8428c--
.
Author: "Andrew C. Morrow" <andrew.c.morrow@gmail.com>
Date: Thu, 11 Apr 2013 12:02:08 -0400
Raw View
--089e01183294a8c27104da17e828
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
Hi all -
I will not be attending the Bristol meeting to advocate for this proposal,
which was accepted as N3619 (
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3619.html).
If anyone who is interested in the material and plans to attend would be
willing to advocate for it, I would appreciate it. My understanding is that
papers without advocates usually go unconsidered.
If you are interested, please email me directly.
Thank you,
Andrew
On Fri, Mar 15, 2013 at 11:26 AM, Andrew C. Morrow <
andrew.c.morrow@gmail.com> wrote:
>
>
>
> On Fri, Mar 15, 2013 at 3:59 AM, Andrzej Krzemie=F1ski <akrzemi1@gmail.co=
m>wrote:
>
>>
>>
>> W dniu czwartek, 14 marca 2013 21:54:34 UTC+1 u=BFytkownik Mikael
>> Kilpel=E4inen napisa=B3:
>>
>>> 14.3.2013 20:50, Andrew C. Morrow kirjoitti:
>>> >
>>> > Any suggestions about how to repair this proposal given the problems
>>> > with is_swappable?
>>> >
>>>
>>> Not really. Sorry.
>>>
>>> I was experimenting with a version that has swap(...) that hides the
>>> std::swap to see if there is anything that matches via
>>> ADL and if not, use qualified std::swap and some more constraints. This
>>> works in normal cases fine, but
>>> of course there is this small gap between the template std::swap and th=
e
>>> swap(...) where the adl version might match
>>> and hence you get wrong results again (you cannot hide the std::swap
>>> with same signature as it is as it gets pulled in by adl anyhow
>>> and it is ambigious, like Nikolay already noted).
>>>
>>> So I can only conclude, since you need the is_swappable for the main
>>> purpose, namely is_swappale_nothrow. Keep it there, explain
>>> the current problems with it and mention that something should probably
>>> be done about it (ie. constrain swap or ..) and let committee give
>>> feedback.
>>> And make sure that the nothrow version is the main purpose of this
>>> proposal.
>>>
>>> Of course we should continue thinking how to solve this but...
>>> Mikael
>>>
>>
>> Sorry, if my suggestion is dumb (I am not entirely following the
>> details), but it looked like you have a problem with implementing the
>> proposed traits within the C++ language, rather than with the proposal
>> itself. Did you consider proposing a requirement that is not implementab=
le
>> within C++ but could be provided by the vendors by some intrinsics or
>> compiler magic (much like other traits)?
>>
>>
> No, I don't think it is dumb at all. I've adopted your suggestion,
> included in a section following Mikael's advice to document the issues wi=
th
> the proposal hoping for feedback.
>
> Given that the deadline is today, I've submitted this proposal.
>
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
--089e01183294a8c27104da17e828
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div style>Hi all -</div><div style><br></div><div sty=
le>I will not be attending the Bristol meeting to advocate for this proposa=
l, which was accepted as N3619 (<a href=3D"http://www.open-std.org/JTC1/SC2=
2/WG21/docs/papers/2013/n3619.html">http://www.open-std.org/JTC1/SC22/WG21/=
docs/papers/2013/n3619.html</a>).</div>
<div style><br></div><div style>If anyone who is interested in the material=
and plans to attend would be willing to advocate for it, I would appreciat=
e it. My understanding is that papers without advocates usually go unconsid=
ered.</div>
<div style><br></div><div style>If you are interested, please email me dire=
ctly.</div><div style><br></div><div style>Thank you,</div><div style>Andre=
w</div><div style><br></div></div><div class=3D"gmail_extra"><br><br><div c=
lass=3D"gmail_quote">
On Fri, Mar 15, 2013 at 11:26 AM, Andrew C. Morrow <span dir=3D"ltr"><<a=
href=3D"mailto:andrew.c.morrow@gmail.com" target=3D"_blank">andrew.c.morro=
w@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote"><div><div class=3D"h5">On Fri, Mar 15, 2013 at 3:59 AM, Andrzej Krz=
emie=F1ski <span dir=3D"ltr"><<a href=3D"mailto:akrzemi1@gmail.com" targ=
et=3D"_blank">akrzemi1@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br><br>W dniu czwartek, 14 marca 2013 21:54=
:34 UTC+1 u=BFytkownik Mikael Kilpel=E4inen napisa=B3:<div><div><blockquote=
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px =
#ccc solid;padding-left:1ex">
14.3.2013 20:50, Andrew C. Morrow kirjoitti:
<br>>
<br>> Any suggestions about how to repair this proposal given the proble=
ms=20
<br>> with is_swappable?
<br>>
<br>
<br>Not really. Sorry.
<br>
<br>I was experimenting with a version that has swap(...) that hides the=20
<br>std::swap to see if there is anything that matches via
<br>ADL and if not, use qualified std::swap and some more constraints. This=
=20
<br>works in normal cases fine, but
<br>of course there is this small gap between the template std::swap and th=
e=20
<br>swap(...) where the adl version might match
<br>and hence you get wrong results again (you cannot hide the std::swap=20
<br>with same signature as it is as it gets pulled in by adl anyhow
<br>and it is ambigious, like Nikolay already noted).
<br>
<br>So I can only conclude, since you need the is_swappable for the main=20
<br>purpose, namely is_swappale_nothrow. Keep it there, explain
<br>the current problems with it and mention that something should probably=
=20
<br>be done about it (ie. constrain swap or ..) and let committee give feed=
back.
<br>And make sure that the nothrow version is the main purpose of this prop=
osal.
<br>
<br>Of course we should continue thinking how to solve this but...
<br>Mikael
<br></blockquote></div></div><div><br>Sorry, if my suggestion is dumb (I am=
not entirely following the details), but it looked like you have a problem=
with implementing the proposed traits within the C++ language, rather than=
with the proposal itself. Did you consider proposing a requirement that is=
not implementable within C++ but could be provided by the vendors by some =
intrinsics or compiler magic (much like other traits)?<br>
<br></div></blockquote><div><br></div></div></div><div>No, I don't thin=
k it is dumb at all. I've adopted your suggestion, included in a sectio=
n following Mikael's advice to document the issues with the proposal ho=
ping for feedback.</div>
<div><br></div><div>Given that the deadline is today, I've submitted th=
is proposal.</div></div><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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--089e01183294a8c27104da17e828--
.