-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Eelis van der Weegen Sent: Sunday, July 10, 2005 9:47 PM To: boost@lists.boost.org Subject: Re: [boost] New Library Proposal: dual_state
Jost, Andrew wrote:
*THE UNDEFINED_OBJECT* A third difference between Boost.optional and dual_state involves the very personal issue of syntax. It is nonsense to tell people to prefer one syntax over another, but I will note that dual_state's use of the undefined_object lends a unique feel to code that uses it. The programmer's intent is unmistakably clear when "undef" is used to initialize members:
[snip]
The concept of using self-evident constructs to obviate documentation is a valuable one. It is detailed in the Boost.noncopyable notes.
Boost.Optional has some interaction with (including initialization from) boost::none, which seems to correspond to your "undef".
Good point, but I would also like to see overloaded == and != operators using boost::none.
Regarding guaranteed object delivery: I must say I find this design aim questionable. The whole point of these facilities (Boost.Optional and your dual_state) is that there are situations where it is simply not possible to assign a meaningful value to the object. It is only logical that this implies that wherever the object is used, there must either be some invariant in user code that guarantees that it is defined, or an if/else to deal with both cases. Quickly default constructing the underlying object when it turns out that the user is attempting to use it when it is not defined seems like a very arbitrary thing to do, and I believe it will only be sensible and correct in very few situations. This is the first reason why the notion of Boost.Optional being a model of OptionalPointee appeals to me.
Our opinions differ on this point. I believe there are cases where providing a default object is quite appropriate, but again, it all depends on the application. If, as you say, an "invariant in user code" can be used to control a program's behavior, why can't the defined and documented behavior of default object delivery serve as the invariant -- especially if it simplifies syntax?
Regarding full operator support: I'm very skeptic about this design aim, mainly because it is an attempt at making the class as a whole a transparent wrapper around the underlying object, which is fundamentally not possible in C++ and will only cause confusion. Sure, the syntax is nice for a few cases, but conceptually it makes the interface complex and inconsistent.
I'm skeptical, too. I am happy to discard this idea.
This is the second reason why the notion of Boost.Optional being a model of OptionalPointee appeals to me: the syntax and semantics are pretty much as one would expect (from a smart pointer).
So, in conclusion, the motivation for your dual_state is very valid, but personally I think Boost.Optional is a more appropriate design.
Eelis
Thanks, for your opinion. I would say we mostly agree, except that I believe there are cases where guaranteed object delivery is useful. Perhaps something like dual_state would be best built as an addition to Boost.optional, as David Abrahams has suggested. So we could say Boost.optional is a robust and appropriate design, and dual_state may offer some useful (though, uh, optional) additions to Boost.optional. Thanks again. -Andy