[I fear this conversation is drifting off-topic, but I hope the moderators will forgive a further reply]

> > and because it is an any he has no means of
> > knowing for sure if the contents are streamable at instantiation time.
>
> Don't put an object into the any that can't be cout and then try and
> cout the any.

> > He has to "trust to luck".
>
> His code put the object into the any in the first place. No luck
> involved. Or it's someone elses code but he knows what someone elses
> code is giving.

Ah you are lucky. You live in a world where you and your co-developers never make any mistakes and the documentation is always up-to-date.
I am more fallible and make mistakes and if possible I'd prefer to be told about them via a compile-time error rather than blowing the stack at runtime.
 
> There is more to an object than it's type. You can't just guess what
> to give a function based on only the information that it wants one
> unsigned integer.

Sure - I don't think anyone has said type-safety is a panacea for all coding ills or a replacement for documentation. But the consensus is that it very helpful in C++.

Incidentally, you may be interested in the Constrained Value library (http://student.agh.edu.pl/~kawulak/constrained_value/index.html).
So if your function needs something in [a,b] rather than [0,UINT_MAX] the type system can give some assistance.

[snip irrelevant stuff about "lockup safe" - it's a non-sequitur ]

> I do appreciate there are different views here, however if one has
> chosen boost::any already then they already know what they want,
> especially given the stuff in std. Suggesting that because you can
> cause an error an error could unexpectedly occur when you pass
> unknown objects into an unknown method in a non sensible example
> that wouldn't happen isn't helpful.

You have to appreciate where we are coming from. Your original post had code where you tried to pass the result of a runtime method as a template parameter.
This suggests you are not hugely familiar with C++ and perhaps Boost.Any, so people naturally ponder whether Boost.Any really is the right choice (often it isn't) and try to help by making sure the OP has heard about the alternatives.
 
> The documentation says that for boost::any a program doesn't crash
> if you try and cast an any into a type it was not set as, it gives a
> null instead.

Actually, If try to retrieve a pointer to the type, it would return a null, if you tried to retrieve a value, it would throw bad_any_cast.
 
> For crashing on stream insertion when it's contents can't be
> inserted vs giving an error that will stop the program more safely
> and tell the coder what went wrong, I think the latter is more
> desirable, unless there is a significant performance difference in
> which case either one is valid.

Right, if you went down a has_operator_stream route, you could throw an exception instead of blowing the stack.

Feel free to offer a patch along those lines if you want , but it opens up a can worms. If operator<<, why not operator+, or member foo() etc... I am sceptical that the maintainer would accept it.