Daniel Frey <[EMAIL PROTECTED]> wrote:
> Joel de Guzman wrote:
>> Although I don't see this as problematic:
>>
>> optional<int> x;
>> if (x)
>> foo(x);
>>
>> Or perhaps:
>>
>> optional<int> x;
>> if (!!x)
>> foo(x);
>>
>> We already have an implicit conversion to safe_bool and an
>> operator ! anyway. Keep it. There's nothing wrong with it:
>>
>> operator unspecified-bool-type() const;
>> bool operator!() const;
>
> IMHO, there is something terribly wrong here because now optional<T> has
> two interfaces. The interface of optional itself and the interface of T.
> If you think that optional<T> can be used like T (having the
> value-interface), you are immediately fooled by if(x) as it doesn't
> check T's value. A pointer-interface is much cleaner as it gives the
> user a hint that he is using a wrapper and in practice, I always prefer
> to be a little more explicit on these things (even at the cost of an
> occasional * here and there) than to have silent bugs.
If you really want it to be explicit, the first version, which I prefer
(and you snipped ;-) is so much better:
optional<int> x;
if (x != none)
foo(x);
Who's fooling who? You said 2 interfaces, the current optional<T> is
actually the one with the 2 interfaces. In some ways, it has a value
interface (construction, reset , ==, !=) and pointer interface on some
(*, ->, get).
What I am trying very hard to say is to stick to only *ONE* interface
and one concept.
Syntactically, there's nothing inherently wrong with:
if (x)
foo(x);
We see it all the time with ints:
int x;
if (x)
foo(x);
Yet, I have to admit that after thinking about it some more, I realized
an ambiguity when T is bool. Example:
optional<bool> x;
if (x)
foo(x);
That is why I really prefer the more explicit syntax:
optional<int> x;
if (x != none)
foo(x);
A small price to pay, considering the advantages. 1) Unification of
the optional and variant where optional<T> <--> variant<T, none_t>.
2) Only one underlying semantics (value-semantics) as opposed to
(sometimes value, sometimes pointer semantics) and 3) Plays well
with generic code (I'll give another use-case in addition to Mat's).
--
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
