Pre-RFC: allow re-rexporting (pub use) to selectively export struct fields

language design
1

Summary

Currently the way of achieving the equivalent of “protected” API functionality is to make a struct, enum, trait, or method be “public”, and then chose not to re-export it using “pub use”.

This works well for everything I mentioned above. Where it is much less useful is for struct fields.

Syntactic extensions to “pub use” could make this dramatically simpler"

Motivation

As far as I can tell, the recommendation for allowing private field access within sibling sub-modules of a large module/crate, but not export those fields externally, is to:

  1. make the field private, not pub
  2. make a public sub-module that provides a public api to access that private field
  3. don’t export the sub-module outside of your crate or primary module

This works. I’m doing it right now. But it is really ugly and cumbersome when you need to do it a lot.

Unfortunately, there are cases where this pattern needs to be used extensively. In particular, FFI usage where you have one -sys crate, either hand written or bindgen-genderated, that should be completely wrapped by a safe crate.

When the -sys crate’s API is large and complex, it is, in practice, necessary to break your wrappers into different files, and hence different modules. So any cross-module “protected” (in the java sense) access requires implementation of the pattern above.

In the work I’ve been doing, my crate that wraps the -sys crate has 30+ files, and 50+ structs who need to follow this pattern. This is taking hours and hours of refactoring work, and the result is substantially more verbose and harder to read than it was when I just accepted exposing what should be hidden implementation details of those structs.

##Design I am not at all attached to this particular syntax nor approach. but the following seems fairly simple, concise, and backwards compatible.

  1. Make all of your struct fields that need to be accessed by sibling modules as public
  2. Don’t create an additional sub-module with access methods
  3. Instead, in the “pub use” section, add syntax to allow you to optionally export public fields instead of requiring the export of private fields.

Possible syntax:

pub use mymod::MyStruct; //same as today. will export all public fields
pub use mymod::MyStruct{}; //hides all fields while exporting this struct
pub use mymod::MyStruct{fieldA, fieldC, fieldD} //does not expose any public fields of MyStruct other than A, C, and D

##Alternatives

  1. Status quo, which is notably cumbersome for wrapping complex unsafe/ffi crates.
  2. Alternate syntax. Open to any ideas.
  3. RFC 1422
2

RFC 1422 seems to cover this, "protected" fields can be declared as pub(crate)

1 Like
3

Thanks for that.

I had looked, but missed that RFC. I agree that that would sufficiently address this issue. I will say, however, that this proposal is less intrusive than 1422, and shouldn’t run afoul of the objections that that one has hit. I’ll add it as an alternative, but I’d love more feedback on this approach.

4

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.