Hi, I make one fairly modest use of result_of in Boost.Iostreams. My initial implementation included result_of.hpp and guarded the use of result_of with the macro BOOST_NO_RESULT_OF. I then discovered that Borland 5.9.2 and Borland 5.9.3 don't support result_of well enough for my needs, but that result_of.hpp header doesn't set BOOST_NO_RESULT_OF for these toolsets (since they supposedly support SFINAE). So I added checks for Borland version to the guard around result_of. This worked until yesterday. Now it seems that simply including the result_of header fails on Borland (see std_test_result_of_header: http://tinyurl.com/26umcr). I'd like to patch Iostreams as soon as possible, so I'm wondering whether this regression will be resolved by making the header includable by Borland or by marking std_test_result_of_header as an expected failure. It seems to me that result_of.hpp either has to be unconditionally includable, or BOOST_NO_RESULT_OF has to be defined in boost/config.hpp so I can tell whether to include it. If result_of is now really unusable on Borland (and if late model Borland really supports SFINAE), then it's no longer true that BOOST_NO_RESULT_OF is simply the disjunction of two existing config macros, and so it seems natural to define it in config.hpp instead of in result_of.hpp. (It could be defined in config/compiler/borland.hpp and also in config/suffix.hpp if BOOST_NO_SFINAE or BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION is defined.) Thanks, -- Jonathan Turkanis CodeRage http://www.coderage.com