Kai Ren
Kai Ren
@phip1611 well, this change doesn't survive the MSRV check. @JelteF are we OK to bump up MSRV to at least 1.51 (last 10 versions)? Or do you see some sense...
@JelteF in case we don't want to do `1.x` releases yet, we always may release just `0.100.x` one, containing the necessary breaking changes.
@JelteF I'm agree with having `derive_new` in `derive_more`! 🤘 But regarding the syntax `#[from(value=::std::backtrace::capture())]`, I still think it's more idiomatically to use the naming adopted by `serde_derive`: `#[from(with = ::std::backtrace::capture())]`....
@appetrosyan doesn't `#[from(types(Foo))]` work here?
@ilslv seems reasonable.
If this is something desirable, I'll submit the PR in a week or two.
@ronlobo pesonally, nobody pushes you to use them, thought. Getters/setters represent a good and idiomatic tool to encapsulate invariants behind a type and do not allow to accidentally break those...
@ronlobo > Invariants can also be captured in the constructor for an immutable data structure. Yup, that's what happens 95% of times. And then you usually need values of your...
@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)]`...