"David Abrahams" <dave@boost-consulting.com> escribió en el mensaje news:uy8d2p528.fsf@boost-consulting.com...
"Brock Peabody" <brock.peabody@npcinternational.com> writes:
On Behalf Of Fernando Cacciola Sent: Tuesday, March 01, 2005 10:39 AM To: boost@lists.boost.org Subject: [boost] Re: [optional] new assignmet semantic and references
So I think I will fix it unless users speak up... Though I will post this issue in the users list as well.
First I'd like to say that I love optional<>. When I first read about it I didn't think I'd use it much, but now I find myself using it all over the place. It's useful for so many things, but to me the most important is how it improves my ability to make code self-documenting.
Personally, I like it the way it is. I've used optional quite a bit and it makes sense to me that operator= changes what an optional holds. I don't think it is a good idea to give operator= special semantics for references.
I had the same feeling. That's what I meant when I said
"It depends on whether you view optional<T> as a T that might just happen to be missing, or as a container for a T."
I think "a container for a T" is a more manageable meaning for optional<T>.
This issue was there from the very beggining... It sort of reminds me about whether electrons are particles or waves... they're both, but not exactly at the same time in the usual sense... it depends on how do you _want_ to look at them. Unfortunately, optional<> is not as smart as electrons in masking themselves to the user's convenience. IMO both views are equally OK.. Each user sees pros in one and cons in the other, and there is no cut clear concensus on which one is definitely better. Yet I need to weight the balance one way and I choosen to favor the wrapper view... much of the latest evolution goes in this way.
I think it odd, for instance, that given the following optionals:
int a = 5, b = 6;
boost::optional<int&> ra = a, rb = b;
this:
ra = rb;
would have different behavior than:
ra.reset();
ra = rb;
I can understand the desire to mimic the semantics of built in C++ references in boost::optional, but one uses boost::optional precisely in cases where one does not want those semantics - in cases where a reference may not be present, and where you may want to change which object is referred too.
This is what I'd have said if I'd had the time to really consider it deeply and write it out. Nice, Brock.
Well, I agree that optional<> is intended to give you something you don't get straight from the language, but as it is now, its goal is to offer you something more of an extension of what you already get than a replacement. Furthermore, you can get rebinding semantics via optional< ref<T> >. Best Fernando Cacciola