I think Dominic’s proposal is not quite covered by other reflection facilities/proposed reflection facilities (except to the extent full expression reflection obviates the need for what he proposes), but also the proposal needs to be tweaked.

Consider the key example from the paper:

```
template<typename OP, typename E0, typename E1, auto ID0, auto ID1>
struct Binary { …} ;

template <typename E0, typename E1>
auto add(E0 &&e0, E1 && e1)
-> Binary<Add, E0, E1, varid(e0), varid(e1) {}

Binary<Add, C, Binary<Mul, A, B, 1, 2>, 3, 5> // c0 + a*b
Binary<Add, C, Binary<Mul, A, B, 1, 2>, 4, 5> // c1 + a*b
```

The key issue in the above is that varid needs to accept not just identifiers, but temporaries. (I.e. varible #5 in the above corresponds to the result of "a*b" — and critically, it must be #5 in *every* case in which a*b is referenced).

However, this could still be done — but a better term for what you want might be `exprid(expr)`, where expr could be any expression. The implementation would be a simple hash of the underlying AST expression node, with any referenced declaration or subexpression AST pointers included in the hash. The output would be an integer. Another thing you’d need, you would need to be able to delay the exprid(expr) until instantiation — i.e you don’t want the varid/exprid for e0, but rather whatever replaces it.

Both would be possible, even simple to implement, and could well have some utility. (Indeed I’ve wondered for awhile if module-like facilities could use AST node hashes to keep track of what particular nodes have been previously compiled, instead of only reasoning about full files…but that’s another matter.)

Dave

> On Jan 28, 2021, at 7:50 AM, Hana Dusíková via SG7 <sg7_at_[hidden]> wrote:
>
> What's the paper number? I would like to see previous version too.
>
> Any paper is welcome, and I will try to schedule discussion for it. Looking at your paper it seems to me, it similar as a reflection over expression, I think you should be able to do same thing without any new language facility other than future reflection.
>
> Hana
>
>> On 28. 1. 2021, at 13:46, Dominic Jones via SG7 <sg7_at_[hidden] <mailto:sg7_at_[hidden]>> wrote:
>>
>> Hello Hana,
>>
>> I was wondering if I may submit a revised paper (R1) to the SG7 discussion group about the `varid' proposal I made late last year, please? Attached is the revision.
>>
>> The revision includes:
>> - clearer explanation of the problem
>> - further considerations on workarounds
>> - corrections in the specification
>> - revision to the proposed implementation
>> - reference to Andrew Sutton's proposal in P2237R0, p. 15
>>
>> Many thanks,
>> Dominic
>> <sg7_varid_R1.pdf>--
>> SG7 mailing list
>> SG7_at_[hidden] <mailto:SG7_at_[hidden]>
>> https://lists.isocpp.org/mailman/listinfo.cgi/sg7
>
> --
> SG7 mailing list
> SG7_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg7