> 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]>
wrote:

> On Tue, 22 Dec 2020 at 01:43, Ville Voutilainen
> <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?
>