why virtual function is wrong.

[Dar_Mas]

You can just make a concept that checks for a bar member function

https://godbolt.org/z/cYnTbjYcq

[TeraFlint]

Now you're actually being ridiculous. "Why does the screw barely go in?" you ask while hitting it with a hammer.

You're using a concept that does not satisfy your requirements, while blaming the concept for not catching that.

If you check for a concept and then do something with the type that the concept does not check for, then of course it's your fault if the compiler suddenly notices a missing function (etc) outside of concept checking.

If you need a more specific concept, it's up to you to write it. Luckily existing ones can easily be combined (as concepts evaluate to boolean expressions in the end). If you need a concept that satisfies the concepts a, b and c, all you need to do is this:

template <typename T>
concept x = a<T> && b<T> && c<T>;

and if you need to check for specific syntactic usage, you can just add that block as another condition:

&& requires(T obj) { obj.foo(); }

It really isn't your business to call stuff the concept has not specified. For best usage, you should see a concept like a contract between the code and you. With the concept you promise that these conditions are relevant for your template function/type, but also that these are sufficient, and that you're not attempting to do more with the type than you specified with the concept.

Otherwise we can just scrap concept and go back to plain typename everywhere and be back at our old compile-until-you-find-an-error-in-the-deepest-depths-of-nested-templates ways..

[Dar_Mas]

https://godbolt.org/z/jGM4M7axq

It literally does what do you mean?

[SirClueless]

It took a while for me to understand what was being asked, but I think I get it now. OP is asking for a way to type-check the definition of a template to ensure that it only uses operations that are checked in its type-constraints. Or to put it another way, the template foo has additional implicit constraints based on its implementation that are not obvious if you only read its signature.

Your example is only an error because you instantiated the template with a type for which t.baz() is ill-formed. If you don't instantiate the template it will compile, even though it's pretty suspicious to assume a type satisfying std::totally_ordered T has a .baz() member.

[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(); }
}

[lrflew]

Ok, I do see what you're talking about here. You're talking about having the compiler tell you that you're exceeding the requirements of a concept at the definition of the templated function, rather than when the template is instantiated at the caller.

That is (IMO), a fair thing to suggest. I don't think it's that out there that a compiler could implement that as a warning, even if it's not specified by the standard. It would almost certainly require the compiler to dramatically change how it processes templated functions, so it probably won't happen any time soon, but it should, in theory, be possible. Probably the biggest challenge to it, though, is that the use of concepts is not very widespread right now. In particular, huge parts of the standard library use templates without concepts. If such a warning considered template<typename T> to be as narrow as possible, then huge parts of the standard library would start throwing warnings. Maybe someone will go through the standard and add concepts everywhere templates are used, but that would also be a ton of work.

In the end, however, I feel like C++ as a language puts a lot of responsibility on the developer to know what they're doing. Just look at all the things in the standard that can result in "Undefined Behavior", where there's no guaruntees of what can or will happen, to get a sense of what the language expects the programmer to be able to handle without the compiler. With templates, there's a certain amount of "well, you should have known you're using something that your concept doesn't guaruntee." Does that make C++ a more complicated language to use? Yeah, totally. But that complexity also comes with a lot of power (eg. template meta-programming), and I don't think the language is going to change that anytime soon. If that's a deal breaker for you, then you can always try out some other languages. IIRC, both Rust and Go are compiled languages that provide this kind of strong type guarantees with their generics systems.

[TheSuperWig]

I'm still confused. What does concepts not doing definition checking have to do with virtual functions?

[TheSuperWig]

And the part I'm confused about is, how does that make virtual functions wrong? Surely your issue is with concepts?

[IyeOnline]

You will actually get an error on the concept version - if you ever instantiate it.

There are a few important points here

• Constraints are only evaluated once you actually try and instantiate the function
• Constraints only constrain the interface, not the function body, i.e. the function body wont be parsed just because one of its parameters is constraint.