Hi Andrew, It seems we all agree that *alternative* values for optional objects are only needed at the point were such optionals are used, not constructed; so we agree that it is not the direct responsability of optional<> or any other such utility to provide that. Having said that, I do see how the kind of adapter you are proposing can be used to deliver an alternative value given a possibly empty container (the concept could be generalized to operate on containers, not just optional<>). But I'm still largely unsure about the utility of such a thing because it actually hides too much information, like the alternative value which happens to be meaningfull in the local context were it is needed. That is, given: void legacy_consumer( int n = -1 ) ; optional<int> v = get_optional_value(); legacy_consumer( v ? *v : -1 ) ; legacy_consumer( default(v) ) ; The version with the ? is far _better_ IMO than the adapater version becuase it makes it explicit what value is being pass if v is empty (and even that a value is beging pass in such a case). default(v) OTOH is as uninformative as it can be and so I don't think is any better. In one of your posts you mention that you intend the adapter to offer clarity, yet, how can it do that when it hides the default value? I would say that it is "terser", but definitely not more clear. If in the end it all boils down to "value_exist ? value : default" how is a "function object" instead of that a key advantage? You said that "the door has been flung open to many templated constructs that are more difficlt with the ?: operator. For example, a boost::transform_iterator could be created with the adapter to automatically access the underlying objects in a sequence." I disagree.. can you post a concrete example with a construct that is indeed more difficult with operator ?: (... and be fair; i.e. code the operator version the right way...) IMO you still need to show that the adpator is indeed a good thing; if you do that we can start discussing a proper design and implementation for it. Best Fernando Cacciola SciSoft