On Tue, 06 Sep 2011 07:31:23 -0700, Stewart, Robert <Robert.Stewart@sig.com> wrote:
Mostafa wrote:
On Fri, 02 Sep 2011 11:10:01 -0700, Stewart, Robert <Robert.Stewart@sig.com> 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> f() { 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 response? 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. Mostafa