C++20 Concepts仅规定最小功能，作为静态接口是否存在缺陷？

你遇到的是Concepts设计上的核心特性：它仅定义模板参数需要满足的最小功能集合，而非限制类型的功能上限。这和CRTP通过继承接口类来强制类型仅实现约定接口的方式完全不同，但这不代表Concepts不适合作为静态接口——只是需要调整设计思路。

问题根源与解决方案 #

你的代码中func调用了bar2()但未将其加入is_something的约束，这才是导致用户类型可能报错的原因。作为库提供者，有几种方式解决这个问题：

1. 确保Concept覆盖所有实际依赖的接口

这是最直接且推荐的方案：把库代码中所有用到的成员函数都加入Concept的约束中。这样不符合完整接口的类型会在模板实例化阶段前就被Concept拦截，避免后续编译错误。

修改后的Concept示例：

template <typename T>
concept is_something = requires(const T& s) {
  { s.bar() };
  { s.bar2() }; // 补充实际用到的接口约束
};

这和CRTP中接口类声明纯虚函数的逻辑一致：你需要保证接口定义完全匹配代码的实际需求。

2. 用封装层强制隔离额外功能

如果不想修改Concept（或Concept需要保持通用性），可以在库内部对传入类型做一层封装，仅暴露Concept约定的接口：

template <is_something F>
struct ConceptWrapper {
  const F& inner;
  // 仅暴露Concept约定的接口
  void bar() const { inner.bar(); }
};

template <is_something F>
void func(const F& s) {
  ConceptWrapper wrap{s};
  wrap.bar();
  // wrap.bar2(); // 此处会直接编译报错，因为封装层未提供该接口
}

这种方式能强制库代码只能使用Concept约定的功能，避免误调用额外成员。

对疑问的解答 #

• 你并没有忽略关键要点，Concepts的设计目标就是提供非侵入式的最小接口约束，它允许类型拥有超出约定的功能，但这并不影响它作为静态接口的适用性——反而比CRTP更灵活，比如无需修改类型代码就能适配接口。
• 作为库作者，核心是确保Concept的定义与所有依赖它的库代码的实际需求完全匹配。只要做到这一点，用户的合规类型就可以正常运行，不会出现“符合Concept但无法执行”的情况。

内容的提问来源于stack exchange，提问作者NewbiZ