On Oct 14, 2005, at 3:01 PM, Ian McCulloch wrote:
Fernando Cacciola wrote:
Joel de Guzman wrote:
[...]
The nullability aspect is *besides* the point and has nothing at all to do with the rebinding semantics.
This is 100% false. Is 100% the opposite.
Rebinding semantics are there _precisely_ and _only_ to solve a problem posed by nullability.
Let me say that again:
Rebinding semantics are there _precisely_ and _only_ to solve a problem posed by nullability.
So once again, I ask you to deeply consider nullability and the problem it poses on assignment (I hope I don't have to repeat it again), then weight my proposed solution (rebinding) with your expectactions. If possible, propose a better solution or at least show that you don't think the problem is worth a controversial solution like rebinding.
If optional<> is to be useful for references, then it should have the same semantics that a class acting as a proxy-reference has. ie, if I use optional<> with a class like
template <typename T> struct Proxy { explicit Proxy(T& obj) : my_obj(&obj) {}
Proxy& operator=(T const& obj) { *my_obj = obj; return *this; }
// ...
T* my_obj; };
then optional<T&> should act as close to optional<proxy<T> > as possible. ie., if optional<T&> does something different just because the template argument is a reference, then there must be a way to replicate that behaviour with optional<proxy<T> > too. As to what behaviour is most useful, I am not sure because I have not yet come across a situation where I wanted an optional<T&> - but I do find the rebinding behaviour surprising.
I don't see what nullability per-se has to do with this discussion.
I agree with Ian and Joel. I don't see that nullability should be the decisive characteristic. Much more so optional is defined by: In the case that optional holds a value, it should work exactly (or as much as possible) like the type it contains. Rebinding goes counter to that. Best, Jaakko