Mistakes with Rust smart pointers: when Deref goes wrong
fuzzypixelz.com
Mistakes with Rust smart pointers: when Deref goes wrong
1–10 of 64 posts
Re: Mistakes with Rust smart pointers: when Deref goes wrong
#2In 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))
Re: Mistakes with Rust smart pointers: when Deref goes wrong
#3Typo: `impl Index> for AsciiString`
Re: Mistakes with Rust smart pointers: when Deref goes wrong
#4I 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 non-method functions. This means that you always have to qualify them, like Box::leak(my_box), and thus you can't get this type of conflict.
Using Deref for types like String or Vec doesn't really fall into this category. They implement something more analogous to an "is-a relationship" in OO. Even outside of those examples, I've seen people manually implement inheritance-like behavior, using Deref to delegate to a field that stores the "base class" instance.
If you do that, you're likely to have a name conflict between the two types sooner rather than later. That's fine as long as you're aware that Rust doesn't really do overload resolution -- AFAICT, the "outer" methods always wins regardless of the arguments at the call site.
Re: Mistakes with Rust smart pointers: when Deref goes wrong
#5"The issue, it turns out, is that method search does not check method parameter types against argument types."
Right. Rust's doesn't allow much overloading of function names. Partly because C++ did. The C++ overload resolution rules got very complex, especially since they interact with implicit conversions. To keep those rules from introducing errors, there's a rule in C++ that the overload chosen must be at least one step "better" than any matching alternative. Something that was supposed to make thing simpler thus became very complicated.
So Rust makes the programmer write that stuff out, which is more verbose but less confusing.
Re: Mistakes with Rust smart pointers: when Deref goes wrong
#6Typo: `impl Index> for AsciiString`
There are a bunch of typos and missing generics all over the place, looks like something there doesn't like angle brackets.
Re: Mistakes with Rust smart pointers: when Deref goes wrong
#7"The issue, it turns out, is that method search does not check method parameter types against argument types." Right. Rust's doesn't allow much overloading of function names. Partly because C++ did. The C++ overload resolution rules got very complex, especially since they interact with implicit conversions. To keep those rules from introducing errors, there's a rule in C++ that the overload chosen must be at least on…
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.
Re: Mistakes with Rust smart pointers: when Deref goes wrong
#8Typo: `impl Index> for AsciiString`
There are a bunch of typos and missing generics all over the place, looks like something there doesn't like angle brackets.
Possibly an HTML-transparent toolchain, something like the original markdown use case would likely have this sort of effect (as HTML transparency was a feature to Gruber).
Re: Mistakes with Rust smart pointers: when Deref goes wrong
#9"The issue, it turns out, is that method search does not check method parameter types against argument types." Right. Rust's doesn't allow much overloading of function names. Partly because C++ did. The C++ overload resolution rules got very complex, especially since they interact with implicit conversions. To keep those rules from introducing errors, there's a rule in C++ that the overload chosen must be at least on…
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.
Re: Mistakes with Rust smart pointers: when Deref goes wrong
#10>Rather, it only checks for method names and where-clauses such as T: Trait. Types are only resolved in the confirm phase, at which point rustc would have already picked its method.
Not following here, the compiler iterates over the deref-chain and acquires a list of method names, but it also "checks for ... where-clauses", what does that mean? A quick look at the linked probe code indicates what we filter on Self traits and return value traits.