BREAKING: Use `#[non_exhaustive]` on structs?

[madsmtm]

In v3.x, it might make sense to use #[non_exhaustive] on syn's structs. As long as some kind of fn new or impl Default is 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, Abi probably shouldn't be, since it's basically a small helper struct. But ItemStruct definitely should (imagine the language wanted add unsafe struct Foo {} or extern "C" struct Foo {}).

This would have avoided the issues in #1851.

[dtolnay]

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.

[jhpratt]

@dtolnay Perhaps it would be more feasible to use the pre-attribute hack of having a __non_exhaustive field? The type could even be inaccessible, effectively preventing manual construction.

[dtolnay]

That alternative has all of the same downsides.

[jhpratt]

Ah, I see. You want to be able to do it but the attribute prevents it. I interpreted it the other way around.

[Veetaha]

I don't know exactly how syn managed to avoid numerous major version bumps (and continues to avoid actually) without the default field values language feature (rust-lang/rust#132162). Adding a new optional public field to a struct not marked with #[non_exhaustive] is indeed a breaking change - I myself have some syn code that uses struct literal syntax in a proc macro.

I guess every major syn release batches a big number of new language features, while retaining compatibility via the Verbatim hack.

But I wonder will syn 3.0 wait for #132162 to benefit from that feature and prevent future breaking changes that need to add optional public fields.