Hi,

Are you sure you want to do a copy-assignment of your T? Your example would typically be more efficient when doing a move-assignment or a swap instead. What would you think of an optional<T>::swap_if_initialized member function, so that you can do:

if( ! TryToGetT().swap_if_initialized(t) { ... other way to get t ... }

I like a swap much better, thanks Neil! I'm normally against obscure functions that are meant to save a few keystrokes. OTOH, while the verbose alternative is perfectly clear and I wouldn't even consider searching for a shortcut, this particular shortcut looks clear enough to justify it. So, Arno: don't you agree swap is better? If so, does the swap() method really need the "_if_initialized"? I would just add overloads to the existing swap: bool optional<T>::swap(T& a) bool swap( optional<T> const&x, T& y ) ; bool swap( T const&x, optional<T> const& y ) ; I know 'swap' is a big name, but distorting it with a return value doesn't seem disruptive enough to justify choosing a different name. What do people think? -- Fernando Cacciola SciSoft Consulting http://www.scisoft-consulting.com

...

I'm normally against obscure functions that are meant to save a few keystrokes. OTOH, while the verbose alternative is perfectly clear and I wouldn't even consider searching for a shortcut, this particular shortcut looks clear enough to justify it.

So, Arno: don't you agree swap is better?

Would a function like optional<T>::swap_if_initialized(T&) indeed be the preferable one for Arno's use case? It isn't yet entirely clear to me, as it seems that Arno would like to have an implicit conversion, while passing the value from optional<T> to its target.

Sorry for not responding earlier. I don't see how my use case is special over regular assignment, apart from the fact that the assignment is conditional. Like for any assignment, move optimization is certainly appreciated, and my use cases are indeed r-value assignments. Arno -- Dr. Arno Schoedl · aschoedl@think-cell.com Technical Director think-cell Software GmbH · Invalidenstr. 34 · 10115 Berlin, Germany http://www.think-cell.com · phone +49-30-666473-10 · toll-free (US) +1-800-891-8091 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl · Amtsgericht Charlottenburg, HRB 85229

Fernando Cacciola wrote:

That is, we can't just yet write that as: template<class T, class U> bool optional_assign( T&, optional<U>&& ) ; as we would a few years from now.

Well, we can achieve almost the same in old C++03, by declaring the function as a /member/ of optional<T>. I'd suggest naming it "optional_move_to", as follows: template <class U> bool optional_move_to(U& arg) { if (*this) { // Moves from **this to arg. optional_detail::move_assign(arg, **this); return true; } else { return false; } } optional_detail::move_assign could be implemented by doing either boost::swap (when T == U) or copy-assignment (when T != U), e.g., by overloading: template <class T> void move_assign(T& lhs, T& rhs) { boost::swap(lhs, rhs); } template <class T, class U> void move_assign(T& lhs, U& rhs) { lhs = rhs; } What do you think? Arno, given such a optional<T>::optional_move_to member function, would you still prefer to use your own optional_assign function? Otherwise your use case could be written as follows: boost::optional< TMyValue > TryToGetT(); T t; if( ! TryToGetT().optional_move_to(t) ) { ... other way to get t ... } Kind regards, Niels

Hi again,

Fernando Cacciola wrote:

...

That is, we can't just yet write that as: template<class T, class U> bool optional_assign( T&, optional<U>&& ) ; as we would a few years from now.

Well, we can achieve almost the same in old C++03, by declaring the function as a /member/ of optional<T>. I'd suggest naming it "optional_move_to", as follows:

On further thinking, if the optional is an lvalue this would do the right thing but will have the wrong name o) So, we need "optional_copy_to()" if we want users to explicitely choose between move vs copy. Or, probably better, a single [optional_]assign_to() that magically does one or the other depending on "this" being and lvalue or rvalue reference Something which, btw, in C++0x can actually be properly overloaded: template<class U> bool optional<T>::assign_to( U& ) & ; template<class U> bool optional<T>::assign_to( U& ) && ; This is getting unsurprisingly closer to the initial proposal from Arno :) The main difference being the usage of a member function instead in order to leverage move optimizations in current C++. Cheers -- Fernando Cacciola SciSoft Consulting http://www.scisoft-consulting.com

Hi Niels,

...

...

Well, we can achieve almost the same in old C++03, by declaring the function as a /member/ of optional<T>. I'd suggest naming it "optional_move_to", as follows:

Fernando Cacciola wrote:

...

Nice one! :)

Thanks :-)

...

I keep wondering whether being member functions, these move_to() and swap() need the "optional_" name prefix?

In the case of "optional_move_to", "move_to" is okay to me as well, as "move_to" isn't so much "overloaded". (Although I still think that "optional_move_to", or even "conditional_move_to", is more clear.)

...

On further thinking, if the optional is an lvalue this would do the right thing but will have the wrong name o)

If "move_to" does either swap or assign-to, IMO the name is right, even if it moves from an lvalue.

What I really meant is that, with an lvalue, most likely you don't *want* move but copy.

...

Or, probably better, a single [optional_]assign_to() that magically does one or the other depending on "this" being and lvalue or rvalue reference

Something which, btw, in C++0x can actually be properly overloaded:

template<class U> bool optional<T>::assign_to( U& ) & ; template<class U> bool optional<T>::assign_to( U& ) && ;

This is getting unsurprisingly closer to the initial proposal from Arno :)

What about adding a "const" overload as well? ;-)

template<class U> bool optional<T>::assign_to( U& ) const & ;

;) indeed

Maybe Ion Gaztañaga's Boost.Move can be of help to emulate move semantics in C++03? http://svn.boost.org/svn/boost/sandbox/libs/move_semantics/doc/html/index.ht...

I'm sure it could help, but I wouldn't like adding such a depedency into Boost.Optional... but maybe I'm over reacting o)

Anyway, for the time being I think that adding optional_move_to(T&) and optional_swap(T&) members (as I presented), and optional_assign (by Arno) should be sufficient.

Let's see: With swap(), move sermantics are aways welcome for both l-and-rvalues, so an optional_swap(T&) member makes sense. When assigning from an rvalue, move-assign is aways welcome, while when assigning from an lvalue you want move only by explicit request. So, an assign_to() API that won't ever move from an lvalue but will always try to with an rvalue also makes sense.. and it must be a member function nowadays to potentially move from rvalues. A member move_to() also makes sense when you explicitely want to move even from an rvalue. So.. I have the same list as you except for optional_assign(), which should be a member to make moving from rvalues possible. That is: 1) o.assign_to(v) is the counterpart of: v = o ; which would move IFF 'o' is an rvalue. 2) o.move_to(v) is the counterpart of: v = std::move(o) which always moves. Best -- Fernando Cacciola SciSoft Consulting, Founder http://www.scisoft-consulting.com

Arno, given such a optional<T>::optional_move_to member function, would you still prefer to use your own optional_assign function? Otherwise your use case could be written as follows:

We don't use any special move library in our code because I am waiting for C++0x. But if the library, in this case boost::optional, supports it, I'd use it where applicable. Regular assignment, without killing the source, should work as well, though. Arno -- Dr. Arno Schoedl · aschoedl@think-cell.com Technical Director think-cell Software GmbH · Invalidenstr. 34 · 10115 Berlin, Germany http://www.think-cell.com · phone +49-30-666473-10 · toll-free (US) +1-800-891-8091 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl · Amtsgericht Charlottenburg, HRB 85229

Fernando Cacciola wrote:

Hi Arno, ... Thus, until move semantics are practically usable (whether via Boost.Move or C++0x) I would either add the three functions as member functions, or just your optional_assign() as a free function, but not two members and one free standing.

What do you think?

FWIW, my vote would go to your first option, adding optional_assign_to(T&), optional_move_to(T&), and optional_swap(T&) as member functions to optional<T>. But of course, my name isn't Arno! Kind regards, Niels

Hi Arno,

Just for my understanding, why are optional_swap and optional_move_to not expessible as free functions?

template< class T, class U > bool optional_move( T& t, boost::optional<U>& u ) {

template< class T > bool optional_move( T& t, boost::optional<T>& u ) {

Just that 'u' there can't be an rvalue, which was one of the motivating requirements. And of course, if you overload for "const&", then you can't swap. This is incidentally one of the reasons 'const' and 'rvalue-ness' isn't exactly the same: you can call a mutating (non-const) method on rvalues. Best -- Fernando Cacciola SciSoft Consulting, Founder http://www.scisoft-consulting.com

Would you like to officially create a request ticket for those three member functions, at https://svn.boost.org/trac/boost/newticket ?

Done.

// Would not compile, trying to pass an optional<T> rvalue! if( !optional_move( t, TryToGetT () ) { // ... other way to get t ... }

The following would compile though, even if optional<T>::optional_move_to(T&) is non-const:

if( ! TryToGetT().optional_move_to(t) { // ... other way to get t ... }

Thank you for educating me! Just for overview: struct S; void change( S& s ) {} struct S { bool m_b; void func() { change( *this ); } }; change( S() ); // does not compile S().func(); // compiles S().m_b=true; // does not compile (!) I found this interesting: struct T; void change( T& s ) {} struct T { // makes R-values non-const operator S&() { return *this; } }; change( S() ); // compiles S const s; change( s ); // does not compile Do you know if any of this will change with C++0x? I know about rvalue references, but will any of the above change as well? Arno -- Dr. Arno Schoedl · aschoedl@think-cell.com Technical Director think-cell Software GmbH · Invalidenstr. 34 · 10115 Berlin, Germany http://www.think-cell.com · phone +49-30-666473-10 · toll-free (US) +1-800-891-8091 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl · Amtsgericht Charlottenburg, HRB 85229

Hi Niels,

...

I'm normally against obscure functions that are meant to save a few keystrokes. OTOH, while the verbose alternative is perfectly clear and I wouldn't even consider searching for a shortcut, this particular shortcut looks clear enough to justify it.

So, Arno: don't you agree swap is better?

Would a function like optional<T>::swap_if_initialized(T&) indeed be the preferable one for Arno's use case? It isn't yet entirely clear to me, as it seems that Arno would like to have an implicit conversion, while passing the value from optional<T> to its target.

I actually didn't notice that the first time. Of course swap() can do the same via "optional<T>::swap_if_initialized(U&)" for that matter.

...

If so, does the swap() method really need the "_if_initialized"? I would just add overloads to the existing swap:

bool optional<T>::swap(T& a) bool swap( optional<T> const&x, T& y ) ; bool swap( T const&x, optional<T> const& y ) ;

I know 'swap' is a big name, but distorting it with a return value doesn't seem disruptive enough to justify choosing a different name.

Personally, I would prefer to have such functions named slightly different from "swap", to make clear that they're not regular swap function. You know, people expect a swap member function to /always/ successfully exchange the values, while swap_if_initialized would /only/ exchanges the values when optional<T> is "initialized" (non-empty).

OK, that's a very good argument.

But I wouldn't mind if it would be named differently, e.g., optional<T>::optional_swap(T&) :-)

I think I like this one better.

IMO a "swap-if-initialized" /member/ function might be especially useful because it allows swapping an rvalue (optionally).

Indeed.

I'm not sure if free "swap-if-initialized" function overloads would also be needed. What do you think?

As it won't be just swap(), it doesn't need to be a free function, and right now at least I can't see any reason for having it.

Anyway, the main question remains: will any of those "swap-if-initialized" functions be appreciated, or not...?

I do, so if no one points out a good reason for adding it, I will. As I said before I really hate bloated interfaces with this seems sufficiently useful and syntactically clear. Best -- Fernando Cacciola SciSoft Consulting http://www.scisoft-consulting.com