[over.best.ics.general] The type of parameter is unclear

[xmh0511]

[over.best.ics.general] p1 says

An implicit conversion sequence is a sequence of conversions used to convert an argument in a function call to the type of the corresponding parameter of the function being called.

[over.best.ics.general] p6 says

When the parameter type is not a reference, the implicit conversion sequence models a copy-initialization of the parameter from the argument expression. The implicit conversion sequence is the one required to convert the argument expression to a prvalue of the type of the parameter.

Consider this example:

void fun(int a()){
}
fun(0);

Is the type of the parameter a be considered as function of () returning int or "pointer to function of () returning int" that is after adjustment?

Since [dcl.fct.note] p3 says

This transformation does not affect the types of the parameters.

The parameter-declaration int a() matches [dl.fct] and thus it's original type is function type. Does the type of the parameter mean the type of the parameter in parameter-type-list? Such as

void fun(int a(), int const b){}
fun(0,0);

For the purpose of defining implicit conversion sequence, the type of a and b are pointer to function of () returning int and int, respectively.

BTW, the adjustment for the types of parameters that is "array of T" or "function type T" does not only affect parameter-type-list but also affect the type when determining the type of the entity, such as the result of decltype(a) is pointer to function of () returning int rather than function of () returning int but decltype(b) is exactly const int. [dcl.fct] p5 may need to be improved to make that meaning clear.

After determining the type of each parameter, any parameter of type “array of T” or of function type T is adjusted to be “pointer to T”. After producing the list of parameter types, any top-level cv-qualifiers modifying a parameter type are deleted when forming the function type. The resulting list of transformed parameter types and the presence or absence of the ellipsis or a function parameter pack is the function's parameter-type-list.

This sounds like all transformations only affect the determination of the function's parameter-type-list.

[jensmaurer]

Putting two entirely different topics into the same issue is unhelpful; please split.

Regarding the first issue, this is probably CWG1668. In particular, "This transformation does not affect the types of the parameters." wants to say "does not affect the types of the parameter variables."

In your example, the parameter type (both as appearing in the function type and as the type of the parameter variable) is "pointer to function".

[xmh0511]

Regarding the first issue, this is probably CWG1668.

Yes, we agree that the type of the parameter is a bit unclear when it refers to in different contexts.

In your example, the parameter type (both as appearing in the function type and as the type of the parameter variable) is "pointer to function".

A different perspective to CWG1668 is that this issue is talking about the type of the parameter from the view of the declaration. [basic.pre] p5 says

Every name is introduced by a declaration, which is a

• [...]
• parameter-declaration ([dcl.fct]),

An entity E is denoted by the name (if any) that is introduced by a declaration of E ...

Anyway, the parameter-declaration int a() and int arr[2] matches [dcl.fct] and [dcl.array] in terms of their grammar. That is, the former is a declaration that declares a function, and the latter is a declaration that declares an array. decltype(a) and decltype(arr) should be function type and array, as per [dcl.type.decltype] p1.3. However, the intent is the former should be pointer to function type and the latter should be pointer to the element's type. So, we should clearly state the transformation

After determining the type of each parameter, any parameter of type “array of T” or of function type T is adjusted to be “pointer to T”.

should also affect the type of the parameter whenever the determination of the type of such a parameter is required. Furthermore, we should also clearly state what the type of a parameter is when the type is used in overload resolution(i.e. the type of the parameter or the type of the parameter in the function type).

---

Putting two entirely different topics into the same issue is unhelpful; please split.

I have done that. Please check it.