-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Overriding default ToStr impl for @A where A: ToStr #4851
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
No, you can't do this. |
One possible workaround is to make a "newtype" for your
then use Closing since this check is working as designed. |
If there's no simple workaround on that end, I'd argue that the default ToStr implementations for pointers-to-ToStr should be removed. If I have some non-small data structure and I care about the to_str(), I'm probably going to also be passing around pointers to the structure. The way I see it, it's far more likely that I'll want
rather than
but more broadly, I will want control over the to_str result without having to resort to awkward hacks such as AtFoo. As evidence for the superfluity of the current @(ToStr) and ~(ToStr) implementations, if I comment them out, the whole system recompiles just fine. |
Oh, and here's a variation that seems more like a genuine error in the impl-finder to me: If I comment out both impls in my first example, unsurprisingly I get an error that there are no implementations for ToStr for If I provide only the implementation for |
Removing the default implementations here is a change worth considering -- @pkgw , please file a new issue with the RFC tag if you want to propose that. Thanks! |
I'm running into an issue with an interaction between ToStr and pointers that I'm not sure how to handle. I have a struct with a ToStr, and I want to call that method on a @-pointer to the struct. However, to_str.rs provides a generic implementation:
that returns the to_str prefixed with "@". I do not want this behavior, but I can't figure out how to override it. My naive implementation is:
But this gives a compile error about multiple implementations. Is there a way around this?
The text was updated successfully, but these errors were encountered: