On Tue, 6 Jun 2023 at 12:42, Marcin Jaczewski via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> wt., 6 cze 2023 o 19:25 Jason McKesson via Std-Proposals
> <std-proposals_at_[hidden]> napisał(a):
> >
> > On Tue, Jun 6, 2023 at 1:02 PM Nikl Kelbon via Std-Proposals
> > <std-proposals_at_[hidden]> wrote:
> > >
> > > really no one want describe why visit([](...) {}, value) just compiles
> into undefined behavior? We want to not change THIS behavior in standard?
> >
> > ... did you read what he said? He's saying that there are a lot of
> > possible complications from doing what you're doing, and that you need
> > to figure out what most of those are before any such change can be
> > seriously considered. It's not a defense of the status quo; it's a
> > statement that your suggestion is undercooked.
> >
> > Your response isn't actually responding to the point being made.
> >
> > In any case, I'm not sure I understand your point. The circumstance
> > you're talking about lies at an intersection between a primarily C
> > feature and a C++ construct. Those intersections tend to be where a
> > lot of UB lives.
> >
> > Here's the thing: pretty much nobody uses C-style variadics with
> > variant visitation *on purpose*. If it happens, it happens purely by
> > accident. The user probably meant to do `auto&&...` but made a
> > mistake.
> >
>
> This is not true, some metaprogramming tricks work thanks to `...` and
> overload ordering. It's possible to that in every big project at least one
> time
> this was used on purpose.
>

True, but that's less necessary now that we can use constraints to adjust
overload resolution order (not that such tricks are necessarily any more
readable).

> But this mistake is actually pretty rare. Why? Because in most cases,
> > users want to actually *do something* in that function with the
> > value(s) it is given. So most of them will catch it themselves when
> > they try to fill in `{}` with actual code, since they have no variable
> > name to look at (remember: they did not mean to use C-style
> > variadics).
> >
> > So the only reason this might survive to an actual usage scenario is
> > if this is intended to be a default case. This would commonly be used
> > in something like "overload", a type that is built from a bunch of
> > lambdas to do overload resolution between their `operator()`
> > overloads. Basically, the code would look like this:
> >
> > ```
> > visit(
> > overload{
> > [](int i) {/*do stuff with i*/},
> > [](std::string const& s) {/*do stuff with s*/},
> > [](...) {/*default case. Needs no variable*/}
> > }
> > , value)
> > ```
> > Since it doesn't need a variable name, it's easy to accidentally use
> > `...` instead of `auto&&...`.
> >
> > But this is still *wrong*. We don't want people to use C-style
> > variadics. And the person who wrote this *also* didn't want to use
> > C-style variadics. We don't *want* C++ objects to be slipped into
> > C-style variadics.
> >
> > So the only good solution here is to provoke a compile error on such
> calls.
> > --
> > Std-Proposals mailing list
> > Std-Proposals_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>