Automatically deriving implementations

[vandenheuvel]

Is there any outlook on automatic derivations of the traits in this crate?

I tried to write a derive crate, but got stuck. Deriving for example AbsDiffEq for structs could be done by calling AbsDiffEq::abs_diff_eq on all fields, in combination with an impl<T: Eq> AbsDiffEq for T. This last trait implementation collides however with the existing derivation implementations such as impl<'a, T: AbsDiffEq> AbsDiffEq for &'a T. I don't know how to solve this problem without removing these trait derivations, or until this work is finished.

[tylerreisinger]

Is the last blanket impl necessary? You could always just create a macro to create the implementation for foreign types if needed

[tylerreisinger]

Here's a pretty quick and dirty example of the sort of thing needed: https://gist.github.com/tylerreisinger/886e56379beffabddaff7bad6a232f06. It can only handles structs and won't insert type bounds on generics, but otherwise works.

[tylerreisinger]

Also, there is no clean way to deal with both non-primitive Epsilon types and a mix of f32/f64 types without TryFrom, which is currently unstable. I used as in my example, as I'm guessing non-primitive Epsilons aren't that common.

[aldanor]

A nice thing to have would be a derive-proc-macro, so you could do

#[derive(AbsDiffEq)]
struct MyStruct { ... }

thus avoiding all the repetitive boilerplate on a per-struct basis.

[joshburkart]

This would be really great to have! Approximately comparing nested structs/enums is a pretty common use case when writing tests for numerical computing applications. @tylerreisinger Do you think the implementation you made is ready for a PR in some form? Or too hacky right now?

[tylerreisinger]

@joshburkart It's not ready for a PR yet, but I can work on it a bit this weekend and see if I can get something working. TryFrom being stabilized helps with an issue implementing it.

[brendanzab]

Yeah, having this would be really nice! I know it'll be a bit annoying with the epsilon though, and haven't had much time at the moment to look into it.

[tylerreisinger]

I've created a repository at https://github.com/tylerreisinger/approx_derive to implement it. When it is production ready, I can transfer ownership or merge it into the approx repo with a cargo workspace.

[linclelinkpart5]

I'd love to have this as well!

[Sufflope]

Big woops, didn't see https://github.com/jonaspleyer/approx-derive created between my first usage of approx 2 years ago, and my latest one month ago when I tought "come on it needs some derives" 🙈

Some pretty big differences in design choices so I'll see how to best contribute to it, but at least linking it here for visibility to at least avoid having a third person going full xkcd 927 😅

[jonaspleyer]

Hey everyone, I have just recently updated my approx-derive crate with some new features. Is there an effort or desire to merge the two crates? As far as I can tell, the maintainer of approx has been inactive for a longer period of time.

From briefly looking over the suggestions made by @Sufflope it seems that it would be a good idea to use darling to simplify the parsing step. I have to admit that I am currently working on other projects however so I will not put too much effort into merging the two crates or refactoring code to use darling.

[jonaspleyer]

To summarize the functionalities of my crate. It solves some of the problems already encountered by users:

• Use equality in fields where desired
• Custom epsilon values for individual fields
• Custom max_relative value
• Casting of values (such as f32 to f64 or vice versa)
• Skip individual fields
• Generics are supported (see tests)
• Custom mapping of values before comparing them (eg. map circle area to radius |v| v.sqrt() / f32::consts::PI / 2.0).