The key matter which is one Tony (cc’d) asked about earlier, though I don’t think Dominic was cc’d to the reply, so I’ll raise the issue more generally. Dominic's technical specification says this:
varid takes one argument which must be a named variable or reference and returns the compiler-specific index of the variable, of type std::size t. The operator name would introduce a new keyword into the language. Listing 5 presents valid use cases. In particular, the capacity to ‘trace though’ from a reference to a definition is key requirement. If such functionality were omitted, there would be no way to write expression node construction functions, like the one presented in Listing 4.

```
float c0;

float c1;

static_assert(varid(c0) != varid(c1));

auto &cr = c0;

static assert(varid(cr) == varid(c0));

cr=c1;

static assert(varid(cr) == varid(c1));

```

The need to trace through from a reference to its definition — i.e. the actual numerical content, not just the binding, so that even if a variable is constructed as a copy of another their varids would be the same, at least until one is modified — will be a hard sell, since it would surely create a great deal of overhead: the compiler would probably have to keep track of all `varid`s for all the variables as it goes (since clang, at least, does not by default keep track of the expressions in which a particular variable is modified, and so cannot perform this logic subsequently).

Dominic, particularly given that you probably want a near-term solution, you might want to look at using clang’s static analyzer to do this, since it handles keeping track of these sorts of things (i.e. how variables are modified in a statement, to check which may be nullptrs etc.). Indeed you might want to ask the cfe-dev list about how you might go about doing what you want to do, since the static analyzer folks really do love to talk and help people out; they are probably the most communicative and helpful people on that list.

I’ll also note here that if anyone wants to play around with expression/statement reflection, my old prototype implementation (which used object-oriented reflection) can handle arbitrary expression and statement types, since it simply directly reflects clang AST nodes. E.g.

```
int add(int lhs, int rhs) { return lhs + rhs }
constexpr {
   reflexpr(add) //type is a meta::clang::FunctionDecl*
      ->getBody(); // type is a meta::clang::CompoundStmt, from which you can fetch the meta::clang::ReturnStmt, and then the meta::clang::BinaryOperator, and its children etc.
}
```

The clang AST is a bit messy, and the implementation is unmaintained & buggy, so this is not something that will ever be standard or which you should write serious code for, but it might be helpful for exploring/brainstorming possibilities along these lines. The link: https://github.com/drec357/clang-meta <https://github.com/drec357/clang-meta>.

> On Dec 22, 2020, at 10:42 AM, Dominic Jones via SG7 <sg7_at_[hidden]> wrote:
>
> > So this is basically a missing piece of functionality for expression-template-based solutions for automatic differentiation?
>
> Yes, I would say so. It is the minimum requirement needed for writing an automatic differentiation tool that produces highly efficient object code.
>
> On Tue, 22 Dec 2020 at 00:41, Ville Voutilainen <ville.voutilainen_at_[hidden] <mailto:ville.voutilainen_at_[hidden]>> wrote:
> On Tue, 22 Dec 2020 at 01:43, Ville Voutilainen
> <ville.voutilainen_at_[hidden] <mailto:ville.voutilainen_at_[hidden]>> wrote:
> > 1) What do you use to solve such problems today?
> > 2) Would the introduction of this language facility perhaps, vaguely
> > guessing at a possible answer to (1), to be able to
> > avoid using a compiler-specific solution or a custom parser?
> >
> > A further remark: we are yet fairly far from being able to introspect
> > and analyze function bodies, sequences of statements
> > and expressions, that is. Based on a brief look at the talk this might
> > fall into that bucket that we hope to get at later
> > on, but perhaps there's something about the answer to the question (1)
> > above that makes this more straightforward
> > than full expression/statement-reflection?
>
> Ha, having seen all of the talk, I may have gotten quite a bit ahead
> of things there. So this is basically
> a missing piece of functionality for expression-template-based
> solutions for automatic differentiation?
> --
> SG7 mailing list
> SG7_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg7