One way to workaroun this is to allow the user to add a default type:
typedef
BOOST_TYPEOF_WITH_DEFAULT(some_expression,some_backup_type_if_some_expression_not_registered) type;
Is this acceptable?
Yes, that seems the best solution. An excellent idea. Should I create a Trac suggestion for it or will you remember to implement it if you decide to do it ? If you do this, I think you will want to do it for TYPEOF_TPL also. I see much less use for AUTO and AUTO_TPL defaults if the type is not registered but I think you should also implement it for these two also both to be orthogonal and for the possibility that someone will find a use there also.
I will remember :) I am, however, not sure about the proper name for this beast. Also, I am a bit uncertain about the best behaviour: I see mainly two options: 1) typedef BOOST_TYPEOF_WITH_DEFAULT(expression,typename some_alternative_expression::type) type; 2) typedef BOOST_TYPEOF_WITH_DEFAULT(expression,no_type) deduced_type; typedef mpl::eval_if< boost::is_same<deduced_type,no_type>, boost::mpl::identity<deduced_type>, some_alternative_expression
::type type;
In the second alternative we could simplify the name to BOOST_SAFE_TYPEOF(expression) or BOOST_NONFAILING_TYPEOF(expression) or BOOST_TYPEOF_OR_NONE(expression) or BOOST_Your_idea_goes_here(expression) And, yes, I agree that this should be implemented for TPL. Only the first alternative can be implemented with AUTO... Another alternative is to implement alternative 1 an then alternative 2 by using alternative 1. I am still unsure about the name. BOOST_TYPEOF_WITH_DEFAULT seems a very long name, and not overly descriptive either. Regards Peder
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost