On Sat, 03 Sep 2011 20:34:41 -0700, Jeffrey Lee Hellrung, Jr. <jeffrey.hellrung@gmail.com> wrote:
On Sat, Sep 3, 2011 at 7:55 PM, Mostafa <mostafa_working_away@yahoo.com>wrote: [...]
Aren't we all? But there are differing notions of consistency floating around. I'm motivated by consistency for the assignment operator of optional<T&>, Fernando's motivated by consistency of programming w.r.t. to template programming and use of optional in general. And as Fernando pointed out, it may not be possible to satisfy all these notions simultaneously. My thought was, and continues to be that if all these notions of consistency can't be satisfied simultaneously, then instead of satisfying some fully and others partially, why not just disallow those operations that are partially consistent. Or more specifically, what are the implications of just disallowing those operations that are partially consistent?
One implication would be a breaking of existing code. Another implication would be greater difficulty in using optional<T> in a generic context when T could be a reference type.
That seems to be the consensus so far. Assuming that I'm creating optional2, so we don't have to worry about existing code, and that it's equivalent to optional in all respects except that the assignment operator has now been disallowed across the board, and we've only retained a no-argument reset method. What are the implications of that? The only consequence I see is that optional2 may not be used with stl-like containers. And how prevalent is the use of the existing optional with stl-like containers anyway? What's the motivation for this line of inquiry? Partial inconsistency w.r.t. to the assignment operator is eliminated and the use of optional2 in a generic context is not comprised. Mostafa