don't generate extra impl for Eq assertions

[fee1-dead]

Eq already has a method assert_receiver_is_total_eq that allows you to put asserts in. This PR makes it so we use that instead of generating a new trait and impl every time (which could be a lot).

This is also a cleanup because apparently additional_impl is only used by Eq (and arguably quite confusing as additional_impl is used to generate the Eq impl while the "main" impl was the extra impl) so we can remove that now.

generating a struct __AssertEq each time is still a little wasteful, but given that derive-where is a single crate (so no "normal" support crate to share types) it might be unavoidable.

[daxpedda]

I specifically removed this a while ago because assert_receiver_is_total_eq() is and undocumented method and therefor unstable.

But I agree that the current state is not ideal and we actually considered splitting the crate into a normal and proc-macro crate for this reason specifically.

[fee1-dead]

incorrect. the method is marked as #[stable] since Rust 1.0. It's not going to be removed just because it is doc(hidden). If the libs team wanted to leave it open for removal they would have used the unstable attribute.

[daxpedda]

All methods in Std marked with #[doc(hidden)] are API unstable. #[stable] just means its available on Rust stable, it doesn't mean it is API stable. E.g. I remember there being a #[doc(hidden)] function to define where the output of println! goes that was simply removed. It was used extensively with Wasm.

EDIT: the function was called set_print().

I'm happy to be told otherwise if you can find me something concrete on that topic, I myself don't have anything concrete on it.

[fee1-dead]

EDIT: the function was called set_print().

This was removed in this PR: rust-lang/rust@aff7bd6 (#78714). Note that what defined whether something was stable or not was through the #[stable] and #[unstable] attribute. set_print had an #[unstable] attribute, i.e. you had to be on nightly and use feature() to use it:

#[unstable(feature = "libstd_io_internals", issue = "42788")]
#[doc(no_inline, hidden)]
pub use self::stdio::{set_panic, set_print};

The method we're using in this PR is stable:

    #[stable(feature = "rust1", since = "1.0.0")]
    fn assert_receiver_is_total_eq(&self) {}

This is stable Rust so there's no way the libs team can remove it as it would be a breaking change.

[fee1-dead]

So

#[stable] just means its available on Rust stable, it doesn't mean it is API stable.

is not true. Rust stdlib maintainers cannot make breaking changes to stable code. That's outlined in https://rust-lang.github.io/rfcs/1105-api-evolution.html - #[stable] absolutely constitutes stable code.

[daxpedda]

set_print had an #[unstable] attribute, i.e. you had to be on nightly and use feature() to use it:

Ah, good catch.

So

#[stable] just means its available on Rust stable, it doesn't mean it is API stable.

is not true. Rust stdlib maintainers cannot make breaking changes to stable code. That's outlined in https://rust-lang.github.io/rfcs/1105-api-evolution.html - #[stable] absolutely constitutes stable code.

I'm not seeing that #[stable] constitutes stable API in RFC 1105. Can you quote the relevant paragraph?

[daxpedda]

Worst case scenario: I'm happy to take a quote from a Rust team member on e.g. Zulip or something.

[fee1-dead]

See also https://rustc-dev-guide.rust-lang.org/stability.html.

I'm a Rust team member, although I primary work with the compiler (I'm a compiler maintainer). I am confident that #[stable] means assert_receiver_is_total_eq will never get removed. idk if you want me to go on Zulip and ask libs specifically, don't think that is necessary.

[daxpedda]

I did ask in Zulip: https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/.60.23.5Bstable.5D.60.20but.20.60.23.5Bdoc.28hidden.29.5D.60.
Apparently it is considered unstable.

But please let me know if you find out otherwise.
Until then: closing.

[fee1-dead]

Apparently it is considered unstable.

Oh well. That part is really unintuitive. Thanks for asking! I stand corrected