Skip to content

Frequently requested changes: add bypassing visibility #323

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

#

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Frequently requested changes: add bypassing visibility #323

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
e8256d6
Fix hyperlinks
mejrs Apr 15, 2025
99d81d9
frequently requested changes: bypassing visibility
mejrs Apr 16, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
29 changes: 26 additions & 3 deletions src/frequently-requested-changes.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -214,6 +214,29 @@ of tail or internal padding, as they can be reused due to the lack of a possible

Cross-referencing to other discussions:

* https://github.com/rust-lang/rfcs/issues/1397
* https://github.com/rust-lang/rust/issues/17027
* https://github.com/rust-lang/unsafe-code-guidelines/issues/176
* <https://github.com/rust-lang/rfcs/issues/1397>
* <https://github.com/rust-lang/rust/issues/17027>
* <https://github.com/rust-lang/unsafe-code-guidelines/issues/176>

## A way to bypass visibility, including an `unsafe` bypass

Items are only accessible if they are marked `pub` or re-exported as such;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line doesn't read correctly to me as stated, i.e. "or re-exported as such" seems too strong. E.g.:

mod m {
    fn f() {}
}
pub use m::f; //~ ERROR function `f` is private

they are otherwise private by default. People sometimes wish to break that
rule to access internals of libraries they're using, for example to access
private fields of a type or to call private functions.

This could break invariants assumed by the crate's author, which, if any
unsafe code depends on those, could lead to undefined behavior.

More importantly, allowing people to violate privacy would destroy SemVer.
If people can access and use implementation details of other crates then
that means that almost any change is now a breaking change. This would lead
to widespread fallout across the crate ecosystem.
Comment on lines +231 to +234
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
More importantly, allowing people to violate privacy would destroy SemVer.
If people can access and use implementation details of other crates then
that means that almost any change is now a breaking change. This would lead
to widespread fallout across the crate ecosystem.
It's also hard to see how allowing privacy violations could be made
compatible with SemVer.


Making it `unsafe` does nothing to prevent these issues. `unsafe` is
used to deal with memory safety problems and it is not in any way useful to
deal with SemVer concerns.
Comment on lines +236 to +238
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Making it `unsafe` does nothing to prevent these issues. `unsafe` is
used to deal with memory safety problems and it is not in any way useful to
deal with SemVer concerns.
This does not fit with our model of `unsafe` in Rust.


Forking a crate (to insert the necessary `pub`s) does not have these
problems. As such, a better way to achieve this would be to make patch
dependencies more ergonomic to use and maintain.
Comment on lines +240 to +242
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Forking a crate (to insert the necessary `pub`s) does not have these
problems. As such, a better way to achieve this would be to make patch
dependencies more ergonomic to use and maintain.
Forking a crate (to insert the necessary `pub`s) does not have these
problems, and so making patch dependencies more ergonomic to use and
maintain could be one alternative to explore.