4 ms·

What does this comment mean? Function parameters used or not are part of the function signature, so obviously would participate in any form of argument dependen

What does this comment mean? Function parameters used or not are part of the function signature, so obviously would participate in any form of argument dependent lookup.

codeflo 3y ago
I mean, you can do as small a change as adding a const somewhere, and cause an (almost) independent file somewhere else in your codebase to hit the wrong overload.
foldr 3y ago
Perhaps a case where after removing the unused parameter and updating all the call sites, none of the calls resolve to the original function anymore.
- ninepoints 3y ago
  And we would expect this behavior why?
  - quietbritishjim 3y ago
    If you start with void foo(std::string x, int y); void foo(const char* x); Then calls to foo("bar", 0) would resolve to the first overload: the second isn't a match at all, but the first is a match with an implicit conversion from const char* to std::string. But if you removed the second parameter, including arguments at all call sites, then foo("bar") would match the second better because it doesn't involve any conversions, so it would be selected instead of the first.
quietbritishjim 3y ago
Perhaps the argument had a default value so call sites didn't need to mention it. Although I can't think of removing an argument with a default value would change its priority in the overload set. But I definitely don't know all the rules so I can believe that it could!
IshKebab 3y ago
There was an argument that was not used by the function implementation. I removed it from the signature entirely - at the definition and the call sites. Boom. No longer compiles. Yes I understand the complex and surprising rules that cause this to happen. That doesn't make them any less complex and surprising.
- qsdf38100 3y ago
  "not used by the function implementation" doesn't mean "not passed in by callers". The callers won't find a matching signature once there is 1 less parameter. I don't see what is confusing about it. You probably misunderstood that warning as "No callers pass this parameter", which btw would only make sense for a parameter with a default value.
  - IshKebab 3y ago
    I removed the parameter from the definition and call sites. I went from void foo(A a, B b) { // Only use a } ... foo(x, y); To this void foo(A a) { // Only use a } ... foo(x); And it stopped compiling. There were no other functions called `foo` so it is nothing to do with overloading. I'll give you the answer if you want or we can leave it a mystery so you can experience how confusing that behaviour is...
    - quietbritishjim 3y ago
      All I can think of is Koenig lookup [1]: B and foo were defined in a namespace, and the calls to foo were not in that namespace and didn't explicitly qualify foo but still found it. [1] https://en.m.wikipedia.org/wiki/Argument-dependent_name_lookup https://en.m.wikipedia.org/wiki/Argument-dependent_name_look...
    - qsdf38100 3y ago
      Yes I’d like to know the answer.
    - ninepoints 3y ago

What does this comment mean? Function parameters used or not are part of the function signature, so obviously would participate in any form of argument dependent lookup.

codeflo 3y ago

I mean, you can do as small a change as adding a const somewhere, and cause an (almost) independent file somewhere else in your codebase to hit the wrong overload.

foldr 3y ago

Perhaps a case where after removing the unused parameter and updating all the call sites, none of the calls resolve to the original function anymore.

ninepoints 3y ago
And we would expect this behavior why?
- quietbritishjim 3y ago
  If you start with void foo(std::string x, int y); void foo(const char* x); Then calls to foo("bar", 0) would resolve to the first overload: the second isn't a match at all, but the first is a match with an implicit conversion from const char* to std::string. But if you removed the second parameter, including arguments at all call sites, then foo("bar") would match the second better because it doesn't involve any conversions, so it would be selected instead of the first.

quietbritishjim 3y ago

Perhaps the argument had a default value so call sites didn't need to mention it. Although I can't think of removing an argument with a default value would change its priority in the overload set. But I definitely don't know all the rules so I can believe that it could!

IshKebab 3y ago

There was an argument that was not used by the function implementation. I removed it from the signature entirely - at the definition and the call sites. Boom. No longer compiles. Yes I understand the complex and surprising rules that cause this to happen. That doesn't make them any less complex and surprising.

qsdf38100 3y ago
"not used by the function implementation" doesn't mean "not passed in by callers". The callers won't find a matching signature once there is 1 less parameter. I don't see what is confusing about it. You probably misunderstood that warning as "No callers pass this parameter", which btw would only make sense for a parameter with a default value.
- IshKebab 3y ago
  I removed the parameter from the definition and call sites. I went from void foo(A a, B b) { // Only use a } ... foo(x, y); To this void foo(A a) { // Only use a } ... foo(x); And it stopped compiling. There were no other functions called `foo` so it is nothing to do with overloading. I'll give you the answer if you want or we can leave it a mystery so you can experience how confusing that behaviour is...
  - quietbritishjim 3y ago
    All I can think of is Koenig lookup [1]: B and foo were defined in a namespace, and the calls to foo were not in that namespace and didn't explicitly qualify foo but still found it. [1] https://en.m.wikipedia.org/wiki/Argument-dependent_name_lookup https://en.m.wikipedia.org/wiki/Argument-dependent_name_look...
  - qsdf38100 3y ago
    Yes I’d like to know the answer.
  - ninepoints 3y ago