3

I'm learning C++ concepts, and trying to realize why the following does not compile (it's just a trivial and meaningless example demonstrating the point; tested with GCC-11.1):

#include <iostream>

struct non_negatable {
};

template <class T>
auto negate(T a) {
    return -a;
}

template <class T>
concept is_negatable = requires(T t) {
    //just `-a;` would do the job of course
    negate(t);
};

template <class T>
auto do_negate(T) {
    std::cout << "here we are\n";
}

template <is_negatable T>
auto do_negate(T t) {
    return negate(t);
}

int main() {
    non_negatable x;
    do_negate(x);
}

The above concept attempts to call a function template, whose implementation would not compile. This fact causes a "hard error", rather than failing the concept.

I guess it works this way because the concept requirements may be failed only by the expressions' "immediate context" ill-formness (like what we could observe with SFINAE).

Is my understanding correct? Where does the Standard describe this point? Is there a way to "fail" a concept based on a function template implementation ill-formness?

Igor R.
  • 14,716
  • 2
  • 49
  • 83
  • 1
    "*Is there a way to "fail" a concept based on a function template implementation ill-formness?*" I'm afraid not, don't you think the overhead is too heavy if the compiler needs to check the specific implementation of the function? – 康桓瑋 Feb 01 '22 at 12:27
  • In addition, definition might not be visible... – Jarod42 Feb 01 '22 at 12:31
  • @Jarod42 shouldn't all the specializations of that template be available at the instantiation point of the concept? – Igor R. Feb 01 '22 at 12:39
  • 1
    Explicit instantiation might be done elsewhere. declaration should indeed be visible for concept, (and it is currently sufficient). – Jarod42 Feb 01 '22 at 12:47
  • @康桓瑋 @Jarod42 but it *does* compile the definition from within the concept `requires` (take a look at the error messages "stack"), it just generates a hard-error, instead of failing the concept. The following requirement still generates hard error: `std::declval() + t;` – Igor R. Feb 01 '22 at 14:08
  • Maybe you should constrain `negate` for [starters](https://godbolt.org/z/d7e8csnn1). – Bob__ Feb 01 '22 at 14:50
  • I though the concept won't instantiate the function (but it seems it would [Demo](https://godbolt.org/z/MMabTvnTj)) and just succeeds (as from declaration `negate(std::declval())` is valid). – Jarod42 Feb 01 '22 at 16:20

1 Answers1

2

Firstly, as you referred, negate<non_negatable> is not a substitution failure since the error is not in the immediate context of the function, as such it's ill-formed. From 13.10.3.1/8 of C++20 standard:

If a substitution results in an invalid type or expression, type deduction fails.

An invalid type or expression is one that would be ill-formed, with a diagnostic required, if written using the substituted arguments.

[Note 4: If no diagnostic is required, the program is still ill-formed. Access checking is done as part of the substitution process. — end note]

Only invalid types and expressions in the immediate context of the function type, its template parameter types, and its explicit-specifier can result in a deduction failure.

[Note 5: The substitution into types and expressions can result in effects such as the instantiation of class template specializations and/or function template specializations, the generation of implicitly-defined functions, etc. Such effects are not in the “immediate context” and can result in the program being ill-formed. — end note]

Secondly, 7.5.7.1/6 says:

[...]

[Note 1: If a requires-expression contains invalid types or expressions in its requirements, and it does not appear within the declaration of a templated entity, then the program is ill-formed. — end note]

[...]

So, your understanding seems correct to me. However, what you're asking in your last question boils down to whether there is a way to make an invalid expression in a template function body cause a substitution failure instead of an ill-formed program. I don't think it's possible.

ofo
  • 1,160
  • 10
  • 21