On Tuesday, February 07, 2012 17:00:04 Andrey Semashev wrote:
Do I understand it correctly that optional_with_traits is an advanced replacement for optional? If so, will the good old optional be optimized? No, optional will be ("isA") optional_with_traits. It's just a work around. I'd prefer to redefine optional: template<typename T, typename Traits=optional_traits<T> > class optional;
That might in rare cases it could break user code like: mpl::quote1<optional> Personaly I doubt that this is such an issue, but have the best of both worlds I can define a temporary "optional_with_traits" which when boost goes to 2.0 we could deprecate and add the parameter to optional. template<typename T, typename Traits=optional_traits<T> > class optional_with_traits; template<typename T> class optional : public optional_with_traits<T> {...}; Do we gurantee boost users that templates will never add default parameters?
BTW, I would really like to see optional< T& > optimized to store T* internally. I'm going to say something provacative here. I agree with Lucanus. I see no reason for optional<T&>. As far I can tell you could use a T*. The only justification I can think of is on system without memory protection you can build checks into operator*().
Maybe if you're mixing code with old libraries where T* might imply ownership you might use optional<T&> to imply no ownership and some temporary validity. Perhaps we should define a new "smart pointer" called dumb_ptr<T> which can't be assigned into auto_ptr,unique_ptr,shared_ptr, or any pointer type which implies ownership. Maybe I'm missing something, but I don't see the justification. Chris