[SymbolKit] Proposal to Support C++ Templates

Hi! I'm Erick, a GSoC contributor for LLVM this summer. I am working on C++ support for clang's ExtractAPI, which can serialize codebases into Symbol Graph files. It currently supports Objective-C and C.

I would like to propose modifications to SymbolKit to allow C++ templates to be represented in Symbol Graph format. I believe the existing components for SwiftGenerics would only require a few changes to allow templates to be compatible.

Examples and Context

Generic conformance in C++ is simple enough:

template <typename T> void foo(T x) requires std::is_integral<T>::value;

Here, T must conform to is_integral::value. There do exist disjunctive constraints which only require one constraint to be satisfied.

template <typename T> void foo(T x) requires std::is_integral<T>::value || std::is_floating_point<T>::value;

This can be considered conditional conformance because this expression short circuits. This might warrant a new enum value for SwiftGenericConstraint::Kind to denote conditional conformance.

Constraints can also be composed and named as concepts, making them reusable.

template <typename T> concept Numeric = std::is_integral<T>::value || std::is_floating_point<T>::value;

template<typename T> concept SignedNumeric = Numeric<T> && std::is_signed<T>::value;

template <SignedNumeric T> void foo(T x)

I believe concepts can be easily distinguished with an optional Name field in SwiftGenericConstraint. If the constraint does not have a name, then it is part of a requires expression.

SwiftGenericConstraint::rhs and lhs fields might fall apart for a requires expression within a declaration, since there is no clear left-hand or right-hand side. Generic parameters also require a type name, which is either typename, class, or a concept name, so I would suggest an optional field Type in SwiftGenericParameter.

I would also like to suggest removing "Swift" from these generic components for better inter-language use and readability.

Summary of Proposed Changes

  • A nullable string field “Name” in SwiftGenericConstraint to denote a concept.
  • Possibly a new enum SwiftGenericConstraint::Kind to denote conditional conformance, as disjunctive constraints short circuit.
  • Consider SwiftGenericConstraint::lhs,rhs to be nullable.
  • A nullable string field “Type” in SwiftGenericParameter to denote the parameter’s type.
  • Possibly remove “Swift” from the name of components for generics.

Thank you for reading and please share any feedback on my proposed changes, or if more clarification is needed!. :grin: