Re: [boost] [optional] Reference assignment

From: Joel de Guzman (joel_at_[hidden])
Date: 2003-11-05 02:38:37

Hi Brian, Fernando,

Ok, so Brian's solution seemed good on paper. I tried it but failed :(
I did concede that "If it ain't broke, don't fix it". Now, I am convinced
that it is broken. To refresh, here's Brian's scheme:

    template <class T>
    class match 
    {
        optional<T> data;
        ...
        void value( T y ) 
        {
            *data = y;
        }
    };

Fix, for the case where T is a reference:

        template <typename ValueT>
        void value(ValueT const& y) 
        {
            *data = y;
        }

[ we'd want to allow m.value(3), for example, where T == int& ]

FYI, the current value member function is implemented this way:

        template <typename ValueT>
        void
        value(ValueT const& y)
        {
            impl::match_attr_traits<T>::set_value(data, y, is_reference<T>());
        }

[ Notice the special case for references ]

I tried to replace this with Brian's code, but the regression tests failed.
Why? Because [where o is an optional<T> and v is a T ] *o = v only works 
when o is initialized, while o = v works even if o is uninitialized. IOTW, I need 
this to work:

    match<int> m; // unitialized
    m.value(3); // initializes m

So, Brian, to answer your question "So does my code above work for you?",
well, unfortunately, not. I am now inclined to believe that, indeed, "If it ain't 
broke, don't fix it". However, in this case, "it" means ***the tried and true
C++ reference semantics***.

Thoughts?

Regards,
-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net
Joel de Guzman <joel_at_[hidden]> wrote:
> Brian McNamara <lorgon_at_[hidden]> wrote:
>> On Fri, Oct 31, 2003 at 01:26:28PM +0800, Joel de Guzman wrote:
> 
>> Hurray for the current semantics of optional!
>> 
>> I know that sounds sarcastic, but seriously: is there anything wrong
>> with this use-case?  As far as I can tell, optional already works fine
>> for your needs.  (If it ain't broke, ...)
> 
> Hi Brian,
> 
> Reading my past few posts, I guess I deserved the sarcasm.
> Pardon me for the delay in replying. I just came back from a nice short
> weekend vacation. Well, I feel fresh with new prespectives now!... :)
> 
> Well I promised myself to be more objective. Sometimes I lose sight
> of different possible perspectives. No, there's nothing seriously wrong with
> your use-case. Yes, optional already works fine for my needs. There are
> a few rough edges, however, that seemed to make me feel uncomfortable
> and these are all due to the mixed value-pointer-like container-like API.
> I guess I can never be comfortable with it. For example:
> 
>     optional<int> o(i);
>     o = i2; // A
>     *o = i2; // B <same as A>
> 
> and for references:
> 
>     optional<int&> o(r);
>     o = r2; // C
>     *o = r2; // D <not same as C>
> 
> It seems that your preferred semantics (the current semantics) creates
> a special case (A is equivalent to B but C is not equivalent to D). Well,
> I reckon that I can get by by avoiding optional assignments from T
> and just use get() (which I prefer over the, ahemmm, funky *o interface):
> 
>     optional<int> o(i);
>     o.get() = i2;
> 
> and for references:
> 
>     optional<int&> o(r);
>     o.get() = r2;
> 
> Perhaps assignments from T is not good? I don't know. I do not have
> a strong opinion any more. I can live with whatever is provided. I leave
> it up to Fernando to do what he thinks is right. Let me just conclude with
> a reminder (from the Zen of Python):
> 
>     There should be one-- and preferably only one --obvious way to do it.
> 
> Right now, optional has three:
> 
>     o = v;
>     *o = v;
>     o.get() = v;
> 
> Regards,