1. Visitors for parse trees / ASTs tend to have a few dozen alternatives, so having separate functions is necessary.

2. The visitors are re-used for different variants (e.g. you'd simplify the node and then it's children recursively). So one needs a mechanism to update the stored reference to a variant. This is error-prone - there are many recursive calls, and one may forget to update the stored variant and call a visitor on another variant, reaching an inconsistent state where the alternative does not correspond to the captured variant.

 3. Solution with a new visit-function that provides the variant itself as a parameter to the visitor seems acceptable - but looks more complicated than what I proposed?

Victor.



> -----Original Message-----
> From: Ville Voutilainen <ville.voutilainen_at_gmail.com>
> Sent: Friday, August 21, 2020 3:22 PM
> To: Victor Khomenko <victor.khomenko_at_[hidden]le.ac.uk>
> Cc: std-discussion_at_[hidden]
> Subject: Re: [std-discussion] std::variant - going from Alternative& to the
> enclosing variant&
>
> ⚠ External sender. Take care when opening links or attachments. Do not
> provide your login details.
>
> On Fri, 21 Aug 2020 at 17:17, Victor Khomenko
> <victor.khomenko_at_[hidden]e.ac.uk> wrote:
> >
> > Thanks Ville,
> >
> > >Use a lambda as a visitor and capture the variant in the lambda?
> >
> > This won't work if the visitor requires very different processing for different
> Alternatives. My proposed workaround with a pointer in a visitor is similar to
> what you suggest, but your solution is restricted to the case when a single
> lambda can handle every alternative.
>
> A single lambda can handle every alternative. You can do an if-constexpr in a
> polymorphic lambda, and handle different cases in any way you please.
>
> If you want different functions for different alternatives, write a function
> object that provides access to the variant.
>
> I suppose we could add a new visit-function that provides the variant itself
> as a parameter to the visitor. I'm not entirely sure whether that's necessary,
> because the work-arounds are not that complicated to write.