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/