Brian McNamara <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> So I completely disagree that optionals should mix the interfaces of
> optional and the wrapped object into one. I think there should be an
> explicit unwrapping operation. But this is just my opinion, based on no
> practical evidence/experience, and I'm sure there are trade-offs either
> way. I'll explain the crux of my own reasoning below.
>
In a way you're right.
My original optional<> submision followed this rule.
safe-bool was added because of the ubiquitousness of the
implicit boolean evaluation idiom.
Implicit construction and direct assignment was left out
precisely in order to keep both interfaces separated.
> On Sun, Aug 31, 2003 at 11:59:42PM +0800, Joel de Guzman wrote:
> > It's really strange (and hard to explain) that you have to dereference
> > optional<B>. Example:
> >
> > F(tuple<A, optional<B>, C> args)
> > {
> > A a = get<1>(args);
> > B b = *get<2>(args); // strange!
> > C c = get<3>(args);
> > }
>
> I don't think it's strange at all; an optional<B> is not a B!
>
Right.
Just like any XYZ<B> is not an B, so the middle line should have
the cannonical form:
XYZ<B> b = get<2>(args).get();
Therefore, it is optional::get() that needs to be fixed, not optional::operator*(),
and not adding an implicit conversion to T.
Fernando Cacciola
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
