std::is_convertible和std::convertible_to有哪些实际应用上的区别？

Question

根据en.cppreference.com（据我所知）：

- std::is_convertible是一个特征类，要求类型From和To是这样的：返回类型为To的函数可以编译并返回一个From值。 - std::convertible_to是一个概念，要求类型From和To符合上述条件，并且可以使用static_cast<To>将类型为From的r-value引用转换。 std::is_convertible所施加的要求似乎相对简单。相反，std::convertible_to的r-value引用转换要求对于如此简单的C++20特性示例来说似乎过于具体。

作为C++新手，我无法理解两个网页提供的一些术语和补充说明的部分，也无法想象两者之间的确切差异。

以下是一些相关问题：

- 对于不仅受std::is_convertible约束而且受奇怪的r-value引用转换要求约束的类型From和To，有哪些实际影响？ - 哪些候选类型的From和To被r-value引用转换要求拒绝？ - 除了概念的便利性之外，程序员为什么要使用std::is_convertible或std::convertible_to中的任何一个来约束其函数返回类型或参数类型？

以下是一个更简单的解释或示例。谢谢！

- Monad

Answer 1

std::is_convertible<From, To>（类型特性）检查类型From是否可以隐式转换为类型To。

std::convertible_to<From, To>（概念）检查From是否既可以隐式也可以显式地转换为To。这种情况很少见，这些类型是荒谬的，但在通用代码中，不必担心这种情况非常好。

一个例子：

struct From;
struct To {
    explicit To(From) = delete;
};
struct From {
    operator To();
};

static_assert(std::is_convertible_v<From, To>);
static_assert(not std::convertible_to<From, To>);

- Barry

---

同意！我想补充一点，当您知道所需的确切要求并且因此可以允许更多的候选类型被接受而不使用可转换为（convertible_to）这样的通用概念时，考虑自定义要求条款或概念可能很重要（例如，可能会使用_just_ std :: Is_convertible）。 - Monad

检查类型From是否隐式可转换为类型To是一个分类错误：在C++中，类型不能转换为类型-尽管库规范中到处都这么说-表达式可以转换为类型。实际上，is_convertible_v<From,To>和is_convertible<From,To>都检查这样一个表达式e是否可转换为类型To，使得decltype((e))为From。 - Casey

“在通用代码中不必担心这种情况确实很好。” - 标准库概念的重点之一是通过正式排除它们来清楚地表明我们认为这些情况是病态的。 - Casey

使用“not”而不是“!”导致得分为-0.1。请注意在将来的代码中使用正确的语法。 - user253751

@Casey add_rvalue_reference_t<From> :) 除了 void 之外，我们不关心 prvalue 的废话...（编辑：实际上，我们想要 remove_cv_t<add_rvalue_reference_t<From>> - 已提交 LWG 问题） - T.C.