C++ Logo

std-proposals

Advanced search

Re: Pack of functions - amendment to P1858

From: Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
Date: Thu, 10 Sep 2020 10:19:39 -0400
On Thu, Sep 10, 2020 at 9:52 AM Fabio Alemagna <falemagn_at_[hidden]> wrote:

> Il giorno gio 10 set 2020 alle ore 15:20 Arthur O'Dwyer via Std-Proposals <
> std-proposals_at_[hidden]> ha scritto:
>
>>
>> Interesting idea, but it puts the '...' much too inconspicuously for my
>> liking. The compiler would have to parse the entire function body before
>> it'd be able to diagnose a missing '...' in the signature!
>>
>
> I thought of that, but then again the same "issue" exists for lambdas as
> well.
>
> template <typename... T>
> std::any *test()
> {
> static std::any array[] = {
> [](T){ /* possibly very long body */}...
> };
>
>
Okay, fair.
My only rebuttals there are
- technically a lambda expression is not a declaration (but why should this
matter?), and
- people who use this idiom are incentivized to keep the lambda body as
short as possible (but I suppose the same would be true of the idiom you
propose).
As far as the parser is concerned, you're correct — this is a case where
the missing '...' can't be diagnosed until arbitrary far after it was
supposed to appear. And in practice, GCC and Clang handle this fine; if
they get to the end of the expression and still have unexpanded packs, they
simply diagnose the *very first place* that the pack appeared unexpanded,
which is *usually *the place where the programmer meant to expand it.

Weirdly, both GCC and Clang do* really awful* when the unexpanded pack
appears in a braced initializer as in your example above:
https://godbolt.org/z/9KK7d1

–Arthur

Received on 2020-09-10 09:23:20