On Wed, 07 Sep 2011 23:44:42 -0700, Nevin Liber <nevin@eviloverlord.com> wrote:
On 7 September 2011 23:15, Mostafa <mostafa_working_away@yahoo.com> wrote:
1) Were the assignment operator disallowed for optional<T&> and only optional<T&>, there would no loss of programmatic generality when optional<T&> is used as a local variable.
I just don't see a use case for when it is a local variable, ... <snip>
In trying to answer "what are the implications of disallowing the assignment operator for optional<T&>" I had to consider the all possible use cases of optional<T&>, and they are 1) where optional<T&> is used as a local variable, and 2) where optional<T&> is used as a member variable. Well, there are namespace variables too, but it's obvious the implications are the same as 2).
The case we've mentioned that you haven't covered is returning it from a function,
In what respects haven't I covered it?
which again, is problematic for two reasons:
(1) Types that are Copyable but not Assignable are surprising
Not necessarily, think of Pimpl. If I have a Pimpl class heirarchy, then operator= becomes problematic for the base class, therefore I disallow it in all cases. What about using such a Pimpl in stl-like containers? Answer, use the opaque handle of the Pimpl, and reconstruct the Pimpl from the opaque handle where necessary.
(2) It is rare to return a reference anyway, as something outside of the callee has to manage the lifetime of the underlying object
Not that rare. Let's say I'm using raw-pointer/reference idiom to convey the semantics of optionalness, then returning a reference is certainly an option. I believe it's the callee that has to manage the said lifetime. Mostafa