That was a good read
Mistakes with Rust smart pointers: when Deref goes wrong
11–20 of 64 posts
Re: Mistakes with Rust smart pointers: when Deref goes wrong
#12Earlier quoted context omitted.
Yes, I've had equally confusing compile errors from C++ due to its lookup rules. For example removing an unused parameter from a function can cause that function not to be found anymore! I'd argue that is more confusing than this Rust issue.
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.
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.
Re: Mistakes with Rust smart pointers: when Deref goes wrong
#13This is very misleading:
str::from_utf8( as Deref>::deref(&self.0))
Re: Mistakes with Rust smart pointers: when Deref goes wrong
#14Earlier quoted context omitted.
Yes, I've had equally confusing compile errors from C++ due to its lookup rules. For example removing an unused parameter from a function can cause that function not to be found anymore! I'd argue that is more confusing than this Rust issue.
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.
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.
Re: Mistakes with Rust smart pointers: when Deref goes wrong
#15I think I've hit the same kind of problem once. What I learned is that true smart pointers are types that (at least in Rust) aren't really supposed to have methods on their own, to avoid this type of ambiguity during method resolution. For example, Box implements Deref so that you can conveniently use T's methods. If you look at the documentation of Box, the things you can do with the Box itself , like Box::leak, are…
This feels analogous to hiding in C++. In C++ by default member functions in a base class don't overload with member functions of the same name in a derived class. They get hidden.
Re: Mistakes with Rust smart pointers: when Deref goes wrong
#16In case the author happens to see this thread – there seems to be a missing less-than sign: str::from_utf8( as Deref>::deref(&self.0)) Thanks for the article! ^_^
You're welcome :)
I finally found out what was going wrong here. All angle brackets and other characters were being escaped in other parts of the document, even in blocks. Except when it came to code blocks inside
For context, I use Zola and Cloudflare pages.
It turns out there is a bug[^0] in Zola 1.40.0 which reads:
> Fix code blocks content not being escaped when not using syntax highlighting
I presume that this is the culprit, as I use an external syntax highlighting library.
Cloudflare Pages has been famously sluggish with updating the Zola version. For reference, 1.14.0 was released in July 2021.
This explains why everything was working fine on my machine™.
Thanks for pointing this out, though I unsure how to work around it without changing my setup.
[^0]: https://github.com/getzola/zola/blob/master/CHANGELOG.md#014...
Re: Mistakes with Rust smart pointers: when Deref goes wrong
#17In case the author happens to see this thread – there seems to be a missing less-than sign: str::from_utf8( as Deref>::deref(&self.0)) Thanks for the article! ^_^
[deleted]
Re: Mistakes with Rust smart pointers: when Deref goes wrong
#18I think I've hit the same kind of problem once. What I learned is that true smart pointers are types that (at least in Rust) aren't really supposed to have methods on their own, to avoid this type of ambiguity during method resolution. For example, Box implements Deref so that you can conveniently use T's methods. If you look at the documentation of Box, the things you can do with the Box itself , like Box::leak, are…
This feels analogous to hiding in C++. In C++ by default member functions in a base class don't overload with member functions of the same name in a derived class. They get hidden.
Not disagreeing with you but what's interesting is that C++ doesn't hide in this particular situation. Smart pointers implement operator-> and operator* but then ptr.foo() is still always the foo() method of the pointer type (and won't compile if it doesn't have it) - you need ptr->foo() or (*ptr).foo() to get the method of the pointed-to type.
It's one of the few places that C++ is more explicit than Rust. I wonder if there's a reason Rust went a different way? I'm mainly a C++ programmer so I'm genuinely curious.
Re: Mistakes with Rust smart pointers: when Deref goes wrong
#19Earlier quoted context omitted.
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.
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.
And we would expect this behavior why?
Re: Mistakes with Rust smart pointers: when Deref goes wrong
#20Earlier quoted context omitted.
Yes, I've had equally confusing compile errors from C++ due to its lookup rules. For example removing an unused parameter from a function can cause that function not to be found anymore! I'd argue that is more confusing than this Rust issue.
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.
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!