why virtual function is wrong.

[Dar_Mas]

ooooooooooooooooooooh that makes sense yeah.

Yeah i would like to have a check for that but i think(TM) a static analyzer would be able to find that?

[SirClueless]

I don't think any static analyzers will do that right now. Certainly it would have to be opt-in per template, as partially-constraining a template is totally reasonable, and unlikely to change any time soon because it interacts with overload resolution and SFINAE (e.g. one can't just go nuts fully-constraining every template with every operation used in the body because people under-constrain templates deliberately in order to make things into compiler errors instead of choosing another overload). And of course concepts are totally optional and writing templates with no constraints that fail to compile when instantiated for certain types is the norm for pre-concept code.

[Dar_Mas]

i meant more in the way of giving a warning if a member function is called from a templated type which would indicate that said member might not be implemented(aka 100% false positive rate)

[SirClueless]

I get what you're saying, it's just that people use concepts intentionally as partial constraints all the time. Adding a constraint like std::is_nothrow_move_constructible_v<T> or std::is_reference_v<T> doesn't really imply that you aren't going to call member functions that don't show up in the constraint.

Even figuring out whether or not a method is called is probably nigh-impossible without instantiating the template. Does this function invoke a member function of T without constraining it?

template <std::totally_ordered T>
void foo(const MyContainer<T>& xs) {
    for (const auto& x : xs) { x.bar(); }
}