Mistakes with Rust smart pointers: when Deref goes wrong

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...

[ Parent | on HN ]

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...

[ Parent | on HN ]

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.

[ Parent | on HN ]

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.

[ Parent | on HN ]