For types which implement Deref, change some methods to associated functions?
#210
Labels
blocking-next-release
This issue should be resolved before we release on crates.io
compatibility-breaking
Changes that are (likely to be) breaking
Comments
joshlf
added
the
blocking-next-release
joshlf
added
compatibility-breaking
Closed
joshlf
added
the
blocking-next-release
joshlf
added a commit
that referenced
this issue
Sep 7, 2024
Since `Ref` implements `Deref`, methods risk conflicting with methods of the same names on the target type. Note that, in #210, we considered applying the same change to `Unalign`. We choose not to do that because most uses of `Unalign` involve types with alignments greater than 1, and for these types, `Unalign` does not implement `Deref`. It's not worth making the API significantly more cumbersome in order to make it easier for this niche use case. Closes #210
joshlf
added a commit
that referenced
this issue
Sep 7, 2024
Since `Ref` implements `Deref`, methods risk conflicting with methods of the same names on the target type. Note that, in #210, we considered applying the same change to `Unalign`. We choose not to do that because most uses of `Unalign` involve types with alignments greater than 1, and for these types, `Unalign` does not implement `Deref`. It's not worth making the API significantly more cumbersome in order to make it easier for this niche use case. Closes #210
github-merge-queue bot
pushed a commit
that referenced
this issue
Sep 8, 2024
Since `Ref` implements `Deref`, methods risk conflicting with methods of the same names on the target type. Note that, in #210, we considered applying the same change to `Unalign`. We choose not to do that because most uses of `Unalign` involve types with alignments greater than 1, and for these types, `Unalign` does not implement `Deref`. It's not worth making the API significantly more cumbersome in order to make it easier for this niche use case. Closes #210
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We have some types (such as
RefandUnalign) which implementDeref, and which provide methods (such asinto_ref). This conflicts with the standard library's pattern of preferring associated functions over methods on types which implementDeref(e.g.,Box::into_raw). This pattern is well-motivated: When a method is called on aDereftype, it is resolved on both the type itself and the target type (e.g., on bothBox<T>and onT), and so methods on the type itself (Box<T>) can conflict with those on the target type (T). We should consider adopting this pattern.The text was updated successfully, but these errors were encountered: