-
Notifications
You must be signed in to change notification settings - Fork 117
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
List of potential derives #25
Comments
It's unclear to me how one would implement the ones I crossed off. One option would be to just allow one to pass in the type parameter via a string like: |
Hi Christopher, thanks for the suggestions. I don't think Display should ever output debug output. That division is there for a reason. Furthermore, I don't think there's a general enough solution for displaying a struct with multiple fields. Structs with a single field would make sense though. The same I think is true for all of the other traits you mention (except maybe deref). So deriving these for newtypes should be quite easy. Even the ones you crossed off should be possible, because you can use generics there (see the Mul like traits for an example). As a next step it would be cool to be able to mark one of the fields of a multi field struct with #[Display] to indicate that it should forward display to that field. I don't really have time to implement these features in the near future though. If you would like to try it's fine though and I'll try to free up some time to merge a PR. |
Hey @cbreeden, I changed your comment at the top a bit for an easy checklist. I hope you're fine with that. Display is now implemented on master for newtypes btw. |
Please add Deref/DerefMut like https://crates.io/crates/shrinkwraprs |
I have a |
I haven't used shrinkwraprs before, how is its Deref impl different to your approach? |
I've just released v0.10.0 with I think those links should show the difference in usage with this: https://crates.io/crates/shrinkwraprs |
Does it only work for members that also impl |
Any further discussion needed before |
@agausmann for structs with multiple fields, I think it would make sense for each field to "opt in" to the #[derive(AsRef)]
struct Foo {
#[as_ref]
bar: Bar,
// Generates impl AsRef<Bar> for Foo { ... }
#[as_ref]
baz: Baz,
// Generates impl AsRef<Baz> for Foo { ... }
} I don't think it's possible to implement #[derive(AsRef)]
struct Foo {
#[as_ref]
bar1: Bar,
// Error! Can't implement AsRef<Bar> multiple times
#[as_ref]
bar2: Bar,
} @JelteF would you be willing to accept a PR that adds |
Yes, that sounds like a good idea.
…On Wed, 11 Sep 2019, 02:19 Bobby Reynolds, ***@***.***> wrote:
@agausmann <https://github.com/AGausmann> for structs with multiple
fields, I think it would make sense for each field to "opt in" to the
AsRef derivation via an attribute. Something like this:
#[derive(AsRef)]struct Foo {
#[as_ref]
bar: Bar,
// Generates impl AsRef<Bar> for Foo { ... }
#[as_ref]
baz: Baz,
// Generates impl AsRef<Baz> for Foo { ... }
}
I don't think it's possible to implement AsRef multiple times for
different fields of the same type. For instance, trying to derive AsRef
as follows should result in an error:
#[derive(AsRef)]struct Foo {
#[as_ref]
bar1: Bar,
// Error! Can't implement AsRef<Bar> multiple times
#[as_ref]
bar2: Bar,
}
@JelteF <https://github.com/JelteF> would you be willing to accept a PR
that adds AsRef and AsMut support as described above?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#25?email_source=notifications&email_token=AAI3YJRNLSZ7HYLJJ52BQ2LQJA2SBA5CNFSM4DNWL3O2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6M3T3Y#issuecomment-530168303>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAI3YJVAXR4ZOFQBWRHZC3TQJA2SBANCNFSM4DNWL3OQ>
.
|
I'd avoid using multiple top-level attributes. It would be better to use a single attribute name like |
@agausmann on one hand that makes sense, but we already do that for the |
@JelteF is What I propose is to add simple If it's acceptable, I'll roll-out implementation in a few working days. |
Derives for any standard library traits fit in this library, so also for
Error. So I'm definitely open to a PR. I'm not entirely sure how you would
want to derive error. Could you make a separate issue for that with your
general idea as a place to discuss the API/ergonomics? (a PR is also fine
if you already have some code).
…On Fri, 11 Oct 2019, 17:10 Kai Ren, ***@***.***> wrote:
@JelteF <https://github.com/JelteF> is #[derive(Error)] would be
desirable? I've tried several err derive crates out there
<https://crates.io/search?q=error%20derive> and they provide custom
display capabilities for ergonomics, which, however, do not mix with our
#[derive(Display)] well.
What I propose is to add simple #[derive(Error)] to derive_more which
will derive *only* std::error::Error implementation. Without any implicit
From and Display implementations. This will play very well with existing
#[derive(Display)] and #[derive(From)] macros.
If it's acceptable, I'll roll-out implementation in a few working days.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#25?email_source=notifications&email_token=AAI3YJTCUXA65PO6TLS5F3TQOCJQDA5CNFSM4DNWL3O2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBAJTVI#issuecomment-541104597>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAI3YJVI5CROE7KDWYBMFVTQOCJQDANCNFSM4DNWL3OQ>
.
|
I ran into a situation where I'd love to be able to use the formatting system in |
You should be able to use #[derive(DebugCustom)] for that. |
I really like this crate, and would love to see one crate that did what you would expect for std traits. So I was thinking about compiling a list of other potential derives:
Conversions:
AsMut
AsRef
Borrowing:
Borrow
BorrowMut
ToOwned
Ops:
Index
,IndexMut
Deref
,DerefMut
Formatting:
Display
Binary
,Octal
,LowerHex
,UpperHex
,LowerExp
,UpperExp
,Pointer
(by generalizingDisplay
implementation)Any thought about these? I wouldn't mind hashing out some of the details and even contributing.
The text was updated successfully, but these errors were encountered: