Re: [boost] Report from Mont Tremblant C++ Committee meeting

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).
>
OK.
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
SciSoft
http://fcacciola.50webs.com/