Boost logo

Boost :

From: Joel de Guzman (joel_at_[hidden])
Date: 2003-10-31 00:44:37

Fernando Cacciola <fernando_cacciola_at_[hidden]> wrote:
> "Brian McNamara" <lorgon_at_[hidden]> escribió en el mensaje

>> do what you want? If T is a reference type, the match's constructor
>> puts the reference in the optional, and then calls to value() change the
>> value of the referred-to object. If T is a non-reference type, it also
>> works, as far as I can tell.
> Maybe the problem is genericity.
> I guess the implementation of 'value()' cannot use the '*' syntax because
> 'data' might be something different than an optional<>.

Well, not really. a match always has 'optional' data. What I am arguing
is that a match<T> is conceptually an optional<T> and hence, the same
reasoning to both classes must apply: i.e. the match<T> use case must
also apply to optional<T>.

> BTW:
> Joel, your use case seems to indicate that the required aliasing semantics
> are actually needed in case 'data' is in fact initialized.
> If I'm right, this would suggest that my recommended semantic for the
> uninitialized lhs case (treat it as initialization) won't conflict with your
> case here.

What I would really like to see is this parallel:

    int a = 4;
    int& r = a;
    r = 3; // a is now 3


    int a = 4;
    optional<int&> o(a);
    o = 3; // a is now 3

Treating uninitialized lhs as initialization of the reference would
rule out the assignment of constants and literals, right?

Joel de Guzman

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