RFC: constants in patterns by RalfJung · Pull Request #3535 · rust-lang/rfcs · G...

While it is true that not having StructuralPartialEq be implied by #[derive(PartialEq)] would be massively breaking, I feel that requiring it be separate as soon as practicable (i.e. the next edition) would be ideal. Having a StructuralPartialEq implementation is naturally an API commitment, so it should be explicit insofar as it is possible to do so.

Aside from that and permitting manual implementations of StructuralPartialEq (which is mentioned in the RFC), I'm quite happy with the way everything is described.

It's opening a new design space though; t-lang expressed concerns that we already have way too long derive(...) declarations and should look into something like derive(Structural) to get "all the usual derives" or so. This RFC does not aim to solve all the problems in this space, it is an incremental step, and IMO decoupling the structural-equality-promise from #[derive(PartialEq)] is not part of that step. I want to push back against scope creep here.

My primary fear is that people will be making API commitments (and then breaking them) without even realizing it. It's a similar problem to traits being object safe without an explicit opt-in. If this existed previously, I would have broken it multiple times deliberately, as it's something I never intended to promise. I know I have done this for object safety, hoping1 that no one would notice.

I understand the concerns over long derive declarations, even if I personally disagree. Was that a significant factor in weighing the pros & cons of each option?

Footnotes

1. successfully ↩

The issue you describe is pre-existing. I agree it is an issue. This RFC does not aim to solve it since it is entirely orthogonal to what the RFC aims to solve. (This RFC just needs some mechanism for type authors to opt-in to "structural equality". The details of that mechanism do not matter. We have an existing mechanism for this. It is flawed but this RFC does not make it worse.) The RFC already acknowledges this problem and mentions it as a "future possibility". There are other real issues that this RFC aims to solve and I don't think we need to unnecessarily entangle this.

Let's not require an RFC that clearly has net benefit to solve every problem in its space, please. This is just a surefire way to ensure nobody will dare suggest RFCs any more. We need room for incremental RFCs that solve a particular issue without also solving closely related (but entirely orthogonal) problems. It has already taken literal years to arrive at this RFC.

The issue you describe is pre-existing.

Code that runs into that can be written on stable? I was under the implication that it was nightly-only, where the traits currently live. If it can already be encountered on stable, then sure, I have no issue with continuing as-written.

Let's not require an RFC that clearly has net benefit to solve every problem in its space, please. This is just a surefire way to ensure nobody will dare suggest RFCs any more. We need room for incremental RFCs that solve a particular issue without also solving closely related (but entirely orthogonal) problems. It has already taken literal years to arrive at this RFC.

I know that it's not easy writing an RFC, let along "defending" it. If my understanding is not correct, then feel free to say so directly 🙂 I'm sure I'm not the only one with this question.

I didn't realize you assumed that this is nightly-only behavior. :)

This RFC does not allow any new code to work on stable. It only turns some future-compat lints into hard errors.

Given that we already had a lang design meeting that reached pretty much this conclusion, I am going to nominate this for t-lang discussion.