Should #[non_exhaustive] be advised over private members for extensibility?

[haibane-tenshi]

#[non_exhaustive] attribute on Rust reference.

I believe #[non_exhaustive] emerged as a better solution to the same problem and private members are an artifact from the rime before it. Still it seems there are a few differences.

From what I can understand, the attribute has three primary differences compared to private members:

• It is still exhaustive inside original crate. There can be cases where this is undesirable (but I struggle to imagine when) - in which case private members still can be useful.
• It can be applied to unit structs/variants. Impossible to achieve with private members (have to convert it to tuple/struct and tuple/struct variant respectively).
• It can be applied to enums. A different approach is required to achieve similar effect without the attribute - a variant with never type (empty enum or !). It is not mentioned in the book.

Overall I consider the new approach as much superior (less boilerplate, better consistency), the old one should be deprecated and used only when very specific semantics is required (e. g. module-level non-exhaustiveness vs crate-level).

[AnthonyYoManz]

#[non_exhaustive] was made with the very purpose of replacing the old-school, unintuitive private member pattern so I think it makes sense to update our advice.

[simonsan]

the old one should be deprecated and used only when very specific semantics is required (e. g. module-level non-exhaustiveness vs crate-level)

That said, how do you imagine it. Do you want to keep both variants in the repo and state their use cases explicitly (link between them, improve doc to state both)? #135 replaces it now, which I'm not sure of if there is still at least one scenario where it will be used?

[MarcoIeni]

An obvious scenario where it will be used is for compatibility with MSRV (Minimum supported Rust version).

Do you want to keep both variants in the repo and state their use cases explicitly (link between them, improve doc to state both)?

I would keep both variants in the same file, if it is necessary to keep the old approach.

Maybe the file could be called "Fields extensibility" and then we discuss both the approaches, first the new one and then we also write the old one (again, if we decide it is necessary), by explicitly saying it is less idiomatic than using non_exhaustive.

[haibane-tenshi]

I'm a third person here, but I would probably create a "Legacy" category with patterns which are outdated/replaced with better alternatives, and then create cross-links on both approaches (maybe with MSRV mentioned etc.)

• This will clearly show which approach is preferable.
• There is probably some code in the wild which still uses the old approach. This will keep the pattern discoverable if needed.
• There are probably other patterns which can go into the new category (like never type in enums I mentioned in the post).

[MarcoIeni]

Mmm..I don't dislike the idea of a "legacy" category :)

[simonsan]

I think something like:

Introduction
Contributing
Idioms
Patterns
Anti-patterns
Functional Programming
Refactoring
Legacy
|--- Idioms
|--- Patterns
|--- Anti-Patterns
Additional Resources

Could be then a nice build up rather than mentioning legacy in each category.

[MarcoIeni]

I agree! Of course for now there will be only the idioms directory there because this will be the only entry.
So in #135 we could move the old file in legacy/idioms/ and idioms/priv-extend.md will be updated with the new approach.
If you agree with this plan we could remove the needed-discussion label.

[simonsan]

A different approach is required to achieve similar effect without the attribute - a variant with never type (empty enum or !). It is not mentioned in the book.

This would be the question if it's worth to mention then and should be added.

For now I think the legacy category didn't make sense. Also it's the question if we would need such a category overall and won't only keep the preferable approach and maybe an alternative inside the same file to have a discussion about both.