Fernando Cacciola wrote:
If I can say it, I don't think that they are really good examples.As an example, currently the C++ standard includes T & stack<T>::top(), with precondition !(stack.empty()).Instead, it could be may_be<T> & stack<T>::top(); // no precondition required <set> could be improved also, instead of: pair<iterator, bool> set::insert(const value_type & x) we would use may_be<iterator> set::insert(const value_type & x)Those are interesting examples! Thanks. They can all be paralleled with optional<> whatever the model and interface we choose. Which can of shows that the concept is useful.
The stack::top signature is wrong, it should return a value and not a reference and thus it may require a copy of the returned object. This makes the proposed signature is potentially less efficient. Moreover, the result of top() could not be used by the caller to modify the top-most element. For this reason, a more correct signature would be
may_be<T&> stack<T>::top();
but, unfortunately, I don't think it's legal.
The proposed signature of set::insert is a downgrade and not an improvement. Even if the element is not inserted, I still may want to have the iterator. In order to perform its operation, insert() will have to compute such iterator, so what's the point in discarding it?
Just my opinion,
-Alberto
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
