Thank you for your comments.

Regarding the first: my use case is compile-time automatic differentiation (AD). I gave a talk on the approach at a London C++ meetup, and at a Euro AD workshop [slides].

The gist of it is that I want to be able to evaluate an expression from its root to its terminals. This is the opposite of what one normally wishes to do, but it just is the nature of the so-called 'adjoint' method of automatic differentiation. Doing this naively, one ends up performing duplicate evaluations when a term is used repeatedly.

Consider the code corresponding to Figure 1 (I now realise I should have included the code snippet in the paper!): the term 'ab' occurs twice in the expression for 'result'. In typical expression evaluation, 'ab' is evaluated once then its result used in many places. However, in back-propagation evaluations (like those found in adjoint automatic differentiation), evaluation begins at 'result' and propagates to the terminals 'a' and 'b'. The problem is that the back-propagation will visit the sub-expression tree for 'ab' twice since it occurs twice upstream.

float c0;
float c1;
auto ab = a * b;
auto result = (c0 + ab) / (c1 + ab);

Regarding the second point: I came across Andrew Sutton's paper, P2237R0, after submitting my own. Whilst skimming it I saw something that may be doing what I am proposing, namely 'meta::location_of(e)', p15 ff. Are the reflection mechanisms you are referring to those mentioned by Andrew in his paper or are you referring to another language proposal? If it is another, I'd be grateful if I could get a link to the paper.

I agree that if there are not sufficiently broad use case examples for my proposal then it does not warrant further consideration; amassing a broad range of use cases is something I still need to work on. (Klaus Iglberger, I believe, has a use case for his math library 'Blaze' which I need to ask him for.) However, presently, I don't know how the same end could be achieved without a top level API function. Early on, I thought it could be by proposing a language extension whereby `address of' in a constexpr context would return a constexpr variable ID, much like what varid would do. However, even with this, a second language change would need to be made, one whereby a constexpr function could return a constexpr result despite taking non-constexpr arguments (i.e. resolving the compilation error presented in Listing 3).

In response to your final comment: unfortunately, only having equality wouldn't do; it would be minimally useful, facilitating expression transformations for only trivial expressions, such as 'c0*c1' or 'c0*c0', but nothing more complicated than that.

Regards,
Dominic


On Mon, 21 Dec 2020 at 19:38, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
On Sun, 20 Dec 2020 at 20:47, Dominic Jones via SG7
<sg7@lists.isocpp.org> wrote:
>
> Hello,
>
> I was wondering if I may submit a language proposal to the SG7 mailing list, please? I have never been involving in library or language proposals (or in any way with ISO C++), so I am not so sure this is the way to go about things.
> I have read the documentation on https://isocpp.org/std/submit-a-proposal , but I have not attended a committee meeting. If this requirement presently stands, may I find out how to attend the next meeting, please?

Well, howdy, welcome.

If you're in UK, perhaps Roger Orr (cc:ed) could help with the
mechanics of attendance? Study group attendance
doesn't require the full mechanics, though - study groups can have any
interested experts attend.

Some questions (not criticisms, just questions) about the proposal:

1) I'm still a bit baffled how this would be used, I mean in code. Do
you have any more concrete examples of where this
facility is important to have?

2) I would remotely-vaguely think that it might be possible to get
this information via the reflection of a variable. If you
have that reflection, you can check the name and the scope of a
variable - if those are the same, you have the same
variable. I don't know whether our proposed reflection APIs have any
particular "reflects the same entity" mechanism,
but perhaps that would be worth looking at or thinking about. Having
the identifier be a top-level API function is.. ..a
bit puzzling to me, because I wouldn't expect this to be all _that_
common use of compile-time information?

One of the reasons I ruminate about (2) is that I don't fully grasp
(1). If all you need is equality, that may be already
doable, or can easily fit into the existing APIs. If you have more
needs for the id than just (in)equality with other entities,
then the picture may change. May. May not.