Joel de Guzman wrote:
Fernando Cacciola wrote:
Rob Stewart wrote:
From: "Fernando Cacciola" <fernando_cacciola@hotmail.com>
I wonder what would be the result of the following thought experiment: Please, answer the questions _without_ looking at the answers, and if possible post your initial results; then compare with the answers.
IANAOU either (yet!), but I'll give my answers.
First, I'll describe what I think the right behavior is; this may be exactly how optional works now or it may not be. I haven't compared this description to optional's documentation.
OK. You just described Joel's proposed behaviour, and, from your test results, it's clear that at least you wouldn't be confused about the fact that in one case it binds while in the other it doesn't. Now I wonder how would that be in real code... I mean, in my example you could infer from the context that 'o' was null in one of the cases... but what if you can't tell that? you wouldn't be able from context alone to know the expected effect of assignment. That's real problem don't you agree?
For the record, that is not exactly my proposed behaviour. I am objecting to *any* form of bind/rebind *from assignment*. Maybe that was not clear (as I noticed from Peter Dimov's reply) but what I am advocating is bind only at construction time (see my reply to Peter Dimov).
Ha yes, you are right.. You just once mentioned that you could live with rebinding from copy assignment at most.
Anyway, I like the new direction this is heading into
Me too! Finally getting somewhere.
(i.e. no assigment from T and the reset(), reset(nil), reset(T) syntax).
Well, I'm not so sure about reset(). My very first boost submision had reset() and no assignment from T, exactly as we are considering now. But the big problem, and it was big, was that it just made people be even more confused about optional<> being yet another smart pointer (precisey becasue auto_ptr and shared_ptr uses it). AFAICT, the choice between: o = make_optional(val); o = nullptr ; and o.reset(val); o.reset(); is just cosmetical.. and at that, I prefer the first version because it pushes optional<> away from a smart_ptr. IOW, that it uses * and -> just like any other nullable type makes sense because the semantics of these operators are the same for all nullable types; but the semantics of reset() in the case of optional<> are different from those of a smart ptr (deep vs shallow). Best -- Fernando Cacciola SciSoft http://fcacciola.50webs.com/