BREAKING: Use #[non_exhaustive] on structs?
#1867
Comments
17 tasks
|
I prefer not to make this change. With rust-lang/lang-team#143, non_exhaustive is too disruptive on being able to conveniently construct syntax trees. |
|
@dtolnay Perhaps it would be more feasible to use the pre-attribute hack of having a |
|
That alternative has all of the same downsides. |
|
Ah, I see. You want to be able to do it but the attribute prevents it. I interpreted it the other way around. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In
v3.x, it might make sense to use#[non_exhaustive]on syn's structs. As long as some kind offn neworimpl Defaultis provided, users would still be able to construct structs manually, while still allowing the language to evolve further.I'm not entirely sure yet which structs should have this attribute, but I think it should basically be "all, unless a good argument is given as to why not". As an example,
Abiprobably shouldn't be, since it's basically a small helper struct. ButItemStructdefinitely should (imagine the language wanted addunsafe struct Foo {}orextern "C" struct Foo {}).This would have avoided the issues in #1851.
The text was updated successfully, but these errors were encountered: