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.
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 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
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