Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mistakes with Rust smart pointers: when Deref goes wrong

fuzzypixelz.com

Post reply on HN
Print view View original

61–64 of 64 posts

Re: Mistakes with Rust smart pointers: when Deref goes wrong

#61

Post by IshKebab »

qsdf38100 wrote: post #54
IshKebab wrote: post #52

Earlier quoted context omitted.

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.

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

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

#62

Post by quietbritishjim »

IshKebab wrote: post #61
qsdf38100 wrote: post #54

Earlier quoted context omitted.

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

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

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

#63

Post by qsdf38100 »

IshKebab wrote: post #61
qsdf38100 wrote: post #54

Earlier quoted context omitted.

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

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

Yes I’d like to know the answer.

Re: Mistakes with Rust smart pointers: when Deref goes wrong

#64

Post by ninepoints »

IshKebab wrote: post #61
qsdf38100 wrote: post #54

Earlier quoted context omitted.

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

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

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.
Post reply on HN