> I'm just saying, it seems contrived to me

Sure. Contrivance is in the eye of the beholder for this kind of thing, I think.

> and the most likely outcome of this type of broken template is failed compilation.

I don't think that was ever in question? It's "just" a matter of when/where said failure occurs.

> This is incompatible with how C++ templates work.

Right, hence "tangentially related". I didn't mean to imply that the aside is applicable to C++ templates, even if it could hypothetically be. Just thought it was a neat capability.

> This sounds wrong to me.

Wrong how? Definition checking was undeniably part of the original C++0x concepts proposal [0]. As for some reasons for its later removal, from Stroustrup [1]:

> [W]e very deliberately decided not to include [template definition checking using concepts] in the initial concept design:

> [Snip of other points weighing against adding definition checking]

> By checking definitions, we would complicate transition from older, unconstrained code to concept-based templates.

> [Snip of one more point]

> The last two points are crucial:

> A typical template calls other templates in its implementation. Unless a template using concepts can call a template from a library that does not, a library with the concepts cannot use an older library before that library has been modernized. That’s a serious problem, especially when the two libraries are developed, maintained, and used by more than one organization. Gradual adoption of concepts is essential in many code bases.

And Andrew Sutton [2]:

> The design for C++20 is the full design. Part of that design was to ensure that definition checking could be added later, which we did. There was never a guarantee that definition checking would be added later.

> To do that, you would need to bring a paper to EWG and convince that group that it's the right thing to do, despite all the ways it's going to break existing code, hurt migration to constrained templates, and make generic programming even more difficult.

I probably could have used a more precise term than "backwards compatibility", to be fair.

> Until you actually pass in some concrete parameters to instantiate, you can't test anything. That's what I mean by saying it's "unavoidable".

I'm a bit worried I'm misunderstanding you here? It's true that C++ as it is now requires you to instantiate templates to test anything, but what I was trying to say is that changing the language to avoid that requirement runs into migration/backwards compatibility concerns.

> No language I can dream of that has generics could do any different.

I've mentioned Swift and Rust already as languages with generics and definition-site checking. C# is another example, I believe. Do those not count?

> I wasn't prescribing a fix. I was describing a new type of error that can't be detected automatically (and which it would not be reasonable for a language to try to detect). If the template requires `foo()` and you just create an empty function that does not satisfy the semantic intent of the thing, you will make something compile but may not actually make it work.

My apologies for the misdirected focus.

In any case, that type of error might be "new" in the context of the conversation so far, but it's not "new" in the PL sense since that's basically Rice's theorem in a nutshell. No real way around it beyond lifting semantics into syntax, which of course comes with its own tradeoffs.

[0]: https://isocpp.org/wiki/faq/cpp0x-concepts-history#cpp0x-con...

[1]: https://www.stroustrup.com/good_concepts.pdf

[2]: https://old.reddit.com/r/cpp/comments/cx141j/c20_concepts_an...