ORNL / ORNL/GridKit

Use different style for template parameters and public interface types

Open
#366 3 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C++
Stars
27
Forks
11
Avg merge
3d 8h
Merged PRs (30d)
23

Description

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.

  1. Use a different style for template type parameters (say... TScalar ... doesn't matter to me)
  2. Use the current standard for class member type aliases
  3. 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;
  //...
};

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the contributor guidelines and the Evaluator types described in the issue, then inspect the DfDy structs in the enzyme work. Identify template parameters and public type aliases that follow the same naming style. Done means the naming rules and aliases are applied consistently across the affected interfaces without breaking their intended access.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
backend
Issue type
Refactor
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.