We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
deref is usually implemented for transparent types such as pointers, but some people use it for other purposes, such as polymorphism, etc.
Without the help of lsp, it is difficult for the reader to know where this method comes from.
More clear code.
If possible, we should warn users when they implement deref
struct Parent {} impl Parent { fn some_op(&self) {} } struct Child { parent: Parent } impl Deref<Parent> for Child { // ^ warning: DON'T implement Deref // ... }
Could be written as:
struct Parent {} impl Parent { fn some_op(&self) {} } struct Child { parent: Parent } impl Child { fn some_op(&self) { self.parent.some_op(&self) } }
The text was updated successfully, but these errors were encountered:
No branches or pull requests
What it does
deref is usually implemented for transparent types such as pointers, but some people use it for other purposes, such as polymorphism, etc.
Without the help of lsp, it is difficult for the reader to know where this method comes from.
Advantage
More clear code.
Drawbacks
If possible, we should warn users when they implement deref
Example
Could be written as:
The text was updated successfully, but these errors were encountered: