From: David Abrahams (dave_at_[hidden])
Date: 2003-09-02 09:14:04
David Abrahams <dave_at_[hidden]> writes:
> Dave Gomboc <dave_at_[hidden]> writes:
>> [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.
> That could have a significant negative impact on performance and code
> size, FWIW.
>>> 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
> So do the proxies required by input iterators over classes and a few
> other such proxy pointers. They all contain the value they "point
> IMO get<X>(y) is the solution to this problem.
>> But they are iterators, and random-access iterators exhibit pointer
>> semantics. That's the reason iterators use operator* and operator-> in the
>> first place!
> Input iterators also contain the values *they* reference.
Just to clarify, I don't claim this makes optional<T> "pointer-like":
I think it's an _approximation_ to exactly what the anti-pointer crowd
have been saying it is, a "T or not". I do think that renders the
pointer interface non-ridiculous, and I see the author's point about
the syntax being a useful clue as to its possible nil value.
Unfortunately the C++ language makes it impossible for it to ever
really act like a T, and I think a core syntax which doesn't try to
hide that fact is probably a good idea.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk