On Tue, Nov 15, 2022 at 12:42 PM Anoop Rana <ranaanoop986_at_[hidden]> wrote:

> template<class... Ts, class... Us> void f();
>> f<int,int>();
>>
>> is actually accepted today by both GCC and Clang (deducing Ts={int,int},
>> Us={}).
>> MSVC rejects the template declaration of `f` itself (even before it's
>> ever called) with a hard error. I think MSVC's behavior is what the
>> Standard strictly requires.
>>
>
> Yes, msvc is correct(as per current wording) in rejecting the program as
> also answered on this stackoverflow answer
> <https://stackoverflow.com/a/73279832/12002570>.
>
> And ideally you'd be saying "Let's change the rules to *the thing that
>> 2/3 of vendors already do*" (i.e., "standardize existing practice"). I
>> don't think that's actually what you're saying, *but, maybe it should be*
>> ?
>>
>
> Yes, that is exactly what point *1) *in my previous email offers.
>

Well, sort of. You describe (1) as "making packs greedy," i.e. you want to
make
    template<class... Ts, class... Us> void f(); f<int, int>(); // OK
with Ts={int,int}, Us={}
But you're actually proposing to make packs less greedy; that is, you want
to also make
    template<class... Ts, int... Us> void f(); f<int, 42>(); // OK with
Ts={int}, Us={42}
as opposed to (one way a student could interpret) what GCC and Clang do
today, which is that the first pack greedily chomps *all* the template
arguments and then you get a kind-mismatch error because Ts={int,42} is not
a pack of types.
AIUI, you're not proposing to standardize what GCC and Clang actually do
today; those compilers will have to change their behavior to make their
packs "less greedy," so that `class... Ts` stops chomping as soon as it
sees a template argument that can't be interpreted as a type.

That sentence makes me worry that this proposal might interact with C++20's
"Down with typename". Fortunately I don't think it does, because the
highlighted context below is not a *type-id-only context*.

    template<class T> struct F11;
    template<class R> auto test() -> F11<R::member>* { return nullptr; }
    struct A { using member = int; };
    struct B { static constexpr int member = 42; };
    int main() {
      test<A>(); // currently ill-formed, but I wonder if it'll be that
way forever
      test<B>(); // definitely ill-formed
    }

Now imagine replacing F11 with F12:
    template<class... Ts, int... Us> struct F12;
You'll want to make sure you know what your proposal is proposing, re the
meaning of `F12<R::member>`.


A procedural note: You've labeled your mailing-list drafts PxxxxR0 and
>> PxxxxR1. You should instead label them DxxxxR0 (draft revision 0) and
>> DxxxxR0 (draft revision 1), and so on.
>>
>
> Okay, so the next revision of my draft will be named "*DxxxxR2*" as 2
> versions(named PxxxxR0 and PxxxxR1) were already mailed here.
>

No, the next revision should be DxxxxR0 (draft revision 2), and you just
deal with the very low cost of having misnamed the first few. :)
The failure modes we're trying to avoid here are:
- Having a file labeled "P1234R5" floating around on the Internet that is
not the actual P1234R5 submitted to WG21. (Thankfully you've avoided this
so far by using "xxxx" in place of a paper number.)
- Submitting the paper for the first time to WG21 with a name like
"P1234R2": everyone will wonder why they can't find any trace of R0 and R1
in old mailings or minutes.

When (if) you submit the paper to an actual mailing, you'll number *that
>> submission* as PxxxxR0, and then start working on new drafts as DxxxxR1
>> (draft revision whatever).
>>
>
> I didn't understand what you meant by "actual mailing". Can you elaborate
> on that. I mean is it different from this and how is it different(if it
> is). I've read how to submit a c++ proposal
> <https://isocpp.org/std/submit-a-proposal> but still have some doubts
> from that page. Not sure if those should be asked in the std-discussion
> mailing list.
>

That page links to
https://isocpp.org/std/standing-documents/sd-7-mailing-procedures-and-how-to-write-papers
<https://isocpp.org/std/standing-documents/sd-7-mailing-procedures-and-how-to-write-papers>
which has more of the WG21-administrivia documentation.
I see how the term "mailing" would be confusing. :)
- There's this mailing list (*std-proposals*), which basically nobody on
the Committee reads.
- There's the actual members-only WG21 mailing lists, usually referred to
as the "*reflectors*" ("the CWG reflector, the LEWG reflector," etc).
- And then there's the periodic *mailing*, i.e. the collection of papers to
be discussed at meetings. It used to come out only before and after each
in-person meeting (~3x/year); post-pandemic I believe it comes out monthly
regardless of the meeting schedule. This year's mailings are collected
here: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/ (and so on,
for previous years). To get a paper into the mailing, you talk to Hal
Finkel per the above vague guidance. AFAIK, this will necessarily be a
manual process that starts with an awkward email; but once you're
bootstrapped into the system (the criteria and process for which I don't
know), you will be able to submit and update your papers directly via a web
form on isocpp.org.

(Btw, I certainly have the ability to submit your paper to the system on
your behalf, but I'm not sure it's kosher for me to do that without
designating myself as a coauthor, and typically a coauthor should be in
*favor* of the proposal, not opposed to it. ;) Maybe someone else who's
more in favor of this proposal is watching and will speak up to help out.
But anyway, it can't hurt for you to read the above guidance and email Hal.)

Cheers,
Arthur

>