|
Boost Users : |
From: David Abrahams (dave_at_[hidden])
Date: 2005-04-24 06:19:22
"Fernando Cacciola" <fernando_cacciola_at_[hidden]> writes:
> I suppose you're saying that given what you wrote, and the fact
> (left implicit) that when 'ora' takes the 'T' branch a variant type
> could just assign the referred value but not rebind, then the choice
> of what to do in the already initialized case just don't follow
> directly from the only possible option in the uninitialized case.
I think that's what I'm saying, yes.
> If that's the case, you're right, though I didn't intend to make my
> choice appear as a logical consecuence of the constrain (when
> uninitialized it must bind to the reference).
Actually when uninitialized you can view it as though the reference
isn't there to begin with. In fact, that's probably the correct view
since that reference would be an uninitialized one, which as we know
is not a valid state for a C++ program to be in.
> I rather intended to show the constrain as a mere motivation for the
> choice. Clearly others choice are still valid.
I think you may be able to legitimately motivate the choice on the
grounds of usability or lack of error-prone-ness, but I don't think
the constraint works as a motivation.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net