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!. 