Re:Mistakes with Rust smart pointers: when Deref goes wrong
by IshKebab on Wednesday July 12, 2023 @03:20PM
(#36700274)
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...
Re:Mistakes with Rust smart pointers: when Deref goes wrong
by quietbritishjim on Thursday July 13, 2023 @07:39PM
(#36717569)
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_look...
Re:Mistakes with Rust smart pointers: when Deref goes wrong
by qsdf38100 on Thursday July 13, 2023 @07:58PM
(#36717712)
Yes I’d like to know the answer.
Re:Mistakes with Rust smart pointers: when Deref goes wrong
by ninepoints on Saturday July 15, 2023 @03:58AM
(#36734602)
Sigh. This is entirely expected behavior, and in fact, is _necessary_ behavior. If changing signatures in that way continued to allow code to "compile" with reckless abandon, so many things would break. I think before complaining, you need to understand how general symbol resolution, name mangling, and argument dependent lookup work. And if you're too impatient to learn, you're not actually in a position to criticize.
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.