|
Boost : |
From: Joel de Guzman (joel_at_[hidden])
Date: 2003-11-02 21:40:13
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,
-- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk