템플릿 본문 오류를 concept으로 옮기면 호출자의 진단이 어떻게 달라지나요?

본문에서 data()를 호출하다 실패하면 이미 그 template candidate가 선택된 뒤의 instantiation error가 됩니다. 선언부 constraint로 조건을 옮기면 해당 후보가 먼저 viable set에서 빠지고, 다른 viable overload가 있을 때 그 후보를 선택할 기회가 생깁니다. 다른 후보가 없다면 자동으로 성공하는 것이 아니라 no matching function으로 거절됩니다.

template<class T>
auto bytes(T const& x) { return x.data(); }

template<class T>
requires requires(T const& x) { x.data(); }
auto bytes2(T const& x) { return x.data(); }
void bytes2(...);

bytes(7)은 본문 instantiation 오류가 될 수 있지만, bytes2(7)에서는 constrained overload가 제거되고 ellipsis가 선택됩니다. requires가 모든 오류를 숨기지는 않습니다. 비의존 이름과 문법 오류는 정의 시점에 거절될 수 있고, constraint 자체의 normalization parameter mapping 문제는 좁은 IFNDR 경계가 됩니다. 또한 data()가 존재해도 body가 기대하는 lifetime이나 semantic 조건은 남으므로 concept이 실제 의미 불변식을 자동 검증하지 않습니다.

예를 들어 bytes2(7)의 선언부 검사에서는 int에 data가 없으므로 제약이 false가 됩니다. 이후 ellipsis 후보가 남아 해당 호출이 선택되지만, 예제는 선언만 있으므로 실제 실행하려면 그 함수 정의도 있어야 합니다. 반면 data가 존재하는 타입이어도 선택된 함수 본문이 반환값에 잘못된 연산을 한다면 instantiation 오류가 남습니다. 저는 지원하지 않는 입력의 컴파일 거절, 대체 overload 선택, 본문 내부의 결함을 각각 다른 테스트로 나누겠습니다.