Boost logo

Boost :

Subject: Re: [boost] [optional] Thoughts on disallowing assignment for wrapped references.
From: Mostafa (mostafa_working_away_at_[hidden])
Date: 2011-09-04 01:14:10

On Sat, 03 Sep 2011 20:34:41 -0700, Jeffrey Lee Hellrung, Jr.
<jeffrey.hellrung_at_[hidden]> wrote:

> On Sat, Sep 3, 2011 at 7:55 PM, Mostafa
> <mostafa_working_away_at_[hidden]>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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at