Sven, kerrek, first of all, I'd like to say that this is a ver good discussion and very insightful. Very useful Indeed. Sven, I agree with you that it doesn't feel right to check the availability of members. I understand that you just want to be safe with the pretty printer by ensuring that it is a container that you're passing in. However, doing so may not be in line with the spirit of STL itself. But first, let me explain how I see STl. I see STL holds the dynamic language duck typing in a statically typed environment. "if it walk, swim, quake like a duck then it's a duck" The same with the problem you guys are facing. If a 'thing' support a begin and end function and it returns an iterator, or const_iterator then it is a container as far as e function cares. As it can operate under such contract. This is not conceptualize a defect. Its an outcome of how tempting works. There is no guarantee that the begin method is the begin method mentioned in the IContainer method for instance. Hence, there is never a guarantee that a begin method means the begin method that the original implementor thinks. Again the contract permits it to be like that. So, if I were to analyze what should've been done in the case of Sven solution, I'd suggest to leave it like that and put a note at the documentation. This will ensure the most flexible solution. But it punishes user that use it wrongly. If you want to be safe, and doing it properly, then I'd suggest that you actually restrict T to be derived from an interface such as IContainer. However, doing so means you have to change all the standard containers to implement IContainer which is not feasible. Other than those two, you are risking on hacking the solution and from my experience it's best not to hack if it's possible especially if your code is going to be used by other people.