Non-trailing function template parameter pack

[flint badger]

Could you walk me through the exact paragraphs of [temp] that are involved in the logic under which double binds to Pack, while T is deduced to int in the following example?

#include <type_traits>

template <typename... Pack, typename T>
T foo(T arg);

static_assert(std::is_same_v<
    decltype(foo<double>(42)),
    int
>);

I do intuitively understand why it is the way it is, and not any other (like Pack=[], T=double or the program being ill-formed), yet I didn't manage to find a satisfying explanation in the standard. Never took the time to read the entire thing, so I'm probably just looking at the wrong place.

[low pecan]

When your question is answered use !solved to mark the question as resolved.

Remember to ask specific questions, provide necessary details, and reduce your question to its simplest form. For tips on how to ask a good question run !howto ask.

[dusk stratus]

https://eel.is/c++draft/temp#param-14

...
A template parameter pack of a function template shall not be followed by another template parameter unless that template parameter can be deduced from the parameter-type-list ([dcl.fct]) of the function template or has a default argument ([temp.deduct]). A template parameter of a deduction guide template ([temp.deduct.guide]) that does not have a default argument shall be deducible from the parameter-type-list of the deduction guide template.
here is something I found from a cursory search

there is an example provided with the paragraph and GCC seems to only reject the first definition

[flint badger]

How do we know that T is in fact deduced from arg and not explicitly overridden by specifying <double>? We need some kind of rule that forces parameter packs to be "greedy", so that double can never be bound to T.

[flint badger]

bump

[dusk stratus]

how about https://eel.is/c++draft/temp#arg.general-2

[flint badger]

What do you think about this one? https://eel.is/c++draft/temp#deduct.type-9.sentence-3
Not sure if I understood the notion of <T> there correctly though, in which case it might not be applicable to the case in question

[dusk stratus]

I think this is describing overload resolution

at least that seems to be what is described by the example below

[compact ice]

because the template-parameter Pack precedes the template-parameter T in the template-parameter-list. and, thus, any explicitly specified type template-arguments are eaten up by the pack.

https://eel.is/c++draft/temp.arg.general#1.sentence-3

[flint badger]

it will correspond to zero or more template-arguments
it's not stated in this paragraph, to which (and how many) template-arguments the template parameter pack corresponds

[compact ice]

well, I guess that follows from here https://eel.is/c++draft/temp.arg.general#2

[flint badger]

what do they mean by "template argument is a pack expansion"?
template argument in this case is double, right? doesn't exactly shout a pack expansion to me

[compact ice]

also this https://eel.is/c++draft/temp.arg.explicit#6

[flint badger]

yeah, i've seen this one, but it still doesn't explain why "any explicitly specified type template-arguments are eaten up by the pack"

[compact ice]

because these arguments correspond to the Pack parameter, and the Pack parameter corresponds to zero or more arguments.

[flint badger]

why do they correspond to the Pack parameter?

[compact ice]

because that's what "correspond" means?

like, I agree that this wording is convoluted af, but I mean, it's quite obvious what the intention is there, no?

[flint badger]

so is it that greediness is implicitly implied by "zero or more", and it should instead be something like "as many as possible"?

[compact ice]

I'm not sure why that would be necessary

there's also https://eel.is/c++draft/temp.arg.explicit#4.sentence-1

[flint badger]

could you also elaborate on this? if you don't mind

[flint badger]

it's not clear if it is in fact omitted though, as long as we are not set on parameter packs "eating up" template arguments

[flint badger]

it's quite obvious what the intention is there, no?
if you read between the lines, yes, but it's not clear what to reference

[compact ice]

forget that, that's actually about something completely different

[compact ice]

agreed

it does indeed seem like this has fallen through the cracks

feel free to open an editorial issue I guess ^^

the whole wording around temple stuff is generally mightily convoluted and confusing

I bet if you open the issue, they'll explain to you how it's implied by some crazy inference chain that contains seemingly unrelated stuff from all over the place ^^

I mean, maybe @vocal tiger has an idea

to me, it seems that that's indeed missing

[vocal tiger]

https://eel.is/c++draft/temp.deduct.type#9.sentence-3 perhaps?

(more generally, even for explicitly provide template parameters the actual rules for determining what goes where is still considered deduction, see https://eel.is/c++draft/temp.deduct.general#2, so even if the the thing I found quickly above is not right this should still probably the appropriate section to find that wording)

But it's hard to look on my phone so I'll need to do a proper read-through later 😛

[flint badger]

that's exactly the same sentence I've referenced earlier btw

[vocal tiger]

I didn't read the whole discussion 🙂

But yes, I tentatively agree

(or concur, it seems)

[compact ice]

I don't think this applies here? we're not deducing arguments from a type I think?

[compact ice]

yeah, I remember running across that one, but dunno

[vocal tiger]

A function is a type https://eel.is/c++draft/temp.deduct.type#3.1

(call deduction has a bunch of other forward references to this section too)

[compact ice]

yeah but I'm not sure how this applies here. the pack in question doesn't even appear in the type of the function.

@flint badger maybe consider asking this over on #include too ^^

I'd be curious what some of the experts over there could add