[boost] Re: optional, tie, and iterator_adaptor

From: Dave Gomboc (dave_at_[hidden])
Date: 2003-09-01 17:22:36

[Fernando Cacciola]
> The most fundamental point is that being Haskell a pure functional
> language there is no possibly undefined behaviour to worry about,
> so Maybe doesn't need to address this issue as optional<> does.
... and later ...
> I account the possibly undefined behavior of accesing an uninitialized
> optional as a real and important problem.

You can get rid of the possibly undefined behaviour by defining it!  Throw
an exception when there's an attempted coercion from nil/undefined to a
normal value.

[Fernando Cacciola]
> First of all, let's not confuse syntax with semantics.
> optional<> HAS strict value semantics.
>
> If the choice of 'operators *', 'operator ->' and 'get()'
> as value accessors makes the appearance that is has pointer
> semantics, then it is the documentation that has to be fixed,
> not the interface.
.. and later ...
> The * syntax is not supposed to make optional<> pretend it is a pointer.
> It is clearly not and the documentation says so quite clearly, I think.
> And if it doesn't, then it is the documentation that needs to be fixed.

No, the interface should be changed, because it _looks_ like it has pointer
semantics.  If the semantics of optional can be clear before reading the
documentation then they should be.  Face it, it's wishful thinking to assume
that documentation will solve the problem.

[Fernando Cacciola]
> vector<>::begin returns an object with operators * and ->,
> yet these objects are not pointers, and once that is learned,
> people do not think they are pointers.

But they are iterators, and random-access iterators exhibit pointer
semantics.  That's the reason iterators use operator* and operator-> in the
first place!

Dave