Date: Tue, 6 Jun 2023 19:42:09 +0200
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.
> 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_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.
> 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
Received on 2023-06-06 17:42:21