Boost logo

Boost :

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2005-10-18 13:03:04

Hamish Mackenzie wrote:
> On Tue, 2005-10-18 at 10:50 -0300, Fernando Cacciola wrote:
>> The problems with optional<bool> are totally unrelated to the choice
>> of operators * and ->.
> True and I think if you could fix it you would find it much easier to
> sell me on using * and ->. The issue I have with * and -> is that
> they
> do not make it clear that the type in question is supposed to be an
> optional (to someone reading the code).

You mean an object of type optional<> right? Granted.
But don't you agree that it makes it clear that the value being accessed
could be absent?
That is, that the type is nullable (whether as a pointer, an optional, an
iterator, etc...)
And don't you think that making _that_ clear is more important than making
clear that the type is specifically an instance of optional<>?

> I still can't think of an
> example where it is desirable to have X * and optional< Y > use the
> same interface.

Dave's just gave one.

>> It is the safe_bool() operator _alone_ which causes that.
>> We can of course discuss whether such operator is worth it given the
>> ambiguity it creates with optional<bool>. That was discussed at
>> length at the time optional<> was reviewed (with me initially
>> opposing safe_bool()), in the end, we agreed that it had more
>> benefits than this simple counter-example.
> I think this problem extends to other types eg. optional< int >. If I
> have a function
> template< typename RecordType >
> void f( const RecordType & r )
> {
> if( !r.some_integer_field() )
> {
> ...
> }
> }
> If the return value of some_integer_field is changed from int to
> optional< int > will the meaning of the code change without a compiler
> error?
> In my experience with optional it is common place to change something
> from required to being optional and back again.
>> These alternatives fix the problem with optional<bool>.
>> One example is to simply provide operator !, used like this:
>> if ( !!opt )
>> is_initialized();
> I don't like this. I don't think it solves the problem just makes it
> less common (as !bool_value still changes meaning when bool_value is
> made optional).
Point taken.

> Was there a problem requiring something like
> if( opt != null_optional )
> is_initialized();
Something like that is already supported (opt != none)
It's just not the only way to test for absence.
In any event, if dropping safe_bool() were a good idea (I'm unsure the bool
case worth dropping it), that could be left as the only choice.

Fernando Cacciola

Boost list run by bdawes at, gregod at, cpdaniel at, john at