new release

[dignifiedquire]

Hey I was wondering if it was possible to cut a release with the current code as there are some things I would love to start using. Thanks

[cwfitzgerald]

Seconding this for the upgrade for syn 2.0. This is one of the lingerers.

[dignifiedquire]

Because I couldn't wait I have published a fork, directly from todays main branch: https://crates.io/crates/derive_more_preview

[ilslv]

@dignifiedquire maybe for some reason this won't work for you, but you can just add git dependency on a specific commit. So current latest main will look like:

derive_more = { git = "https://github.com/JelteF/derive_more.git", rev = "60ed1e7" }

[dignifiedquire]

@ilslv thanks, that's what I have been doing for a while, but I need to cut releases and publish them to crates.io which does not allow to have git dependencies.

[JelteF]

I published v1.0.0-beta.1 a few minutes ago from the current master. There's still a few breaking changes incoming before the final 1.0.0 release, but most things should stay the same now. Feedback is very much appreciated.

[dignifiedquire]

great, thanks a lot!

[tyranron]

@JelteF some report on integrating 1.0.0-beta.3 in our codebase.

Bugs

Only 3 bugs were discovered during integration: #287, #288, #289
Everything else worked out very well. Legacy syntax diagnostics were really very helpful.

Inconveniences

Importing via derive_more::Trait both macro and trait at the same time was really helpful most of the time, except the one major case: derive(Error).

It turned out that the case for defining pub struct Error/pub enum Error/pub type Error is very often one. We had tons of such errors in granular modules (like transcoding::Error, command::create_user::Error, etc), and, as the result, the tons of conflicts with use derive_more::Error imports. This lead to a quite refactoring, where in most cases such error types were renamed more precisely, depending on use-case. However, there are still enough places where such renaming is inappropriate or undesired, so we were forced to use use derive_more::Error as StdError imports there, which turned out to be a good practice, though, as it removed any ambiguities regarding [`Error`] references in docs.

However, I think the derive_more::macros module re-exporting macros only would still make sense and may save some nerves for somebody in similar situations. Importing derive_more-impl crate alongside didn't really feel as an option. It's much easier to just write use derive_more::macros::Error in such a situation and don't bother with conflicts or dependencies.

Happiness

Where 1.0.0-beta.3 derive_more really shines is derive_more::Debug, of course. It so much flexible and convenient, that allowed us to strip out every single manual Debug implementation in our codebase! Tons of boilerplate just gone away! Even more, no more #[allow(missing_debug_implementations)] are present in our codebase: very complicated places where we were just too lazy to write manual impls became as easy as putting 2-3 attributes.

[JelteF]

Importing via derive_more::Trait both macro and trait at the same time was really helpful most of the time, except the one major case: derive(Error).

Hmm, that indeed sounds really annoying. Do you also have examples where re-exporting the traits did reduce the amount of imports you needed? If so, did you have any cases where it was beneficial that Error was exported. This is most certainly something we should fix before the final 1.0.0 release.

I think maybe we shouldn't export the Error trait for this reason as an exception to the rule. I don't think any of the other derives have this problem that it's common for people to define a struct themselves with same name. Error seems like a special case in this regard. Having use derive_more::Error cause such breakage seems quite undesirable.

[tyranron]

@JelteF

Do you also have examples where re-exporting the traits did reduce the amount of imports you needed?

Yes, most of the time, it reduced duplicated imports from std, and it felt like better ergonomics.

If so, did you have any cases where it was beneficial that Error was exported.

Similar for the Error. There were quite a lot places where redundant use std::error::Error or use std::error::Error as _ were removed.

I think maybe we shouldn't export the Error trait for this reason as an exception to the rule.

Error seems like a special case in this regard.

I don't think so. That was my first feeling, of course, when I started the refactoring and was overwhelmed with a lot of import conflicts. But after finishing it, I think that things are much better the way they are now.

You see, I can't say the problem is with the new version of derive_more. For me, it seems quite the opposite: the problem is with the old version of derive_more and the new version just uncovers it. We had quite a lot of modules in the code which looked like this (or similar):

use std::error::Error as StdError;

use derive_more::{Display, Error};

#[derive(Display, Error)]
pub struct Error(Box<dyn StdError>);

So in the same scope we had macro@Error referring to derive_more::Error, local Error type, and the std::error::Error renamed as StdError, which was quite a bad situation, because the same ident Error referred to different things, while the same thing actually was named differently (Error and StdError at the same time). This lead to additional headache in docs: disambiguating stuff explicitly ([`Error`](struct@Error)). This mess appeared because old derive_more was allowing it easily.

With new derive_more, we streamlined such modules as the following:

use derive_more::{Display, Error as StdError};

#[derive(Display, StdError)]
pub struct Error(Box<dyn StdError>);

And voilà, no ambiguity anymore! No additional docs squatting!

So, I think the new derive_more forces to write better code, which is good. I don't want to lose this quality.

For those who are really pissed off and don't bother with such stuff, I really think the use derive_more::macros::Error re-export is enough to do the trick.

[JelteF]

Okay, sounds good. Can you create a PR for the macros module? Or probably call it the derives module instead? (I slightly prefer that name)

[pacak]

Did you mean to close this whole issue? #290 added a derive module, but I don't see a new release yet.

[KillingSpark]

Any blockers for the release? Having syn 2.0 would be very nice

[tyranron]

@KillingSpark yes, there are some blocker still for going fully into 1.0. Mostly are #142 and #328, but there can be some new ones once the code is revisited before 1.0.

Nevertheless, you already can use syn 2.0 by using 1.0.0-beta.* versions.