# Add an #\[allow(ignore\_field\_privacy)\] annotation **URL:** \ **Category:** ideas (deprecated)\ **Created:** [October 10, 2014, 12:01am UTC](https://internals.rust-lang.org/t/add-an-allow-ignore-field-privacy-annotation/625 "2014-10-10T00:01:21Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![bfops](https://avatars.discourse-cdn.com/v4/letter/b/50afbb/32.png) [@bfops](https://internals.rust-lang.org/u/bfops)\ **Post date:** [October 10, 2014, 12:01am UTC](https://internals.rust-lang.org/t/add-an-allow-ignore-field-privacy-annotation/625/1 "2014-10-10T00:01:22Z")
@Jurily brought up an interesting idea that I feel got a little overlooked: the ability to (transiently) forgo public/private field protection. Now, I make almost all my struct fields public for pretty much exactly the reason that some user might want to be crafty in a way I didn’t expect, but for classes where that’s not true, I wouldn’t mind the ability to explicitly and obviously opt out of those protections from the compiler, and annotate specific lines in a way that allows me to access private members. Thoughts? ---
**Author:** ![comex](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/comex/32/2587_2.png) [@comex](https://internals.rust-lang.org/u/comex)\ **Post date:** [October 10, 2014, 12:59am UTC](https://internals.rust-lang.org/t/add-an-allow-ignore-field-privacy-annotation/625/2 "2014-10-10T00:59:52Z")
I’ve encountered situations where I’ve wanted to use this multiple times - although I’m usually too much of a cowboy for my own good, I still think it would be nice to have. For example, recently I wanted to modify the behavior of getopts to use BSD-like rather than GNU-like parsing (i.e. all options must come before free arguments rather than allowing them to be interspersed\*). In the modified crate, it would be nice to use the same data types as the original, rather than identical copies, so that external code could operate on them without caring whether the modified or original parser is in use. But this isn’t possible, because getopts::Matches has private fields so I can’t create instances of it from outside the crate. Even though privacy implies there is no stability guarantee for the struct’s layout, it seems unlikely in practice to change anytime soon, so a privacy override would probably work fine for me if it were available (and if it didn’t, it’d be my own fault). - Now that I think about it, it might be easier just to insert “–” at an appropriate location, then call into the original. But the general point stands. ---
**Author:** ![seanmonstar](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/seanmonstar/32/36_2.png) [@seanmonstar](https://internals.rust-lang.org/u/seanmonstar)\ **Post date:** [October 10, 2014, 2:04am UTC](https://internals.rust-lang.org/t/add-an-allow-ignore-field-privacy-annotation/625/3 "2014-10-10T02:04:43Z")
Allowing access to private properties could ruin backwards compatibility attempts. You can usually feel free to change around private properties and expect not to break anyone downstream. ---
**Author:** ![bfops](https://avatars.discourse-cdn.com/v4/letter/b/50afbb/32.png) [@bfops](https://internals.rust-lang.org/u/bfops)\ **Post date:** [October 10, 2014, 2:12am UTC](https://internals.rust-lang.org/t/add-an-allow-ignore-field-privacy-annotation/625/4 "2014-10-10T02:12:26Z")
To me, that’s an onus you reasonably take on when you touch private members. An analogy for me is that I can take unsafe pointers from underneath a ref, and lifetime and one-mutable-reference-only semantics will continue to be enforced for refs, essentially unaware of the sketchy things I’m doing with pointers, essentially assuming that they’re still the only things touching the data they refer to. In the same way (to me), library authors should absolutely continue to treat private members as things that only they know about, essentially unaware of the sketchy things I’m doing with their private members. ---
**Author:** ![Jurily](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/jurily/32/212_2.png) [@Jurily](https://internals.rust-lang.org/u/Jurily)\ **Post date:** [October 10, 2014, 8:24am UTC](https://internals.rust-lang.org/t/add-an-allow-ignore-field-privacy-annotation/625/5 "2014-10-10T08:24:00Z")
[This](http://steve-yegge.blogspot.com/2010/07/wikileaks-to-leak-5000-open-source-java.html) may have been the inspiration, I just remembered it. ---
**Author:** ![tbu](https://avatars.discourse-cdn.com/v4/letter/t/839c29/32.png) [@tbu](https://internals.rust-lang.org/u/tbu)\ **Post date:** [October 11, 2014, 7:14pm UTC](https://internals.rust-lang.org/t/add-an-allow-ignore-field-privacy-annotation/625/6 "2014-10-11T19:14:54Z")
I don’t think it’s really needed. This seems like something that will be abused, as opposed to the unsafe code that would be needed to do the same thing otherwise. ---
**Author:** ![eddyb](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/eddyb/32/8411_2.png) [@eddyb](https://internals.rust-lang.org/u/eddyb)\ **Post date:** [October 11, 2014, 7:38pm UTC](https://internals.rust-lang.org/t/add-an-allow-ignore-field-privacy-annotation/625/7 "2014-10-11T19:38:07Z")
If we ever do item-level hygiene, it’s possible that you may not be able to refer the names of private fields **at all** , so this isn’t future-proof in that respect. ---
**Author:** ![conradkleinespel](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/conradkleinespel/32/298_2.png) [@conradkleinespel](https://internals.rust-lang.org/u/conradkleinespel)\ **Post date:** [October 11, 2014, 8:17pm UTC](https://internals.rust-lang.org/t/add-an-allow-ignore-field-privacy-annotation/625/8 "2014-10-11T20:17:53Z")
Is this something that is supposed to be useful to allow third parties to use your library in a more flexible way? For example, you’d write a library and then the developer that uses it could opt out of protection? Or is it the library creator that would opt out to avoid repitition of `pub`? ---
**Author:** ![Jurily](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/jurily/32/212_2.png) [@Jurily](https://internals.rust-lang.org/u/Jurily)\ **Post date:** [October 12, 2014, 6:26am UTC](https://internals.rust-lang.org/t/add-an-allow-ignore-field-privacy-annotation/625/9 "2014-10-12T06:26:33Z")
> [@eddyb](#): > > If we ever do item-level hygiene, it's possible that you may not be able to refer the names of private fields **at all** , so this isn't future-proof in that respect. Would you prefer `offsetof` + `memcpy`? ---
**Author:** ![eddyb](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/eddyb/32/8411_2.png) [@eddyb](https://internals.rust-lang.org/u/eddyb)\ **Post date:** [October 12, 2014, 6:32am UTC](https://internals.rust-lang.org/t/add-an-allow-ignore-field-privacy-annotation/625/10 "2014-10-12T06:32:00Z")
I would prefer sanity. Could your usecases be covered by public unsafe fields? ---
**Author:** ![Jurily](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/jurily/32/212_2.png) [@Jurily](https://internals.rust-lang.org/u/Jurily)\ **Post date:** [October 12, 2014, 7:45am UTC](https://internals.rust-lang.org/t/add-an-allow-ignore-field-privacy-annotation/625/11 "2014-10-12T07:45:04Z")
My use case is replacing C as the lowest common denominator for base systems and ultra-portable libraries. In my mind, that’s the only niche Rust can thrive, and only if we’re on par with C in every aspect, including a stable ABI other languages can build on and doing things that are normally crazy but make sense in context. The more mature stuff like `Vec` already expose _all_ their fields through unsafe functions, it’s not necessarily a worse choice to get rid of all the boilerplate. Sure, the users will have to respect all the invariants, but that’s why `unsafe` exists in the first place. ---
**Author:** ![tbu](https://avatars.discourse-cdn.com/v4/letter/t/839c29/32.png) [@tbu](https://internals.rust-lang.org/u/tbu)\ **Post date:** [October 12, 2014, 7:47am UTC](https://internals.rust-lang.org/t/add-an-allow-ignore-field-privacy-annotation/625/12 "2014-10-12T07:47:02Z")
C code often uses PIMPL, which hides these details even more. ---
**Author:** ![system](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/system/32/14092_2.png) [@system](https://internals.rust-lang.org/u/system)\ **Post date:** [March 25, 2019, 8:22am UTC](https://internals.rust-lang.org/t/add-an-allow-ignore-field-privacy-annotation/625/13 "2019-03-25T08:22:58Z")
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.