RE: [boost] Re: optional vs variant vs any

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2001-08-30 12:14:50

----- Original Message -----
From: Kevlin Henney <kevlin_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, August 30, 2001 7:41 AM
Subject: [boost] Re: optional vs variant vs any

> >   From: "Vesa Karvonen" <vesa.karvonen_at_[hidden]>
> >
> >> Yes, though replace "void" with a real (but useless) type, like:
> >> struct unused {};
> >
> >hmn... Do you mean that 'void' is an illegal parameter for 'variant'?
>
> FWIW, I personally consider "void" to be a real and useless type :->
>
> >> Pointer syntax doesn't really make sense for variant or any, because
there
> >is
> >> no fixed return type for either. For optional and smart pointer, there
is
> >> only one possible type. This I think justifies the syntactic
differences.
> >
> >I was mainly thinking of the following syntax:
> >
> >    !x         ...meaning...     x.empty()
> >    if (x)     ...meaning...     if (!x.empty())
> >
> >And possibly:
> >
> >    0 == x     ...meaning...     x.empty()
> >    x == 0     ...meaning...     x.empty()
> >
> >However, the usefulness of the above syntax is not very clear. It seems
to me
> >that 'vswitch' and 'cast' are the proper ways to use 'variant' and
probably
> >'any', too.
>
> >From experience I would recommend against it. The semantics of any, in
> common with many other value types, is not sufficiently pointer-like to
> justify the slight increase in convenience but noticeable relaxation in
> type safety. The original any (or at least the one submitted to Boost)
> had a UDC, but the review process convinced me to remove it.
>
> And, for an extra EUR 0.02, supporting "x == 0" is an order of magnitude
> less desirable than supporting "!x". Except for proper smart pointer
> types, it is not worth pursuing the gymnastics involved in trying to
> make this work and be reasonably type safe.
>
I think I managed to support "x==0" in optional, thanks to the fact that you
cannot initialize it directly nor access its value without operator *() (or
.value()).
That is, you are required to write: optional<T> x ; *x = T(...). Therefore,
the operator void*() used to support the syntax is pretty type safe.
It isn't, though, dumb-user safe: You can still write:

optional<int> opt = foo();
if ( opt == 3 )  // Oops! This is not what the programmer probably intended!

This last issue is giving me second thoughts about supporting direct
comparison to pointers.
The main reason why I don't remove it is that "x == NULL" is what a user
would expect as part of 'pointer semantic'

(If we had a non-integer true null pointer value this wouldn't be a problem)

In the case of optional, it makes complete sense to provide only a default
constructor, because if you could initialize x with something you shouldn't
be using optional in the first place; that is, it is completely senseless to
write optional<T> x = T(...);

Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com