Subject: Re: [boost] [optional] Thoughts on disallowing assignment for wrapped references.
From: Mostafa (mostafa_working_away_at_[hidden])
Date: 2011-09-06 19:23:55
On Tue, 06 Sep 2011 07:31:23 -0700, Stewart, Robert
> Mostafa wrote:
>> On Fri, 02 Sep 2011 11:10:01 -0700, Stewart, Robert
>> <Robert.Stewart_at_[hidden]> wrote:
>> > Mostafa wrote:
>> >> Ahh, I disagree with that. IMO, if maybereff was not bound
>> >> at construction time, then it should always remain
>> >> "uninitialized".
>> > If the only way to make a non-empty optional<T&> is to
>> > construct it from a reference, then it couldn't be used, for
>> > example, as a function return type.
>> A non-empty maybereff can be bound at construction time via
>> construction from a T& or from construction from a non-empty
>> optional<T&>.> The latter would allow it to be used as a
>> function return type.
> Right. When I wrote the above, however, I was thinking of the more
> generalized usage that is possible with optional, though I didn't say so:
> optional<T> result;
> // do stuff
> return result;
> Since copy assignment isn't permitted in your idea, that wouldn't work.
> That means even less generality, so a new type would definitely be in
> order if shown to be sufficiently useful.
I'm presuming that in your "do stuff" section there is going to be
something along the lines of "result = ...". If so, then:
In this thread-path I was exploring disallowing assignment for
optional<T&> and only optional<T&>. Hence the above example should work
for all types T that are not references, but fail for types T that are
references. However, in the latter case, there is no loss of generality
since the above would still be a no-no where T a reference type and
assignment allowed for optional<T&>. Or did I miss something in your
There is some loss of generality w.r.t. to the existing behaviour of
optional when optional<T&> is a member variable and one would want to
return it from a method, since optional<T&>'s initialization is then
restricted to its enclosing objects construction. However, that is how
one would expect the underlying T& type to behave from the outset.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk