-
Notifications
You must be signed in to change notification settings - Fork 7
Description
Similar to parameter name reflection, we face issues with parameter names being inconsistent across declarations, possibly between TUs. We should take the same approach as parameter name reflection, which is enforced consistency.
Furthermore, when inconsistency is spotted, this should presumably not be SFINAE-friendly because that may result in inconsistent overloads being chosen:
// a.cpp
void f(int x); // included from header
void f(double x); // included from header
f(.x = 0); // OK, calls f(int)
// b.cpp
void f(int x); // included from header
void f(double x); // included from header
void f(int val) { /* ... */ }
f(.x = 0); // OK, but calls f(double)In this example, if f(int) is merely disqualified, f(.x = 0) would give us inconsistent behavior between a.cpp and b.cpp, so my intuition is that a call with named arguments to an overload set that contains any overloads with inconsistent parameter names should be ill-formed, regardless of candidate viability. However, that could also backfire because a lot of trash can get pulled in via ADL from std, and the standard library does not generally have consistent parameter names.
Metadata
Metadata
Assignees
Labels
Projects
Status
Status