Create 0000-enum-variant-cast-patterns.md#3985
Conversation
| # Acknowledgements | ||
| [acknowledgements]: #acknowledgements | ||
|
|
||
| This RFC was developed from the public Zulip proposal |
There was a problem hiding this comment.
Developed from?
You posted this proposal four hours before this RFC and it had not yet received any comments.
On its own, this is already a weird thing to say since it's your proposal. You wrote an RFC for your proposal; you didn't develop a proposal that was posted somewhere.
This wording immediately begs the question of whether you developed this RFC, or if you used a separate tool like an LLM to increase the word count on a proposal that the team already could have told you is unlikely to get accepted because of multiple reasons, including that it is possible with const patterns.
While there isn't an outstanding policy regarding LLM usage on RFCs, this is at least very presumptuous and wasteful, because we've been trying to get people to make smaller proposals before dumping large documents on the team.
There was a problem hiding this comment.
Like to be clear, as someone who has in the past effectively just dumped documents on the team, I think there is a lot of value to be drawn from writing these documents even if they aren't accepted. I just think that value equation is totally different when you've just had a tool format an existing proposal into a document with a load of extra words that don't really address the main reason why this would be considered.
The goal is to make the language better and help people write good code. The code examples you gave seem like this extra syntax is not worth the complexity compared to either defining constants like you did (they can even be associated constants, for Enum::CONST) or adding const {} around the patterns for const patterns.
Instead of anyone drawing value from this discussion it just feels like a big waste of resources spent on a tool to make a document that doesn't need to be read to say there are potential issues with the proposal. And it's extra annoying that you seemingly did the right thing and proposed it more informally on Zulip first but only waited four hours before moving onto the next step.
This RFC proposes allowing unit variants of unit-only enums with an explicit primitive integer #[repr(...)] to be cast directly to that representation type in patterns:
match byte {
Operation::Banana as u8 => {}
_ => {}
}
This is narrowly defined syntactic sugar for an equivalent named constant pattern. It introduces no implicit conversions or arbitrary expressions in patterns and does not change enum layout, validity, or exhaustiveness semantics. It is intended primarily for matching integer values from protocols, file formats, hardware interfaces, and FFI while retaining the enum variant’s semantic name.
Rendered