# Discussion: Allowing Unsafe to Bypass Visibility **URL:** \ **Category:** Unsafe Code Guidelines\ **Created:** [March 19, 2025, 11:49pm UTC](https://internals.rust-lang.org/t/discussion-allowing-unsafe-to-bypass-visibility/22606 "2025-03-19T23:49:38Z")\ **Posts on this page:** 1\ **Showing post:** 21
**Author:** ![ByThePowerOfScience](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/bythepowerofscience/32/13072_2.png) [@ByThePowerOfScience](https://internals.rust-lang.org/u/ByThePowerOfScience)\ **Post date:** [March 22, 2025, 3:39am UTC](https://internals.rust-lang.org/t/discussion-allowing-unsafe-to-bypass-visibility/22606/21 "2025-03-22T03:39:54Z")
> [@demurgos](#): > > Overall, actively maintained projects tend to react to the issues you raise; that's why a few people asked higher if you contacted the lib maintainers first before posting here. Your case would be stronger if you had examples where maintainers refused to increase visibility without good reasons. I _absolutely_ agree. I usually wind up submitting PRs for pretty much every program I use; every time I find any kind of bug, I submit an issue, and then immediately take a stab at fixing it myself. I'm not against forking projects in the slightest, and if anything I'm _also_ not entirely pleased with how my solution would result in fewer PRs. In this particular instance though, I'm doing something that quite frankly _shouldn't_ be a PR. I don't think the items I need access to _should_ be publicly accessible, since in the 99.9% of cases, having access to it would just cause issues and be more confusing for developers. It shouldn't be popping up in intellisense for _anyone_. However, the problem is that it's _blanket_-blocked without _any way_ to get around it, when there are still 1 in 1000 people who genuinely need that information and don't have any other option.   It's like if the Windows Registry were made inaccessible on principle. Yes, for literally 99.999% of users it will _only_ cause trouble if they have access, but restricting access entirely makes _100%_ of the 0.001%'s needs completely impossible.   It _shouldn't_ be easy, it _shouldn't_ be promoted, and heck it _shouldn't even be a "stable" feature_. But preventing jailbreaking altogether without even the most obscure workaround is not the right move, and that's why I'm so passionate about this.   > [@demurgos](#): > > This kind of silent semantic change is why your proposal gets so much push-pack in my opinion. It needs an answer to semver. Thank you so much for explaining it! I didn't think about cargo doing silent updates; that explains so much about everyone's responses. I was thinking "just be careful when updating!", but no, that does actually make complete sense. _Of course_ you can bind to a non-minorpatch subversion and have changes happen under your nose. That's my bad. In that case, stressing that possibility to the user by adding a warning and confirmation pop-up on update would be the best idea. Ideally, bypassing visibility would be a _nightly-only_, _unsafe_ feature, enabling the feature would be _explicitly stated in the docs to be an absolute last resort_, and enabling it would cause _warnings and confirmations in cargo when attempting to update_ due to the potential semver complications, and hell it should probably throw a linting warning on use too like unsafe operations inside unsafe functions. Those last two would further dissuade people from using it unnecessarily, since _no one_ likes build warnings. Overall, this would serve to allow the possibility while making it annoying as hell to access, which is far better than being outright disallowed by the compiler in all circumstances without recourse.   I don't like the idea of permanently babysitting a terminal fork, since that adds several dozen layers onto maintaining the project and makes it significantly harder to keep your unsafe changes catalogued as well. I really don't like other declaration-based strategies for the same reason: I wouldn't want to accidentally use a formerly-private function somewhere I genuinely don't need it, but changing the source makes it pop up like any other instead of being a case-by-case basis. Ideally the best strategy would be usage-focused so you know where your changes are and what you need to pay special attention to. --- _[View the full topic](https://internals.rust-lang.org/t/discussion-allowing-unsafe-to-bypass-visibility/22606)._