From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2003-09-11 10:35:44
Hamish Mackenzie <hamish_at_[hidden]> wrote in message
> On Wed, 2003-09-10 at 17:05, Fernando Cacciola wrote:
> > > Any chance of adding .empty() member? I am not to fussed about this as
> > > it might make code that uses optional< bool > or optional< T * > clearer
> > > but will probably also make optional< std::vector< T > > more confusing.
> > The new optional<> now has ".is_initialized()"
> > for those who won't/can't use safe_bool or operator!
> Sweet. Though now you have to get the US and UK to agree on how to
> spell it :-)
I'm from Argentina and I speak Spanish so both spellings
are equally foreign to me. :-)
> > I see your point but I'm not sure if this is a recommended pattern.
> It also allows the function to be used with classes without copy
I don't follow. How so?
> template< typename T >
> void f( const optional< T > & );
> restricts T to copyable classes.
Why? f() as you wrote it, doesn't.
In fact, in place construction, a new feature of optional<>,
effectively relaxes the CopyConstructible requirement in some
> I think optional< T > is the middle of three cases
> T // Known to exist
> optional< T > // May or may not exist
> null_optional< T > // Known not to exist
> null_optional would have the same interface as optional but would
> need no storage overhead.
> There would be an implicit constructor to make an optional< T > from
> null_optional< T > and optimised versions of the optional_empty and
> optional_get functions.
Hmmm.. what would be the purpose of a _type_ like null_optional<>?
I mean, why would you express the idea as a different type instead of
a different state?
In which way is it better than an uninitialized optional<>?
> > The purpose of allowing some degree of similarity between T and
> > optional<T> is to easy the _manual_ transition from one to the
> > other, but optional<T> is not intended to blindly replace T,
> > as in your example.
> Yes this is a problem. It would be handy to have a way to
> check the type so
> void f( const optional< some_big_class > & );
> would become
> template< typename T >
> void f( const T & )
> is_optional_version_of< some_big_class, T >::value );
Why do you want to have a function that receives either
an optional<T> or a T?
The semantics you seek are expressed by variant< T, optional<T> >,
though it looks tautological to me.
Managing this sort of duality is the role of optional<> itself.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk