Mistakes with Rust smart pointers: when Deref goes wrong

Re:Mistakes with Rust smart pointers: when Deref goes wrong by foldr on Monday July 10, 2023 @04:08AM (#36663384)

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.

[ Parent | on HN ]

Re:Mistakes with Rust smart pointers: when Deref goes wrong by ninepoints on Monday July 10, 2023 @05:30AM (#36663939)

And we would expect this behavior why?

[ Parent | on HN ]

Re:Mistakes with Rust smart pointers: when Deref goes wrong by quietbritishjim on Monday July 10, 2023 @05:39AM (#36663988)

If you start with

    void foo(std::string x, int y);
    void foo(const char* x);

Then calls too 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.

[ Parent | on HN ]