The contributor guidelines state that template parameter names should use the format ScalarT, but this is the same as the public interface types defined in classes. This presents a problem in that the set of public interface types is incomplete (or must be made inconsistent in order to have access to template parameters).
For example, with types in the Evaluator tree, ScalarT and IdxT are template parameters and accessible only within the type. But RealT is available as part of the public interface. So, say I have another class that takes a model type as a template parameter (expecting it to inherit from Evaluator), I can access RealT but not ScalarT or IdxT...
template <typename ModelT>
class Foo
{
// this is fine
using RealT = typename ModelT::RealT;
// this is an error; IdxT isn't part of the interface (but intuitively it should be)
using IdxT = typename ModelT::IdxT;
};
You can see the problem looking at the structs in the enzyme work (DfDy shouldn't need its last two template parameters).
One can work around this problem by using a traits type (although one would have to break the rules for that type), but I think we could solve the problem with a simple set of rules.
- Use a different style for template type parameters (say...
TScalar ... doesn't matter to me)
- Use the current standard for class member type aliases
- Always define aliases for template parameters and use the alias everywhere instead of the template parameter.
For example:
template <typename TScalar, typename TIdx>
class Evaluator
{
public:
using ScalarT = TScalar;
using IdxT = TIdx;
using RealT = typename GridKit::ScalarTraits<ScalarT>::RealT;
//...
};
The contributor guidelines state that template parameter names should use the format
ScalarT, but this is the same as the public interface types defined in classes. This presents a problem in that the set of public interface types is incomplete (or must be made inconsistent in order to have access to template parameters).For example, with types in the
Evaluatortree,ScalarTandIdxTare template parameters and accessible only within the type. ButRealTis available as part of the public interface. So, say I have another class that takes a model type as a template parameter (expecting it to inherit fromEvaluator), I can accessRealTbut notScalarTorIdxT...You can see the problem looking at the structs in the enzyme work (
DfDyshouldn't need its last two template parameters).One can work around this problem by using a traits type (although one would have to break the rules for that type), but I think we could solve the problem with a simple set of rules.
TScalar... doesn't matter to me)For example: