c++ - 如何使概念失败并显示自定义错误消息(C++ 20)

Question

概念非常擅长将错误定位到“不满足约束”的代码行。
但是，我想知道是否可以在此处发布自定义引用消息。 static_assert的好处就是这种可能性。用例:任何想要帮助用户弄清某个表达式为何不满足约束条件的库。
这是一个简单的示例，仅包含一些代码。您可能会争辩说，任何体面的“用户”都必须能够弄清楚编译器的注释“因为'is_base_of '被评估为false”，但是更多的自定义信息不会受到损害。肯定会有更复杂的概念。

template<typename B, typename D> 
concept is_base_of = std::is_base_of_v<B, D>;

template <typename T, is_base_of<T> BaseType>
struct BaseWrapper { };  

int main() 
{
    class Base {};
    class Derived : public Base {};
    class C {};

    using T1 = BaseWrapper<Derived,Base>;
    using T2 = BaseWrapper<C,Base>;         // fails right here, but a custom message would be nice
}

Answer 1

[EWG] P1267R0:自定义约束诊断

I'm wondering, however, if it is possible to issue a custom informational message there.

当前没有作为Concepts的一部分的 native 功能，但是有WG21/SD-1论文专门讨论了此主题:

P1267R0: Custom Constraint Diagnostics

Design

There is already precedent in the standard for custom diagnostics:

[[deprecated("reason")]]

static_assert(cond, reason)

We propose adding a new attribute, similar to​[[deprecated("reason")]]​, for custom constraint diagnosticmessages. Let’s call this newattribute[[reason_not_used("reason")]]​ for now:

template​ <fixed_string Pattern>  
  requires Correct_Regex_Syntax<Pattern>  
  [[reason_not_used("invalid regex syntax")]]
bool​ match(string_view sv);

When this attribute is placed on a function, the diagnostic messagewould be used when:

• The function was considered and rejected as a candidate for a function call, for any reason (deduction/substitution failure,requires clause constraint failure, no suitable conversion, etc).
• The function call found no matching overload and thus lead to a compilation failure.

Today, when a function call fails to find a match, C++ compilers typically print out a list of all the candidates considered. We envision this new attribute as being additive to existing diagnostics, in the same way that static_assert​’s diagnostic message is.

[...]

Future Directions

This attribute could also potentially be used on class and aliastemplates to provide custom diagnostic messages for constraintfailures and when selecting a specialization (in the case of classtemplates):

template​ <​typename​ T>  
  requires FloatingPoint<T> || Integral<T>  
  [[reason_not_used("the element type must be numeric")]]
struct​ matrix {};

matrix<string> a;

#:#:​error: ​template constraint failure 
matrix<string​>​ a;​
             ^
#:#:​note: ​constraints not satisfied: ​the element type must be numeric
#:#:​note: ​within ...

This attribute could also be attached to concept definitions, and usedwhenever checking that concept’s constraints fails.

它的听众是Evolution工作组(EWG)，据@DavisHerring(C++委员会成员)称，尽管未在外部发表，但遭到拒绝:

@DavisHerring:

[...] that paper was considered in 2018 and “rejected”—that is, new information (like “It’s 2021 and in practice concept error messages are still bad”) would be needed to consider it again.

Recently, papers have been given very brief public statuses; for older papers like this one, the references are unfortunately internal.

但是，很可能是受此StackOverflow问题与解答的启发，该主题已在 r/cpp上复活，作为线程 Custom 'diagnostics' for concepts，讨论了用于概念的自定义诊断的另一种更简单的方法[ 强调我的]

Custom 'diagnostics' for concepts

I'd like to 'propose' the following simple attribute for concepts:

template <typename T> [[requirement_failed("reason")]]
concept MyConcept = /*some expression*/;

template<typename T>
concept MyConcept2 = requires(T t) {    
    /*some expression*/;
} [[requirement_failed("reason")]];

The purpose should be quite obvious: "reason" is issued as a compilernote, when the requirements are not met.

Notes:

There isP1267R0,but I think it's just not put or presented it in a simple enough way.Allowing the attribute on any definition that 'requires' will likelyresult in a mess.

Allowing it on concept definitions only will keep things clean. Itavoids duplication for various functions making use of the sameconcept. It avoids over-use of the feature, as there should not be anexcessive amount of concepts.

In my view, concepts that are part of an interface should offer'diagnostic' messages as a best practice.

I don't think I have the guts, insight or time to make this into an official proposal, even if it is a very simple thing. So I thought,I'd just mention it here. It's also hard to imagine that somethingsimilar has not been considered yet, by some concepts committee.

Anyway, I wanted to draw some attention to it.

作者明确提到他/她不想继续发表有关该主题的正式论文。如果例如因此，SO Q＆A的OP将此视为一项重要功能，一种方法是将这个主题整理成(重新)形式化的论文。