8

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

 1 year ago
source link: https://github.com/rust-lang/rfcs/pull/3535
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

Conversation

Member

@RalfJung RalfJung

commented

Nov 25, 2023

•

edited by rustbot

When a constant appears as a pattern, this is syntactic sugar for writing a pattern that corresponds to the constant's value by hand. This operation is only allowed when (a) the type of the constant implements PartialEq, and (b) the value of the constant being matched on has "structural equality", which means that PartialEq behaves the same way as that desugared pattern.

Thanks a lot to everyone who gave feedback in the Zulip discussion!

Rendered

BurntSushi, Jules-Bertholet, oli-obk, Nyabinary, Evian-Zhang, pitcer, AaronKutch, clarfonthey, and GrayJack reacted with heart emojiBurntSushi, Nadrieril, Nyabinary, davidhewitt, BD103, and GrayJack reacted with rocket emoji

Member

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.

Member

Author

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.

Member

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 ↩

Member

Author

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.

Member

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.

Member

Author

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.
jhpratt reacted with heart emoji

Comment on lines

+293 to +296

- To avoid interpreting `derive(PartialEq)` as a semver-stable promise of being able to structurally match this type,

we could introduce an explicit `derive(PartialEq, StructuralPartialEq)`.

However, that would be a massive breaking change, so it can only be done over an edition boundary.

It probably would also want to come with some way to say "derive me all the usual traits" so that one does not have to spell out so many trait names.

One potential alternative to this is to allow negative impls for StructuralPartialEq for derived PartialEq, and/or perhaps to allow typing derive(PartialEq, !StructuralPartialEq).

If we think of StructuralPartialEq "like an auto trait" since it's infectious, this should make some amount of sense.

Member

Author

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.
clarfonthey and workingjubilee reacted with thumbs up emoji

RalfJung

added the I-lang-nominated Indicates that an issue has been nominated for prioritizing at the next lang team meeting. label

Dec 2, 2023

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

Back to tour

ehuss

ehuss left review comments

programmerjake

programmerjake left review comments

petrochenkov

petrochenkov left review comments

clarfonthey

clarfonthey left review comments
Assignees

No one assigned

Labels
A-const Proposals relating to const items A-patterns Pattern matching related proposals & ideas I-lang-nominated Indicates that an issue has been nominated for prioritizing at the next lang team meeting. T-lang Relevant to the language subteam, which will review and decide on the RFC.
Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

None yet

6 participants

report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK