[boost] Re: Swapability of named objects?

From: David Abrahams (dave_at_[hidden])
Date: 2003-11-06 04:17:59

Daniel Spangenberg <dsp_at_[hidden]> writes:

> David Abrahams schrieb:
> [snip]
>
>> The paper I'm referring to is actually:
>> http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1523.htm
>
> Thanks, Dave.  But honestly, after reading it, I don't see any
> fundamental contradiction to my loose definition of swappable,
> especially, if you consider my previous posting's paragraph
> concerning overloadability of swap.

When I posted, before you gave a loose definition of swappability, I
thought that swappable probably meant "swappable with std::swap".
That does for all intents and purposes imply copyability **today**,
though that would change after Howard's proposal is accepted.

> Howard proposes that **one or more** of the following conditions apply:
>
> a. T is swappable if T is copyconstructible and assignable.
> -> This requires copyability and this is not what I am discussing about.
> I spoke about "non-copy-swappability"
>
> b. T is swappable if a namespace scope function named swap exists in
> the same namespace as the definition of T, such that the expression swap(t, u)
> is valid and has the semantics described in Table??.
> -> This is the point I am discussing about! My first definition left the namespace
>
> scope function swap out, because I was think of overloading std::swap. But if
> you honestly read my last posting, you have to accept, that I effectively meant
> the same thing, don't you?

I'll be happy to accept now anything you tell me you meant.  As for
earlier, I had no idea what you meant, and after reading your last
posting I was left with an entirely different impression: that your
"swappable" depended on the presence of a member function.

>> >> Oh!  That's the last thing I expected!  So ints are not Swappable.
>> >> Now, are there any restrictions on the signature of that function or
>> >> its semantics?
>>
>> No reply?
>
> I didn't answer at this place, because the following stuff of my
> previous posting extended my original definition, which was coloured
> by the non-overloading-issue of std::swap.
>
>> >> > I do not see any connection between swapable and copyable.
>> >>
>> >> Given *your* (partial) definition of Swappable there is no connection.
>> >> I don't happen to think it's a very useful definition, though.
>> >
>> > You are right, but the main reason for my previously given very
>> > specialized
>>
>> ...and incomplete...
>
> OK, maybe incomplete, but this was not the place, to **completely**
> define swappability. 

It's awfully simple to define as Howard's paper shows, so I don't see
why not.  I think it's reasonable to have a complete definition of a
simple concept before we start discussing its implications.

> As I showed you above, Howard's proposal essentially contains my
> swappability definition.

It didn't seem that way to me.

> At this place, the need for copyability and assignability was not
> under discussion (which we would need for fundamental types, of
> course).
>
> The point under discussion was property b of his proposal.
>
>> IMO that's overconstrained.  Even if you consider swapping two B's
>> what difference does it make that b1.cc_ is exchanged with b2.cc_?
>>
>> You're still missing a function signature or at least a list of valid
>> expressions.
>
> You know very well, **why** I left out the valid expression. 

What makes you so sure I understood why you left out the valid
expressions?  I really didn't.  Maybe I missed an important part of
the thread.

> I explained it as an deficiency in overloading std::swap, Howard
> solves it elegantly by requiring a namespace scope swap and adding
> further requirements on several algorithms of the standard
> library. So what problems are left now?

I don't know; I have no idea how any of this relates to the bigger
picture.

> Now, finally: What about the swappability of named_object?

I really have no idea or opinion about that issue.

>> > The disadvantage of this very general definition is, that we see
>> > no direct connection to member functions, like swap.
>> >
>> > You say, that you think that my originally proposed specialized
>> > definition of swappability is not very useful, but I ask you:
>> > why?
>>
>> Because you can't use it on lots of objects (like ints) which can
>> certainly be swapped.
>
> I think we have answered this question already, don't we?

I don't think I was asking a question.  

For the record, I don't think I'd like to accept any definition of
Swappable in Boost that differs from Howard's (which does work for
ints).  You now seem to be saying that your definition is the same as
Howard's, but it seemed markedly different just a few messages ago.

>> > If this finally does not satisfy you: What is *your* definition of
>> > swappability
>>
>> I don't have one; *you're* the one using the term.
>
> So you don't think, that Howards proposal is fair enough?

Yes.

>> > and how does it's definition relate to boost::scoped_ptr, which I
>> > would in fact describe as "swappable but not copyable"?
>
> Reply?

I don't understand the question.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com